Service link proposal #175
Conversation
Provides a simplified description of an update of a SERVICE LINK, in order to provide an updated schematic shape (not ROUTE POINTs) in case of rerouting. Only updated ServiceLink are expected to be provided here, the scheduled one being provided by a NeTEx feed. The SERVICE JOURNEY itself is knonw from hte context. Note that, The shape (LineString) is mandatory in order to be consistent with the use case, which is to update the shape. In this initial proposal, the Service Links update can be inserted either in a EstimatedVehicleJourneyStructure (to be repeated for each journey) either in a consequence of a PTSituation (can be shared accross multiple journeys). As usual, the EstimatedVehicleJourneyStructure can be linked with the PTSituation.
|
At present, no ServiceLinks are included in any NeTEx feeds to Entur in Norway generated by the SignatureRail NeTEx Integrator. However, the Integrator has a MasterNetwork, in which ServiceLinks for all rail routes are already defined, and routes for rail-replacement busses can also be defined. Once defined, bus ServiceLinks could then be included in NeTEx exports. However, note that none of the current rail-replacement bus data sources includes any form of ServiceLink data, only the calling points of the busses (thus defining the two ends of each ServiceLink joining two calling points). If there is any variability in the ServiceLink to be used between two calling points, then the sources of rail-replacement bus data may need to be enhanced to give at least one intermediate routing point. |
| <xsd:documentation>Relations of the journey with other journeys, e.g., in case a joining/splitting takes place or the journey substitutes for another one etc.</xsd:documentation> | ||
| </xsd:annotation> | ||
| </xsd:element> | ||
| <xsd:element name="UpdatedServiceLinks" type="ServiceLinkViewsStructure" minOccurs="0"> |
There was a problem hiding this comment.
This is not acceptable for me. This will cause implementations to provide UpdatedServiceLinks for every EstimatedTimetable Update.
There was a problem hiding this comment.
cause implementations to provide? It will enable implementations to provide. I think a pertinent question is how often is the routing of a bus or train (or other transport medium) re-routed between being planned (NeTEx) and being implemented (SIRI). Yes, I have seen trains seriously rerouted after a bridge has been damaged, and busses being seriously rerouted because of a major accident on a road, but it is not a frequent occurrence in my experience. Much more often you just get an extended delay (or cancellation).
And even if a rerouting does occur on the day, once the rerouting has been established, it should not need to be repeated with every updated EstimatedTimetable (unless the routing has been changed again)
There was a problem hiding this comment.
I am not sure I understand your point @skinkie as the minOccurs="0", so it looks optional to me.
There was a problem hiding this comment.
The problem is that it can be used to transfer service links upon every ET message. That is still not acceptable for me.
There was a problem hiding this comment.
@skinkie There are many different places where optional additional data can be unnecessarily be added to SIRI messages. So why just pick on the service link here? What would you suggest instead? In my experience, a dynamic change of route, which is what a new service link implies, is inevitably tightly linked to a new estimated timetable for the remainder of the journey.
Is it the volume of data that can be required by a Service Link that is troubling you? I agree that the data volume can be quite high (some of my rail service links have several hundred GPS points, with a few longer distance ones going into the thousands). So are you, in effect, wanting a pre-existing Library of Service Links, meaning that a dynamic change of route would only require a new Service Link Ref?
There was a problem hiding this comment.
Why? Because we should not introduce more options to do stupid stuff. Hence a single place, the situation exchange, would make total sense. One message, one location.
|
This was decided at the Cologne meeting. ServiceLink in SX with reference from ET. |
|
What do you think about using OpenLR for the service Link ? What do you think about not only to allow stopPointRef as from/to - element but to allow also others, e.g. StopPlace |
TuThoThai
added
the
Needs CEN documentation Update
|
replaced by #194 |
7 participants
First proposal to include ServiceLinks
Provides a simplified description of an update of a SERVICE LINK, in order to provide an updated schematic shape (not ROUTE POINTs) in case of rerouting. Only updated ServiceLink are expected to be provided here, the scheduled one being provided by a NeTEx feed. The SERVICE JOURNEY itself is knonw from hte context.
Note that, The shape (LineString) is mandatory in order to be consistent with the use case, which is to update the shape.
In this initial proposal, the Service Links update can be inserted either in a EstimatedVehicleJourneyStructure (to be repeated for each journey) either in a consequence of a PTSituation (can be shared accross multiple journeys). As usual, the EstimatedVehicleJourneyStructure can be linked with the PTSituation.