Home » railML newsgroups » railML.infrastructure » [RailML3] Renaming Track into UsagePattern (Duplication of the concepts NetElement & Track)
[RailML3] Renaming Track into UsagePattern [message #2502] Fri, 24 July 2020 11:50 Go to next message
Stefan Wegele is currently offline  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 Go to previous messageGo to next message
christian.rahmig is currently offline  christian.rahmig
Messages: 436
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 Go to previous message
Stefan Wegele is currently offline  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
Previous Topic: [railML3] Request for extension of the 'crossing' infrastructure element
Next Topic: [railML3.1] applicationDirection and placing of elements
Goto Forum:
  


Current Time: Thu Mar 28 19:14:53 CET 2024