Home » railML newsgroups » railML.infrastructure » Mandatory elements for NEST UC (NEST)
Mandatory elements for NEST UC [message #3634] Tue, 27 May 2025 16:53 Go to next message
Torben Brand is currently offline  Torben Brand
Messages: 211
Registered: March 2016
Senior Member
This is a posting To be discussed in common NEST SCTP meeting in June.

I think the following track@type [1] should be mandatory in NEST UC:
Main: yes
Siding: no
Secondary: optional
Connecting: optional/no (depends how modelled)

All signalIs<isMovementSignal> [2] should be optional/mandatory
all other signals: no (as covered in SCTP)
signalIL@function [3]: yes/optional Challenge is that we introduce a new subschema to the UC, but this should be ok for only one element

[1] https://wiki3.railml.org/wiki/IS:track#3.3-0
[2] https://wiki3.railml.org/wiki/IS:isTrainMovementSignal#3.3-0
[3] https://wiki3.railml.org/wiki/IL:signalIL#3.3-0

[Updated on: Mon, 23 June 2025 13:44]

Report message to a moderator

Re: Mandatory elements for NEST UC [message #3707 is a reply to message #3634] Tue, 02 September 2025 08:48 Go to previous messageGo to next message
Fredrik Jönsson is currently offline  Fredrik Jönsson
Messages: 14
Registered: June 2024
Location: Sweden
Junior Member
Hi Torben,

[1] From Swedish (Trafikverket) perspective we think that the consumer of data should be the one that makes the selection i.e. we think the data could be disseminated for the whole network at macro/meso/micro level.
The NEST UC should allow to describe the network in different ways depending on the how its done today between different Infrastructure managers. An example is that Trafikverket currently describe service functions and stabling track information in its network statement documentation https:// bransch.trafikverket.se/en/startpage/operations/Operations-r ailway/Network-Statement/network-statement-2025/ and this information often belongs to the track type Siding.

Therefor we would like to have the Siding as optional:
Main: yes
Siding: optional
Secondary: optional
Connecting: optional/no (depends how modelled)

[2] We agree on this proposal.
[3] We agree. @funtion could be added as an attribute of SignalIS aswell. It is also needed in context of Route book information (See TSI OPE Appendix D2 and RINF)


Fredrik Jönsson
Trafikverket - Swedish Transport Administration
Re: Mandatory elements for NEST UC [message #3730 is a reply to message #3707] Mon, 06 October 2025 08:57 Go to previous message
Silvan Gruber is currently offline  Silvan Gruber
Messages: 11
Registered: July 2024
Junior Member
Hi Torben,
The topic was discussed in the SCTP/NEST Working Group on 26 September 2025, with the participants agreeing on the following points:

[1] The track types (IS:track@type) should be considered in the NEST UC as follows:

main: mandatory
siding: optional
secondary: optional
connecting: optional

[2] To ensure that the railML data clearly indicates which signals are to be processed in the NEST UC, it is recommended to use "isTrainMovementSigna@type" for all signals relevant to train movements. However, the "isTrainMovementSignal" element should not be mandatory in the NEST UC, as otherwise, listing signals without "isTrainMovementSignal" would be prohibited.

[3] The same applies to "signalIL@function", since the information regarding entry and exit signals is relevant in the NEST UC.

Note: The possible values ​​in "isTrainMovementSigna@type" (distant, main, repeater, shunting) are somewhat redundant to the values ​​in "signalIL@function" (barrage, block, blockInterface, distant, entry, exit, group, intermediate, intermediateStop, junction, lineInterface, trackEnd, repeater, shunting)
A clarification should be considered with railML3.4

[Updated on: Mon, 06 October 2025 09:00]

Report message to a moderator

Previous Topic: [railML3] Making consistent linearPositioningSystem and linear coordinates
Next Topic: Handling of netElement directions in switches and crossings
Goto Forum:
  


Current Time: Wed Jun 17 06:14:18 CEST 2026