Home » railML newsgroups » railML.infrastructure » Level crossing with extended information (Proposal for additional elements for barriers and lights towards the crossing)
Level crossing with extended information [message #3007] Thu, 02 June 2022 09:25 Go to next message
Georg Boasson is currently offline  Georg Boasson
Messages: 18
Registered: October 2020
Junior Member
The proposed additional elements <barrier> and <light> must at least include name and position of barriers and lights towards the crossing.
See the attached document for more details and an example with a level crossing consisting of both a road and walkway with several barriers and lights.
Re: Level crossing with extended information [message #3018 is a reply to message #3007] Tue, 14 June 2022 14:05 Go to previous messageGo to next message
christian.rahmig is currently offline  christian.rahmig
Messages: 447
Registered: January 2016
Senior Member
Dear Georg,

thank you very much for the detailed document with your needs and requirements for the level crossing model. Before I comment on your ideas for a more detailed modelling of barriers (described on pages 6-7), I first want to answer your questions on page 3:

"Is it possible to define both the middle of each level crossing together with the start and end of the road and walkway in the same railML Infrastructure file or must another length attribute be defined as in railML2.4nor?"

For the example depicted in the bottom of page 2 of your document, I suggest to define three level crossings: one for the road, one for the walkway, and one as the joint parent level crossing for both. Grouping both level crossings together in a joint parent level crossing is useful, especially when both level crossings are controlled together from a signalling perspective. Both level crossings - the one for the road and the one for the walkway - should have a <spotLocation> and a <linearLocation> each. The <spotLocation> describes the center point of each crossing. The <linearLocation> shall be used to define the exact "crossing area" (begin of road until end of road; and begin of walkway until end of walkway).

"Can both <spotLocation> and <linearLocation> be used for the same level crossing element?"

Yes, like any other functional infrastructure element, the <levelCrossingIS> can have multiple location child elements, e.g. a <spotLocation> for the center point and a <linearLocation> for the projected crossing area.

Barriers

Existing element <levelCrossingIS / protection> provides a summary of the technical level crossing protection system including the general types of barriers in attribute @barriers. If we want to model barriers in more detail, we have to define them as own placable infrastructure elements. For this, I see two options:

1) Define a child element <levelCrossingIS / barriers> that acts as container for a number of <barrier> elements.
2) Define a new type of functional infrastructure element in <functionalInfrastructure / barriers> containing a number of <barrier> elements.

In both cases, I suggest that <barrier> shall inherit from the datatype FunctionalInfrastructureEntity that comes along with all the location child elements for referencing the barrier with the topology network.

For defining the side of the barrier location related to the road, I agree to model it based on the constraint that this always refers to the orientation towards the level crossing. The wording "sideOfCrossing" does maybe not clearly enough describe the situation. I suggest an attribute @sideOfRoad or @roadSide instead. Possible values are "left" and "right".

Lights

The approach for the signal lights can be similar like for the barriers: Lights can be modelled as <light> elements that can be located as own infrastructure elements with absolute coordinates as well as linked with the topology.

Something to be further discussed here in the forum: Shall there be a common base model for detailed light signal elements, no matter if they are applicable for the road transport (see level crossing protection) or applicable for the railways (see current element <signalIS>)? When talking about number of bulbs or colours or flashing vs constant lights, both worlds (road and railway) are quite similar. So, I am very interested in your ideas and comments for various implementation approaches.

As usual, any comment and contribution from the railML community is highly appreciated...

Best regards
Christian


Christian Rahmig – Infrastructure scheme coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org
Re: Level crossing with extended information [message #3060 is a reply to message #3007] Wed, 15 March 2023 09:45 Go to previous messageGo to next message
Georg Boasson is currently offline  Georg Boasson
Messages: 18
Registered: October 2020
Junior Member
Re-uploaded the attached file, since it was corrupted
Re: Level crossing with extended information [message #3105 is a reply to message #3060] Thu, 06 July 2023 16:12 Go to previous messageGo to next message
Larissa Zhuchyi is currently offline  Larissa Zhuchyi
Messages: 38
Registered: November 2022
Member
Dear all

As no one has commented anything against this extension for a year railML.org will bring it as a ticked for the railML 3.3 development.

Regarding the modelling issues of the <signalIS> element, just now new form posts were launched [1, 2] as the general railway signal model railML 3 appeared to be rather ill-defined and is under revision by the railML coordinators. railML.org will bring questions about the number of bulbs and flushing next meeting.

[1] https://www.railml.org/forum/index.php?t=msg&th=911& start=0&
[2] https://www.railml.org/forum/index.php?t=msg&th=899& start=0&

Sincerely,
Larissa Zhuchyi


Larissa Zhuchyi – Ontology Researcher
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org
Re: Level crossing with extended information [message #3122 is a reply to message #3105] Mon, 04 September 2023 10:24 Go to previous message
christian.rahmig is currently offline  christian.rahmig
Messages: 447
Registered: January 2016
Senior Member
Dear Georg, dear all,

the ticket for including the level crossing barrier topic inside railML 3.3 development can be found in [3].

[3] https://development.railml.org/railml/version3/-/issues/515

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: @keepsOrientation in Track object
Next Topic: [railML3] Restrictions
Goto Forum:
  


Current Time: Thu Jul 25 20:19:43 CEST 2024