Siri formation in full in OJP 2.0

[ue71603]

Technically simple, the explanation of the usage more difficult. We need a chapter on VehicleFeatureRef in OJP.

• Includes VehicleFeatureREf
• Includes Formation on journey level
• Includes Formation on arrival and departure

Another problem that would need to be addressed is that the Quay information in OJP is only textual. Perhaps we should switch this too. (separate PR then). A lot of explanation in the documentation is needed, to not do overkill. The reason to use SIRI: I had today a discussion with Adrian. We believe that the SIRI 2.1 formation should be used. We may in the documentation show, how to use it in a simplified form (only some elements to be filled in). However:

It is the format for Transmodel For accessibility complex things might be necessary. GTFS RT formation extension is no better in the end. When this is agreed, I will copy things from the CEN SIRI European profile draft (information from Adrian).

For non-train SIRI proposes the usage of VehicleFeatureRef. We don't have that neither in OJP.

Continues the discussion from: https://github.com/VDVde/OJP/issues/269

It does not validate until we have SIRI 2.1 referenced in our project.

[ue71603]

We need parameters in the request. Trigger what happens. Only in Trip Refinement and not Trip. Only TripRefinement and TripInformation.

Malte: Subpart better. At least in specification. Christophe: Info from rail. Avoid having it here, but use SIRI. The reality is complex not the structure.

[ue71603]

Norman: Checking consistency might be a problem.

[ue71603]

Only TripInformation.

[ue71603]

Examples will be taken from the Swiss realisation guide v 0.9

[ue71603]

Added formation now in fully. I know that we wanted it only on TripInformation and there the filter is. However: As it is part of the regular structure, it would be possible to add formation also on Trips and StopEvent

It would be a big pain to take it out (splitting the whole DatedVehicleJourney structure). Would you agree we tell people. You may do it here, but you should not. Do it only in TripInformation?

[ue71603]

@herlitze @normanoffel @Aurige @sgrossberndt @skinkie : Heavy weight stuff ready for your consideration....

[ue71603]

description in spec in 5.3.4, 5.4.6, 7 (some sections and very briefly), 8.8.1

[herlitze]

description in spec in 5.3.4, 5.4.6, 7 (some sections and very briefly), 8.8.1

The description added is hinting in the right direction, but there is no restriction to a less complex part of the SIRI model. You write that the full model is needed for accessibility, are you sure about that? Would it be possible to only allow a list of TrainElements instead of the JourneyFormationGroup including Trains and CompoundTrains as well?

[ue71603]

@herlitze We could mention that one should stick to the SIRI European profile? Technically: How should I restrict it? Or is a textual limitation enough?

[herlitze]

@ue71603 Instead of using siri:JourneyFormationGroup we could use the Type of TrainElements.

[ue71603]

@ue71603 Instead of using siri:JourneyFormationGroup we could use the Type of TrainElements.

Can't follow you. Perhaps more than a single sentence is needed to explain what you mean.

[herlitze]

In the last of your 3 screenshots you added the element to DatedJourneyStructure. Instead of this we could add only TrainElementStructure (the subelement of JourneyFormationGroup) directly:

[ue71603]

• Search for use cases.
• UC1: present the train as it is (like it is in thedocumentation)
• UC2: Accessibility vehicle
• UC3: Accessibility vehicle-stop interaction Either we find something that makes it necessary or skip.

[ue71603]

@herlitze @normanoffel @haeckerbaer @Aurige We only can remove Trains and TrainElements from the JourneyFormationGroup, when we have the physical TrainElements and Trains always in CompundTrains. However, not all Trains are CompoundTrains. We could certainly agree that TrainElements and Trains can only be directly added to the JourneyFormationGroup and are always referenced. TrainElements alone are not expressive enough, Especially the order of the carriages is in Trains (as TrainComponents that contain a TrainElement) and not in TrainElements.

The restrictions that you want we could do by refering to the European profile for SIRI, that hopefully puts some restrictions on the way formations are modeled.

Examples: For this we need (in my opinion, pls @haeckerbaer correct me, if necessary) Trains, TrainComponents and TrainElements:

Here too:

For this we probably would need CompoundTrains: (to express that one can't move from one Train to the other)

[herlitze]

@ue71603 you are right, TrainElements only is not enough. Would Traincomponents be sufficient?

[herlitze]

@ue71603 I did not find the information of the sectors: Can you give me a hint where to find them?

[ue71603]

@herlitze I think you need all. See what the structure means.

[ue71603]

@herlitze
DatedJourneyGroup contains JourneyFormationGroup. There all relevant information is stored.

The assignment occurs in the ServiceDeaprtureStructure / where the DepartureFormationAssignment exists. We were a bit lazy there, because we also could use a ArrivalFormationAssignment, but we skipped that for now. So I tried to minimize...

The relevant information about the sectors is part of the DepartureFormationAssignment.

And this brought about one mistake. I need an unbounded amount of DepartureFormationAssignments (for each relevant part of the CompoundTrain/Train/TrainElement)

[ue71603]

A TrainComponent can contain only one TrainElement. Split in Ham IC from Berlin (has two ServiceJourney at the beginning). Norman: Could be on ServiceSection to save data? Matthias: There may cases where the formation changes but no ServiceSection change (e.g. direct carriage).