💡 Requesting input

What should a SIRI EstimatedCall's StopPointRef refer to?

Leonard Ehrenfried
Leonard Ehrenfried
I'm a developer working on improving the EPIP support in OpenTripPlanner.

While working with the NeTEx and SIRI feeds for South Tyrol I noticed a discrepancy that I can't really resolve. Their SIRI feed contains the following StopPointRef:

<StopPointRef>it:22021:2129:0:5177</StopPointRef>

it:22021:2129:0:5177 is not a quay id in their NeTEx feed. However, I can find the string in the feed. It's in a ScheduledStopPoint but not in its ID.

<ScheduledStopPoint id="it:apb:ScheduledStopPoint:it-22021-2132-1-5273:" version="any">
  <keyList>
    <KeyValue>
      <Key>GlobalID</Key>
      <Value>it:22021:2132:1:5273</Value>
    </KeyValue>
  </keyList>
  <Name lang="de">Bolzano, Casanova</Name>
  <Location>
    <Longitude>11.315091</Longitude>
    <Latitude>46.480908</Latitude>
  </Location>
  <ShortName lang="de">5273</ShortName>
</ScheduledStopPoint>

My first question is: can a SIRI stop point ref refer to a ScheduledStopPoint?

The various profiles have different opinions about this.


Nordic profile


Reference to the serviced Quay. (ID to the corresponding Quay in the national stop place registry, corresponding to the serviced stop point as assigned in the timetable data or corresponding to the stop point as re-assigned in real-time data.)


EU profile


It says the same:


Reference to the Quay in question (ID corresponding to related object in the National Access Point).
image.png 103 KB View full-size Download

Swiss profile


I believe that the use of the ScheduledStopPoint ID comes from the Swiss profile.


Reference to a SCHEDULED STOP POINT.
image.png 268 KB View full-size Download


Secondly, there is the question if putting the actual ID into the KeyValue is the way these IDs should be modeled. I believe that this value is not in the actual id field because EPIP ids are supposed to follow the following format:
(epd:)[country code] : ([local code]) : [object type] ( _ [epip-type]) : [technical-identifier] : [ID provider for shared IDs]

Can someone confirm that this is the way to go?
See previous comments
Johan Wiklund Johan Wiklund, Data Manager
If we missed the core design points of NeTEx, I say that's not our fault 🤣

- The documentation is paywalled.
- There is no official support or help to be had. At best, it's here - a closed forum, or in GitHub which is not official either. Sometimes questions remain unreplied to.
- We had to make our own examples to learn how to use the format by ourselves.
- The format is full of extremely interpretable features that can tip either way in the hands of each user.

Historical reasons by all means,
Christophe Duquesne (Aurige) Christophe Duquesne
, but using the argument "not easy to change now" does not age well. NOW is the time when it is most easy to change things. Tomorrow, it's even harder.

---

On the topic of this thread. I am not well versed in SIRI so I cant say what is right or wrong - but the same topic is discussed in the thread from
Ulf Bjersing Ulf
Re: RECHARGING POINT ASSIGNMENT - NeTEx - CEN Working Group TC278/WG3/SG9

Quay and Scheduled Stop Point are not synonyms

From what I can tell in
Christophe Duquesne (Aurige) Christophe Duquesne
s reply. "StopPointRef" in SIRI means both STOPPLACE and SCHEDULEDSTOPPOINT because it was not updated when Transmodel was updated. So its really up to the SIRI-source to declare whether it is talking about virtual or physical stops in order to map the data correctly to SP or SSP

I can only conclude then that SIRI is not Transmodel-compliment and this should warrant immediate attention and correction.
Leonard Ehrenfried Leonard Ehrenfried, OpenTripPlanner Developer
I can only agree that the paywalled specifications really, really hurt the people that want to learn and advocate (like myself). But it's also not the point of this thread.
Einar Bjørkevoll Einar Bjørkevoll, Information architect
How we are working with standards, is something Entur is looking into, as today, there is improvements needed.
Both in how we work with the standards, but also the profiles so the use cases is easy to understand and implement.

Here we need to work together and open, both with the standards and profiles. Also, mistakes have been done, misunderstanding have been done, they should be corrected, either by better profiles, change in standards or in implementations.
So,
Stefan de Konink Stefan
, I will welcome your feedback on what to do better, and how we can work better together towards a harmonised standard and profile through Europe as there is a huge need for changes according to the new MMTIS regulation and upcoming MDMS proposal. Changes has to be done, hopefully only in the profiles and implementations, also in providing new APIs etc.

We also agree upon the paywall, but this is not the only issue 
Leonard Ehrenfried Leonard Ehrenfried, OpenTripPlanner Developer
Einar Bjørkevoll Einar
Do you have an opinion about the specific question I have at hand here?
Einar Bjørkevoll Einar Bjørkevoll, Information architect
Leonard Ehrenfried Leonard
 : Sorry, I have to rely on other experts for now, as I also struggle to get into all the stuff in the standards and profiles, have only work on this for an half year, and not then in the SIRI standards. 
My point is that we need to work better on this in the future so we can have better standards and profiles in Europe so we can use each other's data 
Christophe Duquesne (Aurige) Christophe Duquesne (Aurige)
Sure, all contributions and help are most welcome to work on this in the future so we can have better standards and profiles in Europe. Amongst other topics, having a better alignment of SIRI to Transmodel/NeTEx wording (StopPoint/Platform/MonitoringPoint to ScheduledStopPoint/StopPlace/Quay here) would definitely be great, but needs to be done with care in a future major release.
Johan Wiklund Johan Wiklund, Data Manager
In the xsd we have two annotations:
 <xsd:element name="StopPointRef" type="StopPointRefStructure">
  <xsd:annotation>
   <xsd:documentation>Reference to a SCHEDULED STOP POINT.</xsd:documentation>
   <xsd:documentation>Reference to a STOP POINT.</xsd:documentation>
  </xsd:annotation>
 </xsd:element>
What does it mean when there are two annotations. One says its a reference to a SCHEDULED STOP POINT, and the other to a STOP POINT? Does it mean it officially allows both?

Does STOP POINT in this act as an "alias" for SCHEDULED STOP POINT or as an alias for any stop, i.e. STOP PLACE or QUAY?
image.png 53.4 KB View full-size Download
Edited
Christophe Duquesne (Aurige) Christophe Duquesne (Aurige)
As explained before, when SIRI was initially drafted (2006), TM has STOP POINT and no SCHEDULED STOP POINT ... this was updated in Transmodel 6 (2018), and STOP POINT does not exist anymore. 
That's most probably the reason for the 2 lines, but yes, the second one should be removed now. Can you create a SIRI issue for it ?
Johan Wiklund Johan Wiklund, Data Manager
Ok so
image.png 8.92 KB View full-size Download

So, if SIRI isn't changed, the documentation should at the very least say "StopPointRef in SIRI is analogue to ScheduledStopPointRef in NeTEx". At least until that major update can be made.
Edited
Leonard Ehrenfried Leonard Ehrenfried, OpenTripPlanner Developer
So, is referring to a ScheduledStopPoint recommended or required?
Christophe Duquesne (Aurige) Christophe Duquesne (Aurige)
in my view, required for the EPIP-RT Profile (but not yet formally, so recommended, for SIRI itself)
Leonard Ehrenfried Leonard Ehrenfried, OpenTripPlanner Developer
We talked about this topic in today's OTP developer meeting and everybody agreed that using `ScheduledStopPoint` is the way to go. We will add support for it.

About improving the documentation: is it welcome to add more long form explanations which also contain links to the SIRI XSD? Or should it stay as bare bones as it is right now?
Christophe Duquesne (Aurige) Christophe Duquesne (Aurige)
No need to be too long in the Github issue... maybe refer this conversation
Leonard Ehrenfried Leonard Ehrenfried, OpenTripPlanner Developer
My question is if I can add more content to these xsd:documentation elements?

 <xsd:element name="StopPointRef" type="StopPointRefStructure">
  <xsd:annotation>
   <xsd:documentation>Reference to a SCHEDULED STOP POINT.</xsd:documentation>
   <xsd:documentation>Reference to a STOP POINT.</xsd:documentation>
  </xsd:annotation>
 </xsd:element>
Edited
Stefan de Konink Stefan de Konink
Leonard Ehrenfried Leonard
in my opinion, which is orthogonal to what
Johan Wiklund Johan
mentioned, is that the "paid documentation" even after paying for it does not help. With SIRI, similar to OJP (the API), we are moving forward in automatically generating the annotated documentation directly from the XSD. This basically makes that available for free. That having said, it is not SIRI for Dummies, but if someone will add serious annotations at least it will be versioned and rendered.

Ninja edit:
Leonard Ehrenfried Leonard
sure add more content.
Leonard Ehrenfried Leonard Ehrenfried, OpenTripPlanner Developer
Stefan de Konink Stefan
, I very much agree! This is where I would also like to see the documentation. I want to add all of the information of this thread to the XSD.

Can you say a bit more about the tooling you use for converting the XSD to documentation? For years I have been looking for something that generates nice-looking HTML.
Nils Juhl Rasmussen Nils Juhl Rasmussen
SIRI CA explicitly specify that a ChangeOfStopPointStatus shall relate to a SCHEDULED STOP POINT (or a STOP PLACE). However, our use cases for such Control Actions are related to the infrastructure being temporary incapable of receiving Calls. The staff responsible for stop cancellations do (in principle) not know what/if traffic have been planned to serve a given stop.

So shouldn't the reference be a Quay in this case? I.e. in the physical domain.

The consequence of a ChangeOfStopPointStatus control action is that some EstimatedCalls in SIRI ET/SM are cancelled. Now we are in the service domain, as pointed out above (but following the Nordic profile, we in Movia will refer to Quays here). 
Christophe Duquesne (Aurige) Christophe Duquesne (Aurige)
Since the  ChangeOfStopPointStatus is related to a SCHEDULED STOP POINT or a STOP PLACE, and the Quay being in a StopPlace, I guess that you need to refer the STOP PLACE and not the SCHEDULED STOP POINT.
If you need to provide more details about the "event" related to the Quay, then that's more a SX Situation that you need (it can be linked to the Control Action when necessary).
Nils Juhl Rasmussen Nils Juhl Rasmussen
We will always add a Situation, to explain why. But a Situation does not prevent signs from announcing planned departures, and a trip planner from suggesting passenger Trips starting/ending at the cancelled Quay (bus stop). A frequent use case is like:
image.png 477 KB View full-size Download
Christophe Duquesne (Aurige) Christophe Duquesne (Aurige)
That should be fine:
  • the Situation will give the description of the event and also the description of the consequences (with a possible set of publishing actions, including messages for Displays)
  • EstimatedTimetable will provide the possible passing time updates platform (Quay) change, etc.
  • the ControlAction is not dedicated to passenger information (use SX for passenger information), but will record any operational action/decision decided by the Operator, and linked to the Situation.
Leonard Ehrenfried Leonard Ehrenfried, OpenTripPlanner Developer
Since yesterday, the very latest dev version of OpenTripPlanner can understand both quays and scheduled stop points in SIRI's stop point ref.