Forum: railML.infrastructure » Turntable and Transfer table

Home » railML newsgroups » railML.infrastructure » Turntable and Transfer table (modelling of turntables)

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

Turntable and Transfer table [message #3685]

Tue, 05 August 2025 12:57

Torben Brand
Messages: 209
Registered: March 2016

Senior Member

Is there a way to modell railway turntables [1] and transfer tables [2] in railML3?
This for UC SCTP
See also attached image of a norwegian turntable.

[1] https://en.wikipedia.org/wiki/Railway_turntable
[2] https://en.wikipedia.org/wiki/Transfer_table

Attachment: Svingskive_Lillehammer.jpg
(Size: 243.21KB, Downloaded 144 times)

[Updated on: Thu, 07 August 2025 11:14]

Report message to a moderator

Re: Turntable and Transfer table [message #3687 is a reply to message #3685]

Thu, 07 August 2025 12:56

Torben Brand
Messages: 209
Registered: March 2016

Senior Member

After some inernal discussion we suggest that both should be a type of switch
Thus we suggest for railML3.4 to extend <switchIS@type> [3] with the enumeration values:
"turntable"
"transferTable" (or alternative "traverser")

Note that the multiplicity of the sub-element <turningBranch> then needs to be extended from (1,2) to (1,n)

I also noticed that a three way switch is missing. This is still in place in railML2.5 [4]
So we should also extend with the enumeration value:
"threeWaySwitch"

[3] https://wiki3.railml.org/wiki/IS:switchIS
[4] https://wiki2.railml.org/wiki/IS:switch

Report message to a moderator

Re: Turntable and Transfer table [message #3691 is a reply to message #3687]

Mon, 11 August 2025 12:20

christian.rahmig
Messages: 546
Registered: January 2016

Senior Member

Dear Torben,

thank you very much for your input for modelling turntables and transfer tables with railML.

Although I understand the basic idea behind, I am not convinced by your idea of modelling these items as switches. The reason: switch parameters like @branchCourse and @continueCourse, as well as child elements like <*Branch> and <locationReference> with @tangentLength are defined for switches and switch crossings and hardly match with turntables and transfer tables.

However, from functional perspective, switches, switch crossings and turntables and transfer tables can be seen as "track nodes" and therefore may have a common base class from which they derive.

But before discussing specific modelling approaches, let me ask the rest of the community: who else needs turntables and transfer tables and which information about these infrastructure objects are important for you to have?

Any feedback 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

Report message to a moderator

Re: Turntable and Transfer table [message #3695 is a reply to message #3691]

Tue, 12 August 2025 11:15

Terje Nordal
Messages: 21
Registered: December 2023

Junior Member

Dear Christian and Torben,

I can confirm that this is also something Bane NOR want to be able to model. In our case they are not part of any interlocking functionality, so maybe something for the schematic track plan use case? The minimum of what we need to model is the presence of the turntables/transfer tables in the first place. Our schematic track plans typically show these as on drawings, and we would like to be able to do the same in our work with railML. I am usually in the ETCS use cases myself, and would typically model them as part of the track layout but located outside the areas that the interlocking covers.

The approach to use "track nodes" for this sounds like a good direction, and the tracks going in and out could then be used to derive the configuration of the object. I cannot think of other types of information one would need, except the common ones like names, designators etc. Other stakeholdes may be able to elaborate, if they also see the need for this addition.

Best regards,
Terje

Report message to a moderator

Re: Turntable and Transfer table [message #3700 is a reply to message #3695]

Mon, 25 August 2025 10:33

Mathias Vanden Auweele is currently offline

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

Senior Member

I agree with Christian that using 'switchIS' for this is not a good solution. It would be better to define a seperate element class for it.

Transfer tables are are also part of the Belgian network and appear on track layout and signaling design.

Mathias Vanden Auweele
Railway data freelancer
https://matdata.eu
Brussels, Belgium

Report message to a moderator

Re: Turntable and Transfer table [message #3774 is a reply to message #3700]

Tue, 28 October 2025 08:51

Torben Brand
Messages: 209
Registered: March 2016

Senior Member

As discussed in railML workgroup for Bane NOR 28.10.2025:
- Need to model turntable in 3.4 acknowledged
- Do not model as switch. Model as separate <functionalInfrastructure> element
- For SCTP UC and not RTCI UC
- Please write down attributes required for the Turntable here in forum.
- ERTMS LSE requirement is only icon in SCTP drawing
- Other sub-UC might need the number of tracks and their length. This can be modelled with regular netElements (track edges) connected to track edge the turntable is on. Those track edges can have regular properties like a length and service sections attached to them.
- Turntable specific attributes might be, length of the track on the turntable, turning speed/time, other?
- To be discussed in next SCTP WG (3.11.2025)

Report message to a moderator

Re: Turntable and Transfer table [message #3819 is a reply to message #3774]

Mon, 08 December 2025 07:18

christian.rahmig
Messages: 546
Registered: January 2016

Senior Member

Dear all,

I set up a Gitlab issue for this topic to be implemented with railML 3.4 [1]. Until its implementation, we are looking forward to receiving more feedback here in the forum regarding requirements for the turn and transfer table model.

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

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: Turntable and Transfer table [message #3823 is a reply to message #3685]

Mon, 08 December 2025 16:17

Torben Brand
Messages: 209
Registered: March 2016

Senior Member

As discussed in SCTP WG 24.10.2025:

Model the track edge representation in a regular mannor with netElements (see illustration) for the entering track, turntable track and stabling tracks.

Have new element <turntable> (for both turntables and transfertables; as predominant form?) under <functionalInfrastructure> with the usual default sub elements like <name>, <designator>, <typeDesignator>, <elementState>, <linearLocation> etc.

Add an element specific attribute @transferTime (in seconds): "average time from the train can enter the turntable to it can leave the turntable to a stabling track that requires a turntable movement."

As there is a different icon for transfertables to turntables, should we have a boolean attribute @isTransferTable?

Attachment: Illustration turntable.png
(Size: 39.05KB, Downloaded 98 times)

[Updated on: Mon, 08 December 2025 16:23]

Report message to a moderator

Re: Turntable and Transfer table [message #3829 is a reply to message #3823]

Tue, 09 December 2025 15:53

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

Senior Member

I'm just thinking of how this relates to micro topology and NetRelation, in another forum post we discuss the need for non-navigable netrelations (to define them or not to). It only makes sense to define them if you can also state that a NetRelations deals with connectivity. Actual phsyical connections. Contrary to a switch, the different tracks of a (transfer|turn)table don't really touch. But you still want (navigable) netrelations defined between them. So this requires some clarification on the page defining netrelations. Some note on the exception of the connectivity rule.

Another alternative is to require the (transfer|turn)table to be defined as a micro topology non linear netelement. In which case the navigabilities is between the different tracks and the (transfer|turn)table instead of what's mostly the case, between the different tracks. But that might require some additional logic in software systems.

Mathias Vanden Auweele
Railway data freelancer
https://matdata.eu
Brussels, Belgium

Report message to a moderator

Re: Turntable and Transfer table [message #3831 is a reply to message #3823]

Tue, 09 December 2025 17:27

Thomas Nygreen
Messages: 111
Registered: March 2008

Senior Member

Dear all,

Like with switches, I do not consider a turntable to be a NetElement in itself, but a NetEntity used to navigate between NetElements. While turntables and transfer tables are not switches, we should use the same modelling principles for the topology. A separate linear netElement for every turntable would be similar to a separate linear netElement for every switch. I've attached an illustration where the turntable is placed in the same way as a double slip switch. There is a noticeable difference in the number of NetRelations. Notice that all relations are navigable. Therefore, if we think this the number of NetRelations is inconvenient, we could place a NetElement to represent (the center of) the turntable as a node, but this would then be a non-linear NetElement, working very much like a station in the mesoscopic topology.

From a topological view, there is no difference between turntables and transfer tables. They both connect all the entry points to each other. The key difference is that a turntable rotates, which gives the additional functionality of turning rolling stock around. So we could use a boolean attribute @rotates. But is there a common name that can be used for both turntables and transfer tables, or is it better to have two separate elements?

To keep track of the relative order of the connected NetElements (like the right and left in switches), both turntables and transfer tables need a way to reference the sequence of the connected NetElements, and perhaps also the position/angle.

Best regards,
Thomas

Attachment: double slip switch and turntable.png
(Size: 107.73KB, Downloaded 97 times)

Thomas Nygreen – Common Schema Coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org

Report message to a moderator

Re: Turntable and Transfer table [message #3834 is a reply to message #3831]

Thu, 11 December 2025 08:58

Dominik Looser
Messages: 44
Registered: March 2020

Member

Dear all,

I am in favor of Thomas' proposal to keep the modelling as close to (double slip) switches as possible.
Modelling it with a separate NetElement for the turning/moving part looks more like a nano-level-modelling and not similar to switch modelling.

Thomas Nygreen wrote on Tue, 09 December 2025 17:27

Dear all,
To keep track of the relative order of the connected NetElements (like the right and left in switches), both turntables and transfer tables need a way to reference the sequence of the connected NetElements, and perhaps also the position/angle.

We would appreciate that. The usage of an angle/orientation value is also proposed in [1] and could help here to define the sequence of the netElements.
I have attached a sketch of what the values could look like for turntables. Note that the actual exact values are not that important, as there is no clear horizontal axis.

/forum/index.php?t=getfile&id=192&private=0

/forum/index.php?t=getfile&id=192&private=0

For transfer tables however, we would still need to define which netRelations are on the same side of the transfer table.

Questions: Where on the topology would you locate such a turntable/transfer table element? And where in the schema could we place such an angle/orientation value?

[1] https://www.railml.org/forum/index.php?t=msg&th=1108& ;goto=3820

Best regards,
Dominik Looser
trafIT solutions gmbh

Attachment: Screenshot 2025-12-10 112942.png
(Size: 17.39KB, Downloaded 256 times)

[Updated on: Thu, 11 December 2025 08:59]

Report message to a moderator

Re: Turntable and Transfer table [message #3835 is a reply to message #3834]

Thu, 11 December 2025 15:14

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

Senior Member

Turntables are micro topologically a little different from switches in the sense that they can be used to rotate a vehicle. So there is a use case to define this as a non linear netelement, like an operational point would be in meso/macro. You can send a vehicle to it and get the vehicle back out through they same linear netelement without it passing through other linear netelements.

Mathias Vanden Auweele
Railway data freelancer
https://matdata.eu
Brussels, Belgium

Report message to a moderator

Re: Turntable and Transfer table [message #3921 is a reply to message #3835]

Fri, 06 March 2026 12:05

christian.rahmig
Messages: 546
Registered: January 2016

Senior Member

Dear all,

following discussions in SCTP working group and in BaneNOR workshop I updated the modelling solution proposal for turntables in Gitlab issue #683 [1].

Let me show you my idea by putting Dominik's figure from 2025-12-11 into source code example:

<turntable id="tut_01">
  <connectsWithTrack ref="trc_01" angle="0" />
  <connectsWithTrack ref="trc_02" angle="45" />
  <connectsWithTrack ref="trc_03" angle="180" />
  <connectsWithTrack ref="trc_04" angle="200" />
  <connectsWithTrack ref="trc_05" angle="330" />
  <branch netRelationRef="nr_0102" />
  <branch netRelationRef="nr_0103" />
  <branch netRelationRef="nr_0104" />
  <branch netRelationRef="nr_0105" />
  <branch netRelationRef="nr_0203" />
  <branch netRelationRef="nr_0204" />
  <branch netRelationRef="nr_0205" />
  <branch netRelationRef="nr_0304" />
  <branch netRelationRef="nr_0305" />
  <branch netRelationRef="nr_0405" />
</turntable>

One question to be clarified: do we really need the <branch> elements? Except for the reference to the topological netRelation elemnents, they provide no added value. What do you think?

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

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: Turntable and Transfer table [message #3931 is a reply to message #3921]

Mon, 09 March 2026 13:00

Dominik Looser
Messages: 44
Registered: March 2020

Member

Dear Christian,

Thank you for the proposal and we agree with it.
I think the <branch>-subelements are not necessary.

For transfer tables, we still need the information about the sequence of connected tracks, as well as which side of the transfer table they connect to.

Best regards,
Dominik Looser
trafIT solutions gmbh

Report message to a moderator

Re: Turntable and Transfer table [message #3963 is a reply to message #3931]

Thu, 16 April 2026 19:16

christian.rahmig
Messages: 546
Registered: January 2016

Senior Member

Dear Dominik, dear all,

I thought about the transfer table model and here comes my proposal, that pretty much aligns with the turntable approach (see [1]):

Like the <turntable>, the <transferTable> has an arbitrary number of child elements <connectsWithTrack> depending on the number of tracks being connected with the transfer table. The <connectsWithTrack> child element has a reference @trackRef to the related <track> element and the attribute @offset defining the lateral distance between the incoming track and the outgoing track in meters, whereas positive values indicate an offset to the left and negative values indicate an offset to the right of the incoming track. Further, the additional attribute @needsChangeOfDrivingDirection (boolean) tells us if the locomotive needs to change its driving direction on the transfer table coming from the incoming track in order to reach the outgoing track.

What is the "incoming track"? It is this track, which is located on the same <netElement> as the <transferTable> spot location. All other tracks are then "outgoing tracks".

Here comes a small example:

<transferTable id="trt_01">
  <connectsWithTrack ref="trc_01" offset="0" needsChangeOfDrivingDirection="true" />
  <connectsWithTrack ref="trc_02" offset="-4.8" needsChangeOfDrivingDirection="true" />
  <connectsWithTrack ref="trc_03" offset="4.8" needsChangeOfDrivingDirection="false" />
  <connectsWithTrack ref="trc_04" offset="9.6" needsChangeOfDrivingDirection="false" />
  <connectsWithTrack ref="trc_05" offset="0" needsChangeOfDrivingDirection="false" />
</transferTable>

Can anyone from the community verify that this example transfer table can unambiguously be layouted?

Thank you very much for your feedback!

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

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: Turntable and Transfer table [message #3968 is a reply to message #3963]

Sun, 19 April 2026 21:16

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

Senior Member

I think the <branch netRelationRef="xxx" /> elements are required. The foundation of railML is the topology. It is not required to define tracks. And sometimes track definitions are also missing or ambiguously defined for the netelements of a turn/transfer table. So in order to avoid falling back into the railml2 world, I would not use <connectsWithTrack> with a ref to a track but <branch> with a reference to netrelations. That immediately makes the turn/transfer tables more aligned with switches and crossings.

Furthermore, there can be multiple incoming tracks on a turntable. I think the most appropriate method to define the reference for the offset or the angle is to replicate what is being done for <switchIS> when defining left and right, to use the spotlocation as the point of reference.

Mathias Vanden Auweele
Railway data freelancer
https://matdata.eu
Brussels, Belgium

Report message to a moderator

Re: Turntable and Transfer table [message #3974 is a reply to message #3968]

Tue, 21 April 2026 09:34

Dominik Looser
Messages: 44
Registered: March 2020

Member

Dear all,

Thank you Christian for the proposal and Matthias for the objection.

If we use <branch> instead of <connectsWithTrack> this would mean that we would have to define the angles for each netRelation. I understand that this would align well with the <switchIS>-modelling, but it would also mean calculating a lot of redundant data. After all, the only thing we need is the order of branches, not the actual angle.
On the other hand, I understand the point that tracks do not always need to be defined, so maybe we should reference the netElements directly?

Thus my (minimalistic) counter-proposals: (naming to be discussed)

Turntables

<turntable id="tut_01">
  <connectedTo ref="ne_01" sequence="0" />
  <connectedTo ref="ne_02" sequence="1" />
  <connectedTo ref="ne_03" sequence="2" />
  <connectedTo ref="ne_04" sequence="3" />
  <connectedTo ref="ne_05" sequence="4" />
</turntable>

The order of the sequence should be defined as counter-clockwise. (documentation or semantic constraint?)

Transfer tables

<transferTable id="trt_01">
  <connectedTo ref="ne_01" sequence="0" side="A" />
  <connectedTo ref="ne_02" sequence="1" side="A" />
  <connectedTo ref="ne_03" sequence="0" side="B" />
  <connectedTo ref="ne_04" sequence="1" side="B" />
  <connectedTo ref="ne_05" sequence="2" side="B" />
</transferTable>

The order of the sequence should be defined as going from left to right, from both sides (i.e. counter-clockwise). (documentation or semantic constraint?)

I am looking forward to your feedback.

Best regards,
Dominik Looser
trafIT solutions gmbh

Report message to a moderator

Re: Turntable and Transfer table [message #3975 is a reply to message #3974]

Tue, 21 April 2026 10:00

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

Senior Member

Yes, referencing the netelement directly is a better approach than referencing the netrelations. As there will be many netrelations, not only between the 'incoming' track and the outgoing ones but also between the others.

And if you think it is sufficient to specify sequences and sides instead of angles and offsets in order to draw a schematic layout, then that's also fine for me.

Here are a couple of schematic track plans with turn/transfer tables:

Turntable:
https://www.banenor.no/contentassets/3b8bd8220a8a410cb9b5535 eeeadb429/lodalen.png
https://www.banenor.no/contentassets/35679e1fc8754fdc94aa071 6a5f53a21/kongsberg-stasjon.png
https://www.banenor.no/siteassets/bane-nor-sf/stasjonssider- felles-innhold/sporplan-stasjoner/-e-/egersund-stasjon_ko-00 2593-000-egersund_bane-nor.png

Transfer table:
https://www.banenor.no/siteassets/bane-nor-sf/stasjonssider- felles-innhold/sporplan-stasjoner/-h-/ko-000078-000-hamar.pn g

Mathias Vanden Auweele
Railway data freelancer
https://matdata.eu
Brussels, Belgium

Report message to a moderator

Re: Turntable and Transfer table [message #3979 is a reply to message #3975]

Thu, 30 April 2026 14:06

Johan Korsmo
Messages: 1
Registered: April 2026

Junior Member

A point I think has not been clearly verbalized is that turntables can have multiple resting location where each side connects to a track.
Meaning locations where no turning is required to traverse the infrastructure between two points.
See ie. Dominik Looser example, where 0 and 180 connect with no rotation required.

This requirement speaks to the need of modeling turntables using angles, not purely as sequences. Otherwise this modality would be lost.

Then, what arise is a want for transfertables to use meters not sequences, to be representatively homogeneous with turntables.

Report message to a moderator

Re: Turntable and Transfer table [message #3983 is a reply to message #3975]

Fri, 01 May 2026 07:40

christian.rahmig
Messages: 546
Registered: January 2016

Senior Member

Dear Mathias,

thank you for providing these example schematic track plans.

My question to the community: Does anyone want to challenge the proposed model by translating the transfer table example visualization into railML code? This would be very helpful to see if the model is complete...

Thank you in advance and 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: Turntable and Transfer table [message #3984 is a reply to message #3979]

Fri, 01 May 2026 07:50

christian.rahmig
Messages: 546
Registered: January 2016

Senior Member

Dear Johan,

thank you for pointing to this detail in the turntable and transfer table model.

I understood, that there is a need for defining the "default position" of the movable element knowing which tracks are connected by each other in that position, right?

Regarding the traversability in general, of course the "physical values" of angle and offset would provide more information than the plain sequences. In particular: same offset value --> traversable; angle2-angle1=180 --> traversable

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: Turntable and Transfer table [message #4000 is a reply to message #3984]

Fri, 08 May 2026 10:12

Jim Kjellberg
Messages: 10
Registered: January 2025

Junior Member

Trafikverket agree with Mathias Vanden Auweele's comment above, that referencing the netElements instead of netRelations would be a good choice for modelling turntables and like the "minimalistic" proposal from Dominik.

Regarding the angles we agree that it is a need to describe the traversability, but it might be hard to find good data to describe them.

Due to us not having transfer tables in the Trafikverket-managed rail network, we have no opinions on how they are modelled in railML but see no issues in adding them to 3.4 since there are others with the need of modelling them.

Regards
Jim Kjellberg
Jonas Ekman
Mathias Hofrén
Fredrik Jönsson
Trafikverket

Report message to a moderator

Previous Topic:	[railML3] New semantic constraint restricting RTM:level, IS:netElement and IS:netRelation
Next Topic:	[railML3] Use of geometricPositioningSystem/@crsDefinition

Goto Forum:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

] [

]

Current Time: Sat May 09 16:25:34 CEST 2026