Using SIRI's StopPointRef to carry a ScheduledStopPoint is Ok (but should be mentioned in the profile, since the initial intention was also for StopPlace or Quay, but that's not a constraint in SIRI), but having the ScheduledStopPoint ID in a key/value is not acceptable to me: SIRI's StopPointRef has to use the real ID of the object it is referencing.
The ID structure proposed by EPIP is here to make sure you build a unique (Europe-wide) and stable ID if you don't have one. But if you have something like a national stop reference database that provides unique+stable IDs, that's fully fine (even if the ID structure does not follow EPIP's proposed one). We are making this clearer in the ongoing NeTEx+EPIP update.
Edited
Leonard Ehrenfried,
OpenTripPlanner Developer
Thanks Christophe, this is very valuable information!
The German DELFI NeTEx feeds also use the GlobalID KeyValue which causes some problems.
Is it possible to make this post public so I can link to it when I discuss this with producers?
Leonard Ehrenfried,
OpenTripPlanner Developer
And about the ScheduledStopPoint: would the routing engine need to store all ScheduledStopPoints at "runtime" to be able to reference them back to the actual quay/stop place or how is this intended to work?
You have PassengerStopAssignment to link ScheduledStopPoint to StopPlace/Quay ... from this point you can do whatever you want.
Stefan de Konink
@Günter Matthias (IT-SWE-CC3-TS2) (mailto:matthias.guenter@sbb.ch) I think this should also be reported at our NAP quality issues.
Matthias Günter
Christophe. Here I have to disagree. When Quays are reference in Siri profiles, this is just plain wrong from the abstraction level. We are in the service domain in SIRI and not on the physical level from NeTEx. We had multiple discussions on that in different groups. If this crept into the final profile version it is still wrong. What is correct is that the ScheduledStopPoint must be assigned to a Quay and not the StopPlace.
Christophe Duquesne (Aurige)
Matthias
I guess that we can agree on the fact that having a referenced idendifier in a key/value, instead of main ID, is a bad idea ....
For the use of StopPointRef, I agree with you, but there are multiple element to consider:
SIRI itself does not make any restriction on the use of ScheduledStopPoint, StopPlace or Quay,
Profiles do make such restriction, and in this context the choice you are pointing is 100% legitimate (and recommended)
In EPIP-RT (EU SIRI Profile), the choice is mainly on ScheduledStopPoint, but a StopPointRef can also refer a Quay in SX (which is Ok I think) and also in some xxxCallStruture (not sure that's very consistent here ....)
It's true that a ScheduledStopPoint should be assigned to a Quay ... but some providers (including very big ones ...) have some StopPlace without any Quay described inside (or a very late Quay assignment), and in that case we need to do with what we have (and push them to improve their data... which unfortunately takes sooooo long ;-) ).
Leonard Ehrenfried,
OpenTripPlanner Developer
Christophe Duquesne
If the EPIP SIRI profile is supposed to use ScheduledStopPoint why does the document say they are quays?
For reference, the screenshot I posted is from the following document: "Public transport — Service interface for real-time information relating to public transport operations — Part 7: European Real-Time Passenger SIRI Information Profile"
Christophe Duquesne (Aurige)
for some reason the images don't show up in your post ... but yes, as mentionned by
Matthias
the ScheduledStopPoint is the best choice (and you need the xxxStopAssignment, and/or the platformName to reference the Quay). I would say that the references to Quays in some StopPointRef comments in some xxxCallStruture in EPIP-RT is most probably a mistake to be corrected.
Leonard Ehrenfried,
OpenTripPlanner Developer
I've figured out why the screenshots don't show up and re-uploaded. Can you check it out?
Matthias Günter
EPIP SIRI: In my view an error.
However, it might be that the ScheduledStopPoint and the Quay have the same id (NeTEx can distinguish this by the class easily and in SIRI it does not matter that much (as Christophe points out)). In Switzerland the sloid is the same for both.
About not having Quays or assigning them very late: Also a StopPlace can have a ScheduledStopPoint and a PassengerStopAssignment just referencing a StopPlace. That would be the correct way of doing it. It is about the separation of concerns: One is the physical model and one is the service model.
The problem with SIRI SX especially is true for the messages concering the physical part.
Let's have a look at Transmodel: SIRI is based on DATED VEHICLE JOURNEYS
I agree however, that the modeling of CALL allows for the other interpretation. With CALL PART. However, it must be noted that CALL wasn't really modeled in that great a detail (as you can see from the "Transmodel Copy" relation.
I'm not sure I understand the last diagramme fully, but I think I'm starting to get the logic behind the ScheduledStopPoint/Quay difference.
Matthias
, if both IDs are the same in Switzerland, what is the benefit for the producer of the SIRI feed to refer to the SSP and not to the Quay.
I think that having an error in the SIRI+EPIP document (
Christophe Duquesne
, can you confirm this?) is something that should be corrected somehow. Is there a collection of errata somewhere?
Lastly, I'm also constrained by OTP's current SIRI implementation which only supports the Nordic profile, and there it definitely is not a mistake that it refers to Quays, not ScheduledStopPoints, as it's used in Norway and Sweden in production for several years. Maybe I can get someone from Entur to comment.
Stefan de Konink
There are more things in Norway that people implemented without knowing the data model.
Leonard Ehrenfried,
OpenTripPlanner Developer
Stefan, I would really like to ask you to cool it with the accusations and insults. Please not here.
Norway's data model may not be perfect but they have the entire country on NeTEx/SIRI, have written tons of open source software to support it and are lobbying hard to move away from country profiles into a single, unified one. In short, they are doing a lot of things right in my view.
Leonard
The problem is that these are two views. StopPlace/Quay are physical objects. ScheduledStopPoints are service/timetable objects. There are (a lot) of transport operators that only provide the service/timetable views. That's why ScheduledStopPoints may also have addresses etc (a bad decision in my personal opinion). That in some ways you do and want to merge those is what happens in real world data models. However, here it s conceptually wrong (as the diagrams from Transmodel show).
Stefan de Konink
You explicitly mentioned: it definitely is not a mistake. I dispute this claim. In Dutch we have a saying unconsciously incompetent. And this applies here too. Entur has implemented NeTEx as a (de)serialisation format, and cherry picked what applied for them, and it continues to do so. The netex java code by entur is a famous example for it, at best it is a profile, but not aligned with the core design points. Since I have never implemented SIRI for an Entur system I cannot comment on what happened there, but I am certain that a Quay is not what the StopPointRef points to. There are other fields that do.
And just to explain the context: SIRI was started in 2006, and at that time, Transmodel version was Transmodel 5, and had not StopPlace/Quay defined. NeTEx was started in 2009 and introduced the StopPlace, Quay (from another standard named IFOPT) and renamed the Transmodel's STOP POINT to SCHEDULED STOP POINT (to avoid confusion), and all this was later on reintegrated in Transmodel 6. That's why SIRI is not as accurante as Transmodel/NeTEx on the stop point concept, and as there are many implementations that's not easy to change now. This said, new implementations should follow the rules of EPIP-RT.
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
, 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.
From what I can tell in
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,
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,
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
, 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,
OpenTripPlanner Developer
Einar
Do you have an opinion about the specific question I have at hand here?
Einar Bjørkevoll,
Information architect
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)
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.
<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?
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,
Data Manager
Ok so
image.png
8.92 KB
View full-sizeDownload 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,
OpenTripPlanner Developer
So, is referring to a ScheduledStopPoint recommended or required?
Christophe Duquesne (Aurige)
in my view, required for the EPIP-RT Profile (but not yet formally, so recommended, for SIRI itself)
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)
No need to be too long in the Github issue... maybe refer this conversation
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
Leonard
in my opinion, which is orthogonal to what
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
sure add more content.
Leonard Ehrenfried,
OpenTripPlanner Developer
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.
Stefan de Konink
Matthias
paid some smart dudes, that went beyond anything you can do with XSLT, and it is not limited to a specific XSD technique (salami slice, etc.)
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)
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
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:
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,
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.
The ID structure proposed by EPIP is here to make sure you build a unique (Europe-wide) and stable ID if you don't have one. But if you have something like a national stop reference database that provides unique+stable IDs, that's fully fine (even if the ID structure does not follow EPIP's proposed one). We are making this clearer in the ongoing NeTEx+EPIP update.
The German DELFI NeTEx feeds also use the GlobalID KeyValue which causes some problems.
Is it possible to make this post public so I can link to it when I discuss this with producers?
What is correct is that the ScheduledStopPoint must be assigned to a Quay and not the StopPlace.
For the use of StopPointRef, I agree with you, but there are multiple element to consider:
If the EPIP SIRI profile is supposed to use ScheduledStopPoint why does the document say they are quays?
For reference, the screenshot I posted is from the following document:
"Public transport — Service interface for real-time information relating to
public transport operations — Part 7: European Real-Time Passenger SIRI
Information Profile"
I would say that the references to Quays in some StopPointRef comments in some xxxCallStruture in EPIP-RT is most probably a mistake to be corrected.
However, it might be that the ScheduledStopPoint and the Quay have the same id (NeTEx can distinguish this by the class easily and in SIRI it does not matter that much (as Christophe points out)). In Switzerland the sloid is the same for both.
About not having Quays or assigning them very late: Also a StopPlace can have a ScheduledStopPoint and a PassengerStopAssignment just referencing a StopPlace. That would be the correct way of doing it. It is about the separation of concerns: One is the physical model and one is the service model.
The problem with SIRI SX especially is true for the messages concering the physical part.
Let's have a look at Transmodel: SIRI is based on DATED VEHICLE JOURNEYS
I agree however, that the modeling of CALL allows for the other interpretation. With CALL PART. However, it must be noted that CALL wasn't really modeled in that great a detail (as you can see from the "Transmodel Copy" relation.
I think that having an error in the SIRI+EPIP document (
Lastly, I'm also constrained by OTP's current SIRI implementation which only supports the Nordic profile, and there it definitely is not a mistake that it refers to Quays, not ScheduledStopPoints, as it's used in Norway and Sweden in production for several years. Maybe I can get someone from Entur to comment.
Norway's data model may not be perfect but they have the entire country on NeTEx/SIRI, have written tons of open source software to support it and are lobbying hard to move away from country profiles into a single, unified one. In short, they are doing a lot of things right in my view.
And just to explain the context: SIRI was started in 2006, and at that time, Transmodel version was Transmodel 5, and had not StopPlace/Quay defined. NeTEx was started in 2009 and introduced the StopPlace, Quay (from another standard named IFOPT) and renamed the Transmodel's STOP POINT to SCHEDULED STOP POINT (to avoid confusion), and all this was later on reintegrated in Transmodel 6. That's why SIRI is not as accurante as Transmodel/NeTEx on the stop point concept, and as there are many implementations that's not easy to change now. This said, new implementations should follow the rules of EPIP-RT.
- 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,
---
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
From what I can tell in
I can only conclude then that SIRI is not Transmodel-compliment and this should warrant immediate attention and correction.
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,
We also agree upon the paywall, but this is not the only issue
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
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?
https://github.com/SIRI-CEN/SIRI/blob/ce377ce9a860ac5758a99a159e78716ad74982aa/xsd/siri_model/siri_reference.xsd#L174
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 ?
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.
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?
Ninja edit:
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.
https://github.com/VDVde/OJP/blob/develop/docs/generate-tables.sh
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).
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).