| [RailML3] Renaming Track into UsagePattern [message #2502] |
Fri, 24 July 2020 11:50  |
Stefan Wegele
Messages: 4
Registered: November 2016
|
Junior Member |
|
|
Dear all,
the element <track> covers two independent concepts:
- navigation per definition (A Track is defined by a railway section between two switches/crossings ...)
- usage pattern - main, secondary, siding and main usage direction.
Assume the application importing the RailML file should find a train path. Now it can use two different approaches:
- NetElements with NetRelations
- Track and TrackNodes (introduced with track/trackBegin and track/trackEnd)
This requires, that in each file NetElements and Tracks cover the entire network identically - otherwise the applications would create different paths depending on the used approach.
To prevent this situation, I would propose to remove navigability from the Track-definition. The first step would be renaming of Track, as it imposes navigability from RailML-2, into UsagePattern. The application creating paths for trains would have to use NetElements and consult functionalInfrastructure for UsageType, UsageDirection, Gauge etc. for each NetElement it traverses.
Example:
<usagePattern type="main" mainDir="up" owner="DB">
<netElementRef ref="ne_1"/>
...
<netElementRef ref="ne_100"/>
</usagePattern>
<usagePattern type="siding" mainDir="both" owner="SNCF">
<netElementRef ref="ne_101"/>
...
<netElementRef ref="ne_200"/>
</usagePattern>
Regards
Stefan Wegele
|
|
|
|
| Re: [RailML3] Renaming Track into UsagePattern [message #2504 is a reply to message #2502] |
Fri, 24 July 2020 14:51  |
christian.rahmig
Messages: 458
Registered: January 2016
|
Senior Member |
|
|
Dear Stefan,
welcome to the railML forum and thank you for you input.
I don't see any problems in railML 3 implementation of the track element. Here are my arguments:
* In contrast to railML 2, the <track> in railML 3 does not cover the navigation perspective, since this is completely defined in topology domain using <netElement> and <netRelation> elements.
* The definition of a track has been widened: it is no longer only defined as a railway section between two switches / crossings / bufferStop. In Trac ticket #368 [1] a track is defined as "a railway section that can be traversed by a train in a continuous motion", which allows for very short tracks as well as for very long tracks (that may pass several switches...).
Renaming "track" into sth like "usagePattern" does not seem to bring any benefits. On the contrary, I see quite a high potential for conflicts and misunderstandings: in fact, any infrastructure element can have sth like a "usage pattern". I would interprete this in the sense "how sth is used"...
However, names can be discussed, but there is another main issue about your proposal: "renaming" <track> into <usagePattern> cannot be considered as a minor version modification. I am afraid, we are then talking about railML 4 instead of railML 3.2.
What does the community think about the topic?
Best regards
Christian
[1] https://trac.railml.org/ticket/368
Christian Rahmig – Infrastructure scheme coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org
|
|
|
|
| Re: [RailML3] Renaming Track into UsagePattern [message #2505 is a reply to message #2504] |
Fri, 24 July 2020 18:41 |
Stefan Wegele
Messages: 4
Registered: November 2016
|
Junior Member |
|
|
Hello Christian,
agree, the term usagePattern is too broad. Perhaps it could be TrackUsagePattern, so it can be read as "usage pattern of a track".
If we say, the <track> is a railway section that can be traversed by a train in a continuous motion and we give it an ID, we create a second-layer-graph. Any train path can be defined by a list of <track>.ids. I would call this "navigability".
To prevent that, we could remove the ID-attribute, so nobody can use it for referencing. In addition we could relax the definition to "it defines functional track attributes for a subset of the network". In this case we could keep the naming <track>.
Of cause we could claim - don't use Tracks for path definitions (navigation), but this was the default way of doing in RailML2. Applications which should be ported to RailML3 would try it with the well-known element <track> first.
Best regards
Stefan
|
|
|
|
Members
Search
Help
Login
Home
