Forum: railML.infrastructure » [railML3] Extensions to the Modelling of Signals

Home » railML newsgroups » railML.infrastructure » [railML3] Extensions to the Modelling of Signals (Two more options related to the physical location of signals)

Show: Today's Messages :: Show Polls :: Message Navigator
E-mail to friend

[railML3] Extensions to the Modelling of Signals [message #3750]

Tue, 14 October 2025 10:22

Georg Boasson
Messages: 24
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.

Attachment: Markerboards on same pole.pdf
(Size: 9.57KB, Downloaded 86 times)
Attachment: Sira station.pdf
(Size: 40.47KB, Downloaded 113 times)
Attachment: Stopping Place.pdf
(Size: 40.17KB, Downloaded 85 times)

Report message to a moderator

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 is currently offline

Mathias Vanden Auweele
Messages: 140
Registered: February 2025
Location: Brussels

Senior 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

Report message to a moderator

Re: [railML3] Extensions to the Modelling of Signals [message #3816 is a reply to message #3753]

Fri, 05 December 2025 18:22

Martin Zien
Messages: 15
Registered: December 2021

Junior Member

Hello,

regarding topic 1) I would agree to follow the implementation as it is in RTM by now.

regarding topic 2)
Mathias' Option 1: This could be further followed up for modeling of Gantries and Signals applied to Gantries. But it's not covering all the use cases of Georg.

Mathias' Option 2: Sounds quite plausible. There are some detailing questions open:
Where would you see such <supportConstruction> be located in railML: In parallel to <signalsIS> (would allow to involve also support constructions for other purposes than signal mounting) or subordinated to <signalsIS>? Should it be limited to "special cases" as described by Georg, or may it be consequently needed for each and every signal?

Mathias' Option 3: Such <designnator> would then refer to an entry in a rule book (= Generic Type in a railway infrastructure) or an itm in a(public?) asset/inventory list of the Infrastrucutre Manager?

Mathias' Option 4: to me it's not clear, how that should work. More explanation is needed.

Report message to a moderator

Re: [railML3] Extensions to the Modelling of Signals [message #3817 is a reply to message #3816]

Mon, 08 December 2025 05:50

christian.rahmig
Messages: 566
Registered: January 2016

Senior Member

Dear all,

topic 1)
is solved as described by Mathias.

topic 2)
All the different options have their pros and cons, but one option is also missing: You can group signals together by @belongsToParent. The information that the signal is installed at a gantry can be modelled with <signalConstruction>@type="gantry".
In order to select the right option as best practice (including maybe also an extension of the schema), we need to conclude, which information about the gantry (or the pole) are necessary to know for the use case.

Best regards
Christian

Christian Rahmig – Infrastructure scheme coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org

Report message to a moderator

Re: [railML3] Extensions to the Modelling of Signals [message #3868 is a reply to message #3817]

Thu, 15 January 2026 12:45

Georg Boasson
Messages: 24
Registered: October 2020

Junior Member

Hello

One solution for "topic 2" may be to extend the <signalConstruction> element with a child element <mountedTogetherWith>. The purpose of this child element will be to reference other signal to be mounted together.

Ex: (<mountedTogetheWith ref="sig90"> will indicate that this signal is mounted together with the signal with id=sig90).

Best regards
Georg

Report message to a moderator

Re: [railML3] Extensions to the Modelling of Signals [message #3869 is a reply to message #3750]

Thu, 15 January 2026 15:33

Dominik Looser
Messages: 49
Registered: March 2020

Member

Hi,

I agree with the implementation of "topic 1".

I think that "topic 2" is technically the combination of "topic 1" and "combined signals" as discussed in [1].
The attachment in [1] states that combined signals - i.e. signals on the same pole - should be exported separately but also have an additional <signalIS> used as container. The individual signals would point to the container via the @belongsToParent attribute.
This has been introduced in railML 3.3 and implemented in our export.
"Topic 2" could thus be modelled as combined signals, but the <signalIS> used as container would have two <spotLocation> elements.

Example as proposal:

sig4 and sig5 are the two signals. sig4_C is the container for both signals, containing the two spotLocations of sig4 and sig5

<signalIS id="sig4_C">
  <spotLocation applicationDirection="normal" id="sig4_C_ips01" netElementRef="ne_3">
	<linearCoordinate lateralSide="right" measure="87.0" positioningSystemRef="ips01"/>
  </spotLocation>
  <spotLocation applicationDirection="normal" id="sig5_ips01" netElementRef="ne_4">
	<linearCoordinate lateralSide="left" measure="50.0" positioningSystemRef="ips01"/>
  </spotLocation>
</signalIS>
<signalIS belongsToParent="sig4_C" id="sig4" isSwitchable="false">
  <spotLocation applicationDirection="normal" id="sig4_ips01" netElementRef="ne_3">
	<linearCoordinate lateralSide="right" measure="87.0" positioningSystemRef="ips01"/>
  </spotLocation>
  <typeDesignator entry="E35d" rulebook="TJN"/>
  <elementState value="conceptual"/>
  <isEtcsSignal/>
  <isTrainMovementSignal/>
</signalIS>
<signalIS belongsToParent="sig4_C" id="sig5" isSwitchable="true">
  <spotLocation applicationDirection="normal" id="sig5_ips01" netElementRef="ne_4">
	<linearCoordinate lateralSide="left" measure="50.0" positioningSystemRef="ips01"/>
  </spotLocation>
  <typeDesignator entry="E35d" rulebook="ETCS"/>
  <elementState value="conceptual"/>
  <isEtcsSignal/>
  <isTrainMovementSignal/>
</signalIS>

Additional information like <signalConstruction> can still be added.

Looking forward to your thoughts on this.

Best regards,
Dominik Looser
trafIT solutions gmbh

[1] https://www.railml.org/forum/index.php?t=msg&goto=3202&a mp;&srch=combination#msg_3202

Report message to a moderator

Re: [railML3] Extensions to the Modelling of Signals [message #3920 is a reply to message #3869]

Fri, 06 March 2026 09:51

christian.rahmig
Messages: 566
Registered: January 2016

Senior Member

Dear Dominik,

your example is the correct approach to modelling signals belonging to different tracks, but installed at the same pole. Jörg described the concept of signal combinations in an earlier forum post [1] together with a nice visualization. I would probably add the <signalConstruction>@mountedOn="pole" to the container signal in the example.

So, to conclude: railML 3.3 already contains all the information needed to model the given signal combination examples. There is no need for further adaptations w.r.t. railML 3.4.

[1] https://www.railml.org/forum/index.php?t=msg&th=916& goto=3225&#msg_3225

Best regards
Christian

Christian Rahmig – Infrastructure scheme coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org

Report message to a moderator

Previous Topic:	[railML3] Modelling serviceSections
Next Topic:	[railML3] Additional Switch attributes

Goto Forum:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

] [

]

Current Time: Mon Jul 20 02:16:58 CEST 2026