|
|
| Re: Mandatory elements for NEST UC [message #3707 is a reply to message #3634] |
Tue, 02 September 2025 08:48   |
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  |
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
|
|
|
|