| [railML 3] Qualifier for train times [message #4006] |
Tue, 19 May 2026 08:10  |
David Lichti
Messages: 60
Registered: December 2020
|
Member |
|
|
Hi all,
We (Hacon) are currently looking into a way to distinguish different qualities of a train schedule's (stop:times and pass:times). While our runtime calculation can automatically derive all these times for a given itinerary, our tool also allows the planner to manually set and fix selected arrival/departure/pass times.
In railML 2, this could be expressed with times@scope="calculated". Though this was mutually exclusive with the values operational/commercial in the same attribute.
In railML 3, the enumeration for the times@scope attribute has only the values operational and commercial. Additionally, our TPS.plan allows to fix arrival and/or departure times independently of each other. So, the times element would not have the sufficient granularity.
We suggest to add an attribute like quality to the arrival, departure and passingTime elements. It should support values like calculated and fixed.
[Updated on: Tue, 19 May 2026 08:11] Report message to a moderator |
|
|
|
|
|
| Re: [railML 3] Qualifier for train times [message #4187 is a reply to message #4020] |
Tue, 15 September 2026 11:10  |
Milan Wölke
Messages: 238
Registered: April 2007
|
Senior Member |
|
|
Hi all,
we also discussed in this context to add another attribute to the <times> structure, named datasource with the proposed values plan, operations and history. "plan" would identify times that originate with the planning, "operations" would indicate that the times are feedback from operations and "history" would point to statistical data.
The developer group decided against adding this to version 3.4 of railML.
It was found, that adding this would basically introduce the ability to describe not only the schedule, but also live data, so trains that are running at the time of writing. Although this is an interesting topic and we aim to add this to railML, it was found, that due to the approaching publishing of railML 3.4 it would not be possible to add a proper modelling for such use case. After all, the way trains are described in railML 3 is designed for minimal redundancy while retaining information about the governing rules on how the schedule was created.
For an exchange of recorded or currently running times this model is not ideal. The idea in the developer group was to rather aim for a specific model for this use case than to bend the existing model to the new requirements.
Just so you know what is going on. If you are of different opinion, let us know. Also if you are interested in exchanging live and statistical timetable data with railML, let us know.
Best regards, Milan
Milan Hoffmann – Timetable schema coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org
|
|
|
|
Search
Help
Members
Login
Home
