Implementing the ideas and structures : Demand-oriented traffic

[ue71603]

I suggest to study and eventually implement the ideas from the document "Auskunft und Buchung von bedarfsorientiertem öffentlichen Personennahverkehr über Auskunftssysteme" by the Bundesministerium fü rVerkehr und digitale Infrastruktur.
The result should be consolidated with the new mode working group of CEN.

Documents will be added as soon as I have the permission to do that.

Adaptions needed (started writing chapter 5.4.3 On Demand Traffic in the specification document)

• We need to clarify which Modes are covered
• The LocationInformationResponse must include information about additional operators (see Add operators to PlaceResultStructure and ResponseContext, allow multiple per ServiceGroup #220)and Modes (already covered). We suggest that the PlaceResult contains the demandAndResponsiveBus even for coordinates, when it can be used. the multiple operators help.
• Trip responses don't need to be adapted in our view in the syntax. However, what is returned depends heavily on the offer information in the "timetable".
• The new line service should be able to provide the area (see LineInformation Request and Response service  #243)
• The availability request should already be able to handle a trip leg that comes from an on demand bus
• The fare request should already be able to handle a trip leg that comes from an on demand bus
• handling of situations works with the existing mechanism.
• The problems with other realtime information is already completly handled by the current structures
• MultipointTripRequest and Exchangepoint Request are not affected by demand responsive traffic in our view.
• StopEvent: In the StopEventResult the Service should contain an extension to the ServiceStatusGroup or a ResponsiveServiceStatusGroup.Best is we add it to DatedJourneyStructure The StopCallSTatusGroup contains already the necessary information with RequestStop. If a stop has already been requested, this can't be shown here directly. Perhaps the RequestStop could be set to false, when the stop is confirmed by real-time information
• TripInformation: It should be shown, when a reservation for a Journey or a Vehicle is necessary. This needs to be added to DatedJourneyStructure.
• For all TimedLeg where a reservation is necessary, it should be shown. One part is certainly that a BookingArrangement must be present. However, in some cases we want to indicate that a reservation is needed. This needs to be added to DatedJourneyStructure.

[ue71603]

BMVI_Planungshandbuch_Bedarfsverkehr_v1.2.pdf

trias-xsd-v1.1_ReservierenUndBuchen_official.zip

[ue71603]

@trurlurl can you check, if we did enough in the document. I assume that I did it, but this is for review purposes.

[trurlurl]

Here the points where I have doubts.

A) From text above: "The new line service should be able to provide the area (see LineInformation Request and Response service #243) "
LineInformationResult does not seem to allow for areas - I only see RouteGeometry of type LinearShape = siri:LocationStructure

B) Would a ferry or a cableway that operates on request be a on-demand service? If yes, the following statement from the specification document and the PtModeEnumeration should be extended, I guess?

C) From text above: "StopEvent: In the StopEventResult the Service should contain an extension to the ServiceStatusGroup or a ResponsiveServiceStatusGroup.Best is we add it to DatedJourneyStructure"
This I don't understand, and I don't have the impression something had been done.

The rest is present and documented in my view.

[ue71603]

(B) We can only do this, when SIRI changes it. Issue added: SIRI-CEN/SIRI#105 . However, currently not that important. So I added a sentence to 5.4.5 and we can leave this be.

(A) You are right the RouteGeometry is completly unsuited for areas. Structure was defined, but not included. Is now: #337

(C) One part was the question and the second the answer. Is now described in detail in 5.4.5.2