-
Notifications
You must be signed in to change notification settings - Fork 11
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Siri formation in full in OJP 2.0 #328
Conversation
We need parameters in the request. Trigger what happens. Only in Trip Refinement and not Trip. Malte: Subpart better. At least in specification. |
Norman: Checking consistency might be a problem. |
Only TripInformation. |
Examples will be taken from the Swiss realisation guide v 0.9 |
@herlitze @normanoffel @Aurige @sgrossberndt @skinkie : Heavy weight stuff ready for your consideration.... |
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? |
@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? |
@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 @normanoffel @haeckerbaer @Aurige 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: For this we probably would need CompoundTrains: |
@ue71603 you are right, TrainElements only is not enough. Would Traincomponents be sufficient? |
@ue71603 I did not find the information of the sectors: |
@herlitze I think you need all. See what the structure means. |
@herlitze 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) |
A TrainComponent can contain only one TrainElement. |
Technically simple, the explanation of the usage more difficult. We need a chapter on VehicleFeatureRef in OJP.
84e5b3e
@@ -357,6 +367,9 @@ | |||
</xs:annotation> | |||
<xs:sequence> | |||
<xs:group ref="ServiceTimeGroup"/> | |||
<xs:element ref="siri:ArrivalFormationAssignment" minOccurs="0"/> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is the cardinality correct? DepartureFormationAssignment needs maxOccurs="unbounded".
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes.. there might be more than one.
@@ -357,6 +367,9 @@ | |||
</xs:annotation> | |||
<xs:sequence> | |||
<xs:group ref="ServiceTimeGroup"/> | |||
<xs:element ref="siri:ArrivalFormationAssignment" minOccurs="0"/> | |||
<!-- comes with SIRI 2.1 --> | |||
<!-- TODO the quays should be moved here, too --> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this comment needed/useful?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think for following up (when updating to SIRI 2.1 it is)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ok
Technically simple, the explanation of the usage more difficult. We need a chapter on VehicleFeatureRef in OJP.
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: #269
It does not validate until we have SIRI 2.1 referenced in our project.