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: 20
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: 474
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: 20
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: 49
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 messageGo to next message
christian.rahmig is currently offline  christian.rahmig
Messages: 474
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
Re: Level crossing with extended information [message #3320 is a reply to message #3007] Wed, 11 September 2024 16:19 Go to previous messageGo to next message
Larissa Zhuchyi is currently offline  Larissa Zhuchyi
Messages: 49
Registered: November 2022
Member
Dear all

railML.org prepared a first version of implementation of this request. You can find the screenshots in the GitLab [1]. Please answer:

1) Does this modeling [1] fulfill the requirement?
2) Wouldn't it make sense to make <roadSideBarriers> and <roadSideLights> children of <functionalInfrastructure>? Consequently <levelCrossingIS> will need to refer to them somehow.

The reasoning for the second question is that this modeling seems to be a first occurrence of both parent (<levelCrossingIS>) and child (<roadSideBarriers>) each having their own location.

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

Sincerely,


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 #3322 is a reply to message #3320] Mon, 16 September 2024 09:48 Go to previous messageGo to next message
christian.rahmig is currently offline  christian.rahmig
Messages: 474
Registered: January 2016
Senior Member
Dear Larissa,

regarding 2)
The question to be answered here is: Can a roadSideBarrier or a roadSideLight exist without a levelCrossing. If there is no situation, where we have a roadSideBarrier in our data, but no levelCrossing, I propose to follow the approach described in [1] with roadSideBarrier and roadSideLight being child elements of \\levelCrossingIS\protection.

So, dear community, what is your feedback?

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 #3371 is a reply to message #3322] Mon, 21 October 2024 14:20 Go to previous messageGo to next message
Georg Boasson is currently offline  Georg Boasson
Messages: 20
Registered: October 2020
Junior Member
Dear all

As discussed in the ETCS Workgroup today (21/10 2024), another attribute for the <roadSideLights> is wanted together with the @roadSide attribute. The new attribute may be called @towardsTrack and will indicate the direction of the light. A light signal will normally point away from the track and towards the (road-/walkway-)traffic, but for pedestrians this light will often be place behind the railway-track to be crossed. An indication for the direction of the signal is therefore important for correct construction and operation.

Re: Level crossing with extended information [message #3387 is a reply to message #3371] Mon, 11 November 2024 14:09 Go to previous message
Dominik Looser is currently offline  Dominik Looser
Messages: 23
Registered: March 2020
Junior Member
Dear all,

I see that the additional attribute @towardsTrack was handled in GitLab ticket 588.
However, I cannot find a new attribute in <levelCrossingIS>/<protection>/<roadSideLights>.
Am I missing something here or is this still missing?

Thank you and best regards,
Dominik
Previous Topic: railML3 suggestion to add values for @detects in IS:detector
Next Topic: [railML 3.2] Modelling of Scheduling Rules
Goto Forum:
  


Current Time: Thu Dec 05 14:41:47 CET 2024