| [railML2] Proposal for a new semantic constraint for <stopTimes> [message #3504] |
Tue, 11 March 2025 16:16  |
Milan Wölke
Messages: 213
Registered: April 2007
|
Senior Member |
|
|
Hi all,
during one of the last timetable developer meetings we discussed an issue that was reported to us by one of our partners. The problem was that <stopTimes> specified for a <stopDescription> of an <ocpTT> at the border of a <trainPart> disagreed on the specified @minimalTime. The partner proposed to introduce a semantic constraint to ensure that the <stopTimes> @minimalTime provided for the same stop in different <trainPart>'s (two adjacent <trainPart>'s of the same <train>) would not contradict each other.
During the discussion in the developer group we found that some members agreed with this approach, others did not and argued that if this scenario took place the lower value would be valid as it is a @minimalTime being specified.
I am writing to you in hope of getting a better overview of what the community thinks of this scenario. How would your systems interprete a situation where two minimalTime values are provided for the same stop? Which one would your systems consider, the one from the departing stop, the lower one?
Please let us know what you think, should we introduce a constraint on 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] Proposal for a new semantic constraint for <stopTimes> [message #3530 is a reply to message #3504] |
Fri, 28 March 2025 10:52  |
Christian Rößiger
Messages: 80
Registered: March 2015
|
Member |
|
|
Hello,
in principle I would welcome the introduction of a SemCon that ensures,
that adjacent trainParts have identical minimal stop times at the same
stop. However I still see some open questions in this context:
Is it allowed to export different minimal times in the trainParts
referenced by one trainPartSequence? This could be justified for example
due to different technical passenger exchange times dependent on the
vehicle or if trainParts have to be shunted in different ways (coupling
& sharing) during a stop.
So, if the above is allowed, it is not enough to ensure that all
trainparts of two adjacent trainPartSequences have the same minimal stop
times at their common ocp. Instead, the minimal stop times of each
trainPart and its individual successor would have to be checked. The big
problem with this is, that a direct successor of one trainPart can not
be determined reliably in railML2.
On the other hand, if all trainParts of one trainPartSequence must have
the same minimal stop times, it is maybe too strict to require that all
minimal times of two adjacent trainPartSequences (in operational and
commercial trains) have identical minimal stop times.
Best regards
Christian Rößiger
--
iRFP e. K. · Institut für Regional- und Fernverkehrsplanung
Hochschulstr. 45, 01069 Dresden
Tel. +49 351 4706819 · Fax. +49 351 4768190 · www.irfp.de
Registergericht: Amtsgericht Dresden, HRA 9347
|
|
|
|
| Re: [railML2] Proposal for a new semantic constraint for <stopTimes> [message #3533 is a reply to message #3530] |
Fri, 28 March 2025 14:07 |
Milan Wölke
Messages: 213
Registered: April 2007
|
Senior Member |
|
|
Hi Christian,
thanks for your valuable input. Could you please elaborate on the scenario where different minimal stop times would be provided? What would be the meaning of the individual minimal stop times? Would they then be added together?
Thanks in advance for the clarification.
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] Proposal for a new semantic constraint for <stopTimes> [message #3546 is a reply to message #3533] |
Tue, 08 April 2025 09:47 |
Christian Rößiger
Messages: 80
Registered: March 2015
|
Member |
|
|
Hi Milan,
my scenario is a train consisting of two trainparts (maybe multiple units) that is split at an intermediate station. Both trainparts continue their journey in two separate operational trains afterwards and both may have different minimal times at this station:
The minimal time of the foremost trainparts consists of the time components for uncoupling and passenger exchange (which may take place simultaneously)
For the rear trainpart applies the same, but since a second train driver is needed and certain additional startup procedures have to be done, it will probably have a higher minimal time than the first one.
In terms of railML this means that 2 coupled trainparts (of the same trainpartSequence) must not necessarily have identical minimal times at a station. But it should be possible to ensure that the minimal times of each of the coupled trainparts and its direct successor after the split are consistent.
Unfortunately, railML2 doesn't make it easy to determine the direct successor of one trainPart. So, I'm a little bit concerned, that we find a wording for the SemCon, that
a) covers all possible cases and
b) is still understandable for the implementor
Best regards
Christian
|
|
|
|
Members
Search
Help
Login
Home
