| Level crossing with extended information [message #3007] |
Thu, 02 June 2022 09:25  |
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  |
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 #3320 is a reply to message #3007] |
Wed, 11 September 2024 16:19 |
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 |
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 #3387 is a reply to message #3371] |
Mon, 11 November 2024 14:09 |
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
|
|
|
|
Members
Search
Help
Login
Home
