| [railML2] New semantic constraint for <trainPart> [message #3671] |
Wed, 09 July 2025 16:44  |
Milan Wölke
Messages: 213
Registered: April 2007
|
Senior Member |
|
|
Hi all,
we got a suggestion for a new semantic constraint for railML 2. It was pointed out to us that there is no semantic constraint yet making sure that when connecting two <trainPart>'s in a <trainPartSequence> the last <ocpTT> of the previous <trainPart> references the same <ocp> as the first <ocpTT> of the succeeding <trainPart>.
Therefore we suggest introducing the following semantic constraint:
When connecting <trainPart>'s in a <trainPartSequence> it shall be ensured, that the <ocp> referenced by the last <ocpTT> of the previous <trainPart> and the <ocp> referenced by the first <ocpTT> of the succeeding <trainPart> are the same.
Please let us know if you dont agree to the introduction of a semantic constrain like this.
Best regards, Milan
Milan Hoffmann – Timetable schema coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org
|
|
|
|
| Re: [railML2] New semantic constraint for <trainPart> [message #3675 is a reply to message #3671] |
Thu, 24 July 2025 14:52  |
David Lichti
Messages: 54
Registered: December 2020
|
Member |
|
|
Hi all,
We (Hacon) object to this proposal.
Consider a situtation with two trains with different origins and destinations: T1 from A via C and D to E, and T2 from B via C and D to F.
This would be represented with 3 trains parts for each train. This would result in the following train part sequences:
- T1: T1-1 (A-C), T1-2 (C-D), T1-3 (D-E)
- T2: T2-1 (B-C), T2-2 (C-D), T2-3 (D-F)
Now, both trains are coupled together at C, and split again at D. The commercial trains would remain the same. But for the operational view, there would only be one operational train between C and D. Before C and after D, nothing changes:
- T1: T1-1 (A-C), T1-2+T2-2 (C-D), T1-3 (D-E)
- T2: T2-1 (B-C), T2-3 (D-F)
This would naturally result in a train part sequence with two subsequent train parts that do not share the same station.
I attached an example of how such a situation would be represented in our timetable export.
Best regards
David
|
|
|
|
| Re: [railML2] New semantic constraint for <trainPart> [message #3684 is a reply to message #3675] |
Mon, 04 August 2025 14:22 |
Milan Wölke
Messages: 213
Registered: April 2007
|
Senior Member |
|
|
Hi David,
understood, so basically the operational train number of the train changes from 1029 to 1129 and back to 1029 when looking at the train to CH.
We did assume that a train number is only used once a day when proposing this constraint. How about making this a best practice then? After all in most situations the rules described in the semcon above will apply.
I will add a section to the page for trainPartSequence.
Thanks for responding.
Best regards, Milan
Milan Hoffmann – Timetable schema coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org
|
|
|
|
| Re: [railML2] New semantic constraint for <trainPart> [message #3689 is a reply to message #3675] |
Mon, 11 August 2025 08:43 |
Christian Rößiger
Messages: 80
Registered: March 2015
|
Member |
|
|
Hello,
We always export railml trains (operational und commercial) in such a way that there are no gaps in the sequence of operating points. Our import also requires this and refuses to import if one trainPart begins at a different operating point than its predecessor ended.
We would always implement David's example using 3 operational trains, see https://www.irfp.de/files/iRFP/Downloads/railml_beispiel_zug teile.pdf (page 11, 'Beispiel 2'). In most cases, all three operational trains have different train numbers. Otherwise, we use the 'additionalTrainNumber' attribute to distinguish between two trains with the same train number.
Best regards
Christian
|
|
|
|
Members
Search
Help
Login
Home
