| Level crossing with extended information [message #3007] |
Thu, 02 June 2022 09:25  |
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  |
christian.rahmig
Messages: 436
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
|
|
|
|
|
|
|
|
|
|
Members
Search
Help
Login
Home
