Home » railML newsgroups » railML.infrastructure » [railML3] LevelCrossing Best Practice Example
[railML3] LevelCrossing Best Practice Example [message #2994] Mon, 04 April 2022 18:25 Go to next message
Heidrun Jost is currently offline  Heidrun Jost
Messages: 25
Registered: September 2006
Junior Member
Dear all,

Thales wanted to give another example for the modeling of a level
crossing. We discussed Georg's example, which used the infrastructure.

Here is an example with the infrastructure in combination with the
interlocking layer. While the infrastructure layer maps the objects on a
graph (netElements) and there are few possibilities to create
associations between different infrastructure objects, interlocking
layer often offers this possibility. The linking of the elements follows
here the business logic. This is the reason that a level crossing (IL)
is connected to tracks (IL) and these tracks (IS) are then mapped onto
"netElements".

Example for a level crossing over two track in the railML3 file:
<!--infrastructure layer -->
<infrastructure>
    ...
     <levelCrossingIS id="uvAn5AZZsL7flbwHdRjDkca">
         <name name="GRM LX_3GRM" language="en"/>
         <designator register="costId" entry="LevelCrossing:BGS_GRM_LX_3"/>
         <designator register="sci_cc" entry="NO_A29_GRMLCSLX_3___"/>
     </levelCrossingIS>
    ...
    <track id="GBQBJs3oZDo85PZD8zlOl9g8" type="other:levelCrossingTrack">
         <name name="GRM LX_3_1GRM" language="en"/>
         <linearLocation id="LL_GBQBJs3oZDo85PZD8zlOl9g8">
            <associatedNetElement 
netElementRef="ZHiQjsi8DUialCTNQdA3yWb" intrinsicCoordBegin="0.625003" 
intrinsicCoordEnd="0.832348" keepsOrientation="true"/>
         </linearLocation>
         <designator register="sci_cc" entry="NO_A29_GRMLCTLX_3_1_"/>
         <designator register="costId" 
entry="TrackSection:LCT_BGS_GRM_LX_3_1"/>
     </track>
     ...
     <track id="Le4nO6kfrraNS2HpJnZHk1b" type=" other:levelCrossingTrack ">
         <name name="GRM LX_3_2GRM" language="en"/>
         <linearLocation id="LL_Le4nO6kfrraNS2HpJnZHk1b">
             <associatedNetElement 
netElementRef="xs4TeJZDctCaMRt47ZZVpYJ8" intrinsicCoordBegin="0.518872" 
intrinsicCoordEnd="0.642698" keepsOrientation="true"/>
         </linearLocation>
         <designator register="sci_cc" entry="NO_A29_GRMLCTLX_3_2_"/>
         <designator register="costId" 
entry="TrackSection:LCT_BGS_GRM_LX_3_2"/>
     </track>
     ...
</infrastructure>

<!--Interlocking layer - ->
<interlocking>
    ....
     <trackIL id="IL_GBQBJs3oZDo85PZD8zlOl9g8" >
         <designator register="station" entry="GRM"/>
         <belongsToOperationalPoint ref="iv4E2FZDsZDyaVN89pt39wx9"/>
         <hasCommand ref="Z4mQSBWmchOeaRCiy06j7ba"/>
         ...
         <refersTo ref="GBQBJs3oZDo85PZD8zlOl9g8"/>
         <hasTvdSection ref="TVD_OoA0orA5Rj3qNI03sc3oZZa"/>
     </trackIL>
     ...
     <trackIL id="IL_Le4nO6kfrraNS2HpJnZHk1b">
        <designator register="station" entry="GRM"/>
        <belongsToOperationalPoint ref="iv4E2FZDsZDyaVN89pt39wx9"/>
        <hasCommand ref="Z4mQSBWmchOeaRCiy06j7ba"/>
           ...
        <refersTo ref="Le4nO6kfrraNS2HpJnZHk1b"/>
        <hasTvdSection ref="TVD_VSQ5ZDtBJ9D7sokZDJzh1Ee8"/>
     </trackIL>
    ...
     <levelCrossingIL id="IL_uvAn5AZZsL7flbwHdRjDkca" 
typicalTimeToClose="PT0S">
         <designator register="station" entry="GRM"/>
         <hasCommand ref="Z8PQrlSVKRb5MGOYTiZDFRfb"/>
         ...
         <isLevelCrossingType ref="lcr_type5"/>
         <refersTo ref="uvAn5AZZsL7flbwHdRjDkca"/>
         <hasLevelCrossingTrack ref="IL_GBQBJs3oZDo85PZD8zlOl9g8"/>
         <hasLevelCrossingTrack ref="IL_Le4nO6kfrraNS2HpJnZHk1b"/>
     </levelCrossingIL>
     ...
     <specificInfrastructureManager ref="infrastructure_01">
         <usesTypes>
             ...
             <hasLevelCrossingType id="lcr_type5" 
controlType="fullControlled" hasBarrier="true" hasTrafficWarning="true"/>
     </specificInfrastructureManager>
    ...
</interlocking>
For this solution we have a wish: If a track only exists (gets an extra
name) because it belongs to a level crossing, you should be able to
recognize this via the 'type' attribute at <track>. We would want to use
the value 'levelCrossingTrack' for that attribute or have the
possibility to use our own extensions with "other:levelCrossingTrack".

Would it be possible to add an "other" extension in railML 3.2 to the
attribute "type" of the track in order to be able to define your own types?

Best regards,
--
Heidrun Jost
Data Manager TMS Norway
Transportation Systems
Thales Deutschland GmbH

Phone: +49 (0) 30 688306 423
Schützenstr. 25 10117 Berlin Germany

[Updated on: Tue, 05 April 2022 16:18] by Moderator

Report message to a moderator

Re: [railML3] LevelCrossing Best Practice Example [message #2997 is a reply to message #2994] Thu, 07 April 2022 14:57 Go to previous messageGo to next message
christian.rahmig is currently offline  christian.rahmig
Messages: 436
Registered: January 2016
Senior Member
Dear Heidrun,

the topic you raised is not that simple as it seems in the beginning.

The biggest issue I see in the incomplete modelling approach from infrastructure perspective: In the example you provided the exact location of the level crossing remains unclear when only looking at infrastructure domain. The connection between the infrastructure element "levelCrossingIS" and the topologic railway network is provided only with the interlocking element "levelCrossingIL". This "detour" is not good thinking of use cases that include only infrastructure and disregard interlocking.

Therefore, I strongly recommend to use one (or more) linear location(s) to link the <levelCrossingIS> with the underlaying topology built by NetElements.

Regarding the new track type "levelCrossingTrack" you were proposing: Having linked the <levelCrossingIS> with the <netElement> instances covered, there is no need to tag a track as being a "level crossing track", because the information is implicitly given in the linking. As written in the wiki documentation [1] the attribute <track>@type is used to describe the general functionality of the track. The existing values "mainTrack", "secondaryTrack", "sidingTrack" and "connectingTrack" are complementary, whereas a "level crossing track" is basically a combination of one of the mentioned track types with a level crossing. Therefore, I don't like to integrate "level crossing track" into the <track>@type enumeration.

So, what does the community think about this topic?

[1] https://wiki3.railml.org/wiki/IS:track

Best regards
Christian


Christian Rahmig – Infrastructure scheme coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org
Re: [railML3] LevelCrossing Best Practice Example [message #3002 is a reply to message #2997] Fri, 22 April 2022 20:43 Go to previous messageGo to next message
Torben Brand is currently offline  Torben Brand
Messages: 156
Registered: March 2016
Senior Member
I agree with Christian in this matter.

--
TOBR
Re: [railML3] LevelCrossing Best Practice Example [message #3051 is a reply to message #3002] Mon, 13 February 2023 09:31 Go to previous message
christian.rahmig is currently offline  christian.rahmig
Messages: 436
Registered: January 2016
Senior Member
Dear all,

based on the feedback provided by the community, I anticipate that the level crossing issue you raised is rather Thales-specific. Following the arguments of my forum post I conclude that level crossings shall not be modelled with "level crossing tracks" extension, but that the existing schema is sufficient for a detailed level crossing model solution.

Best regards
Christian


Christian Rahmig – Infrastructure scheme coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org
Previous Topic: Clustering of location information
Next Topic: [railML3] Proposal for removing "any" elements
Goto Forum:
  


Current Time: Fri Mar 29 07:12:54 CET 2024