| [railML3] Extensions to the Modelling of Signals [message #3750] |
Tue, 14 October 2025 10:22  |
Georg Boasson
Messages: 21
Registered: October 2020
|
Junior Member |
|
|
We very much like to extend the modelling of signals with two more options. Both options are related to the physical location of signals.
1) One signal (or group og signals) may be valid for several tracks
One physical signal may be valid for several tracks. Example: A stop post signal may be placed between two tracks with arrows showing that this signal is valid for both tracks.
See example with a Stop post signal between two tracks (Stopping Place.pdf)
May be this scenario could be solved by using several <spotLocation> for the <signalIS>?
2) Signals belonging to different tracks (referenced to different netElements) may be located at the same mast (pole, gantry, etc)
Several different signals may be placed together due to limited space. A possible example here may be two ETCS markerboards placed at the same pole but valid for differnet tracks.
See example with two signals placed together on a single mast (Markerboards on same pole.df / Sira station)
Maybe the subelement <signalConstruction> can be extended with a possibility for different signals on the same mast as mention in Forum post #2786?
Can the pole itself be an element? Or with a reference to a @mountedTogether attribute?
See also #3097 for other related topics of the modelling of signals.
|
|
|
|
| Re: [railML3] Extensions to the Modelling of Signals [message #3753 is a reply to message #3750] |
Wed, 15 October 2025 10:02  |
Mathias Vanden Auweele
Messages: 72
Registered: February 2025
Location: Brussels
|
Member |
|
|
Hello Georg,
1) Yes, for a signal that is applicable on several tracks, you need to create 2 SpotLocations for that one signal. The modelling of RTM allows for this. There is an example in the RTM wiki, look for "clearing post":
https://wiki.railtopomodel.org/wiki/Object_positioning_in_th e_network
2) I think it's a good idea to extend railML to support your use case. I can think of some alternatives on how to model this in railML 3.4:
- option 1: a new type 'Gantry' can be added to the <overCrossing> element and an optional @overCrossingRef added to <signalConstruction>, that would also allow a <SignalIS> to be linked to a <signalConstruction> linked with a bridge.
- option 2: a new element <supportConstruction> with a similar @supportConstructionRef added to <signalConstruction>
- option 3: add the ability to use <designators> in <signalConstruction> and use external designators
- option 4: add a @genericAreaRef to <signalConstruction>
Mathias Vanden Auweele
Railway data freelancer
https://matdata.eu
Brussels, Belgium
|
|
|
|
Members
Search
Help
Login
Home
