Home » railML newsgroups » railML.infrastructure » [railML 3.4 bèta 3] BaliseGroup attribute validityDirection
[railML 3.4 bèta 3] BaliseGroup attribute validityDirection [message #4040] Tue, 16 June 2026 18:04 Go to next message
Mathias Vanden Auweele is currently offline  Mathias Vanden Auweele
Messages: 167
Registered: February 2025
Location: Brussels
Senior Member
Hello,

I notice in railML v3.4 bèta 3 that the baliseGroup has received a new attribute validityDirection that seems to indicate the direction in which the baliseGroup is applicable.

The element type that is associated is the tApplicationDirection which refers to intrinsicCoordinates to give meaning to the direction. However:
- without a reference to a netElement, this attribute is useless and ambiguous
- the spotLocation already contains this attribute, so this solution is increasing data duplication and possible issues
- multiple spotLocations (on different networks or levels) can exists, thus the tApplicationDirection can be different depending on the referenced netelement

Please remove this new attribute, it makes no sense.

Thank you

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

Report message to a moderator

Re: [railML 3.4 bèta 3] BaliseGroup attribute validityDirection [message #4050 is a reply to message #4040] Wed, 17 June 2026 14:02 Go to previous messageGo to next message
christian.rahmig is currently offline  christian.rahmig
Messages: 583
Registered: January 2016
Senior Member
Dear Mathias,

the attribute //baliseGroup/functionalType/@validityDirection defines the direction of train movement for which the certain balise telegram is valid. This refers to ETCS variable Q_DIR allowing for values "normal", "reverse" and "both". The assumption was that a balise group can submit different types of telegrams with different validity directions. Basically, @validityDirection replaces @mileageDirection, but not //baliseGroup/spotLocation/applicationDirection.

The complete modelling background is documented in Gitlab issue #684 [1]. The related forum discussion can be found in [2].

Maybe someone from the ETCS use case working group can confirm the balise group model as implemented in railML 3.4 beta 3 is sufficient or whether changes have to be considered.

[1] https://development.railml.org/railml/version3/-/issues/684
[2] https://www.railml.org/forum/index.php?t=msg&th=1068& ;start=0&

Thank you very much and best regards
Christian

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

Report message to a moderator

Re: [railML 3.4 bèta 3] BaliseGroup attribute validityDirection [message #4053 is a reply to message #4050] Wed, 17 June 2026 15:25 Go to previous message
Mathias Vanden Auweele is currently offline  Mathias Vanden Auweele
Messages: 167
Registered: February 2025
Location: Brussels
Senior Member
Thank you Christian for the feedback. So if I understand correctly, a <baliseGroup> can have multiple <functionalType> with different @validityDirection values. In that case, to avoid ambiguity, I think a reference to the spotLocation for which the @validityDirection applies is required?

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

Report message to a moderator

Previous Topic: [railML 3.4 bèta 3] PlatformEdge's new attribute "lateralDistance"
Next Topic: Interpreting "begin" and "end" in the sub elements <linearCoordinateBegin> and <linearCoordinateEnd>
Goto Forum:
  

[ Syndicate this forum (XML) ] [ RSS ] [ PDF ]

Current Time: Tue Sep 15 11:55:49 CEST 2026