|
|
|
|
| Re: Turntable and Transfer table [message #3691 is a reply to message #3687] |
Mon, 11 August 2025 12:20   |
christian.rahmig
Messages: 539
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
|
|
|
|
| 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
|
|
|
|
| Re: Turntable and Transfer table [message #3700 is a reply to message #3695] |
Mon, 25 August 2025 10:33 |
Mathias Vanden Auweele
Messages: 104
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
|
|
|
|
|
|
|
|
| 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?
[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: 104
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
|
|
|
|
| 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
Thomas Nygreen – Common Schema Coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org
|
|
|
|
| Re: Turntable and Transfer table [message #3834 is a reply to message #3831] |
Thu, 11 December 2025 08:58 |
Dominik Looser
Messages: 42
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:27Dear 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.
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
[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: 104
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
|
|
|
|
| Re: Turntable and Transfer table [message #3921 is a reply to message #3835] |
Fri, 06 March 2026 12:05 |
christian.rahmig
Messages: 539
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
|
|
|
|
| Re: Turntable and Transfer table [message #3931 is a reply to message #3921] |
Mon, 09 March 2026 13:00 |
Dominik Looser
Messages: 42
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
|
|
|
|
Members
Search
Help
Login
Home
