Home » railML newsgroups » railml.infrastructure » Definition of track/stoppingPlace/platform infrastructure vs. timetable
Definition of track/stoppingPlace/platform infrastructure vs. timetable [message #2252] Wed, 02 October 2019 17:00 Go to next message
Stefan Hubrig is currently offline  Stefan Hubrig
Messages: 2
Registered: October 2018
Junior Member
Dear all,

I stumbled over the definition of the <track> in infrastructure:

<xs:documentation>A Track is defined by a railway section between two switches/crossings or between a switch/crossing and a buffer stop.</xs:documentation>

Does this definition cover tracks in the context of timetables? For those, we would want to describe where the train stops inside an operationalPoint. In that case, there would be a single line track through many operationalPoints since there is no switch. What would <track> <length> refer to?

If <track> is not the right fit here, what would we choose instead?

For most timetable applications it is sufficient to know on which "track" of the operational point the train will stop (or pass). But a more specific description could be either of:
stoppingPosition (currently not in railML)
Describes where the front of the train stops
important parameters for compatibility with a train: train type/category, direction

stoppingPlace
Refers to the train stop position with the length
important parameters for compatibility with a train: train type/category, direction, train length

platform
Important for passenger trains.

So what do we choose when the meaning of <track> in infrastructure is something different? More generally, when do we use track, platform or stoppingPlace?

Best regards,
Stefan Hubrig

Thales Deutschland
Phone: + 49 30 688306 410
Mobile: + 49 172 82 81 426
------------------------------------------------------------ --
Thales Deutschland GmbH
Schuetzenstrasse 25 10117 Berlin Germany
------------------------------------------------------------ --
www.thalesgroup.com
------------------------------------------------------------ --

Sitz der Gesellschaft/Domicile of the Company: Stuttgart
Amtsgericht/District Court: Stuttgart HRB 728793
Geschäftsführer/Managing Directors:
Dr. Christoph Hoppe (Vorsitzender/Chairman), Dirk J.H. de Bruijn, Dr. Yves Joannic, Jens Nielsen

Re: Definition of track/stoppingPlace/platform infrastructure vs. timetable [message #2253 is a reply to message #2252] Mon, 07 October 2019 20:28 Go to previous messageGo to next message
christian.rahmig is currently offline  christian.rahmig
Messages: 260
Registered: January 2016
Senior Member
Dear Stefan,

thank you for your contribution on the question "What is a track?".

Am 02.10.2019 um 17:00 schrieb Stefan Hubrig:
> [...]
> <xs:documentation>A Track is defined by a railway section
> between two switches/crossings or between a switch/crossing
> and a buffer stop.</xs:documentation>
>
> Does this definition cover tracks in the context of
> timetables? For those, we would want to describe where the
> train stops inside an operationalPoint. In that case, there
> would be a single line track through many operationalPoints
> since there is no switch. What would <track> <length> refer
> to?
>
> If <track> is not the right fit here, what would we choose
> instead?

Following several talks with different railML users and contributors I
can agree that the current definition of a railML <track> seems to be
too strict for certain applications/use cases. There are scenarios like
yours with very long tracks that span over several operational points
and connected switches. On the other side, there are scenarios with very
short tracks or "track sections". In both cases, the constraint that
tracks range from switch/crossing/buffer stop until
switch/crossing/buffer stop, does not match.

My question to the whole community:
Would you like to modify the definition of a railML <track> by removing
the constraints?

How to continue then? Is there an optimal definition of a <track>? Here
is my proposal:
There may be a hierarchy of <track> elements: A very short <track>
section may refer to a longer parent <track> via the attribute
@belongsToParent. And this longer <track> may refer to a very long
parent <track> spanning over several operational points again via the
attribute @belongsToParent.

The advantage of this approach: we are able to model all kind of tracks
- from very short to very long. The disadvantage: more freedom on the
model requires more constraints on the use case side in order to
guarantee compatibility of export and import interfaces. In particular,
each use case shall define what kind of <track> elements it expects.

Dear community, how do you like this proposal?

> For most timetable applications it is sufficient to know on
> which "track" of the operational point the train will stop
> (or pass). But a more specific description could be either
> of:
> •     stoppingPosition (currently not in railML) Describes where the
> front of the train stops
> important parameters for compatibility with a train: train
> type/category, direction
>
> •    stoppingPlace
> Refers to the train stop position with the length
> important parameters for compatibility with a train: train
> type/category, direction, train length
>
> •    platform
> Important for passenger trains.
>
> So what do we choose when the meaning of <track> in
> infrastructure is something different? More generally, when
> do we use track, platform or stoppingPlace?

Sorry, but I did not get the difference between a "stoppingPosition" and
a "stoppingPlace". railML 3.1 already knows the <stoppingPlace> element,
which defines the place where trains may stop (with their head).
Further, you may define the stop post panel by using the <signal>
element with child element <isStopPost>.

The <platform> element is relevant for use cases related to the exchange
of passengers in a station. For example, the height of a platform edge
may be relevant for evaluating the access of the train with wheel
chairs. Another example may be the side of the platform edge in relation
to the orientation of the track in order to tell the passengers the
right side of exit. To cut the story short: the choice between elements
<platform>, <track> and <stoppingPlace> depends on the use case specific
requirements. The railML data model provides the syntax for all
different solutions.

Best regards
Christian

--
Christian Rahmig - Infrastructure scheme coordinator
railML.org (Registry of Associations: VR 5750)
Phone Coordinator: +49 173 2714509; railML.org: +49 351 47582911
Altplauen 19h; 01187 Dresden; Germany www.railml.org


Christian Rahmig - Infrastructure scheme coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org
Re: Definition of track/stoppingPlace/platform infrastructure vs. timetable [message #2268 is a reply to message #2253] Thu, 07 November 2019 14:33 Go to previous messageGo to next message
christian.rahmig is currently offline  christian.rahmig
Messages: 260
Registered: January 2016
Senior Member
christian.rahmig wrote on Mon, 07 October 2019 20:28
Dear Stefan,

thank you for your contribution on the question "What is a track?".

Am 02.10.2019 um 17:00 schrieb Stefan Hubrig:
> [...]
> <xs:documentation>A Track is defined by a railway section
> between two switches/crossings or between a switch/crossing
> and a buffer stop.</xs:documentation>
>
> Does this definition cover tracks in the context of
> timetables? For those, we would want to describe where the
> train stops inside an operationalPoint. In that case, there
> would be a single line track through many operationalPoints
> since there is no switch. What would <track> <length> refer
> to?
>
> If <track> is not the right fit here, what would we choose
> instead?

Following several talks with different railML users and contributors I
can agree that the current definition of a railML <track> seems to be
too strict for certain applications/use cases. There are scenarios like
yours with very long tracks that span over several operational points
and connected switches. On the other side, there are scenarios with very
short tracks or "track sections". In both cases, the constraint that
tracks range from switch/crossing/buffer stop until
switch/crossing/buffer stop, does not match.

My question to the whole community:
Would you like to modify the definition of a railML <track> by removing
the constraints?
In order not to forget about this issue to be solved with railML 3.2 I created Trac ticket #368, see https://trac.railml.org/ticket/368. Still, I would like to hear your opinion about the best definition of a track.

Thank you very much and best regards
Christian

--
Christian Rahmig - Infrastructure scheme coordinator
railML.org (Registry of Associations: VR 5750)
Phone Coordinator: +49 173 2714509; railML.org: +49 351 47582911
Altplauen 19h; 01187 Dresden; Germany www.railml.org


Christian Rahmig - Infrastructure scheme coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org
Re: Definition of track/stoppingPlace/platform infrastructure vs. timetable [message #2293 is a reply to message #2268] Fri, 13 December 2019 15:16 Go to previous message
Thomas Langkamm is currently offline  Thomas Langkamm
Messages: 6
Registered: April 2019
Junior Member
We had some discussions in the SCTP groups regarding the track definition, and agree that we should have no hard restriction regarding the end of the track. We do want to allow "long tracks" that extend over several operational points.

Thus, we suggest to change the definition to "A track is a railway section that can be traversed by a train in a continuous motion."

Additional documentation in the wiki could be:
A track may contain switches and signals. A track is an object with a mandatory type and optional attributes, typically a name, a main direction and a reference to an infrastructure manager. It may also have an associated linear positioning system (kilometrization). A track may be defined locally, where tracks start and end at buffer stops, switches, signals or the boundaries of an operation point, or globally, where tracks may continue over long distances and contain switches.

And to elaborate further, here's something for best practices:
In a microscopic model, a track is typically defined on one netElement or on a collection of netElements. If a track is defined as a collection of netElements, they must be connected and circle free in a graph theoretical sense.

We have discussed whether we should give a more restrictive definition but found use cases we might not have an infrastructure element at all, for example in a timetable environment where we care only about tracks and not about switches or signals.
Previous Topic: [railML 3.2] extending the <balise> element
Next Topic: [railML2] @dir
Goto Forum:
  


Current Time: Mon Mar 30 12:57:45 CEST 2020