| Orientation of baliseGroup and validity direction of balise telegrams [message #3640] |
Fri, 06 June 2025 15:04  |
Silvan Gruber
Messages: 7
Registered: July 2024
|
Junior Member |
|
|
Dear community
Regarding the orientation of balise groups and the validity directions of balise telegrams, the RailML specification does not seem to be clear. According to the Wiki, the information on the orientation and validity direction of balise telegrams can be described in railML as follows:
- Balise groups are located using "spotLocation," with the optional "applicationDirection" attribute. As I understand, this attribute is used to relate the effective direction of an element to the orientation of the NetElement.
- According to the wiki, the attribute "mileageDirection" can be used to align the balise group according to the track mileage.
- The child element "functionalType" is used to specify kinds of telegrams sent by a balise group. Since the telegrams are direction-dependent, the validity direction is described by the "mileageDirection" attribute.
The following questions arise in relation to these points:
1.) Should the attribute "applicationDirection" be used to describe the alignment in relation to the underlying NetElement? Then the following convention would make sense:
- applicationDirection="normal" => The orientation of the balise group corresponds to the orientation of the NetElement. (The position of the single balise with N_PIG=0 located on the NetElement is closer to the beginning of the NetElement than the single balise with N_PIG = 0+n)
- applicationDirection="reverse" => The orientation of the balise group is inverse to the orientation of the NetElement. (The position of the single balise with N_PIG=0+n located on the NetElement is closer to the beginning of the NetElement than the single balise with N_PIG = 0)
- applicationDirection="both" => is not used
2.) If an orientation of a balise group is specified when locating the balise group using "applicationDirection" (according to 1.), the information in "mileageDirection" would be redundant. Furthermore, problems can arise if the orientation of elements is not consistently related to the NetElements, but rather, as in this case, the route mileage is used with "mileageDirection." Here, the orientation should be described in relation to the underlying NetElement.
3.) According to Subset-026 Chapter 7, the validity direction of balise telegrams (Q_DIR) refers to the orientation of the balise group. Thus, the use of the "mileageDirection" attribute is not defined precisely enough in this regard. Furthermore, the functionalType@mileageDirection attribute can only specify whether a function acts in the nominal or reverse direction. If a function acts in both directions, the "both" attribute is missing. The attribute should indicate the relevant validity direction with reference to directionality of the balise group sending the information (Q_DIR).
In this context we ask the community if there are other users who have defined a clarification of the railML specification and a corresponding convention?
Kind regards
Silvan Gruber
SBB Swiss Railways
[Updated on: Fri, 06 June 2025 15:07] Report message to a moderator |
|
|
|
| Re: Orientation of baliseGroup and validity direction of balise telegrams [message #3690 is a reply to message #3640] |
Mon, 11 August 2025 11:36  |
christian.rahmig
Messages: 515
Registered: January 2016
|
Senior Member |
|
|
Dear Silvan,
thank you very much for bringing up this topic and for your very detailed explanation of the current situation.
Since there has been no reaction from the community so far, the topic is either absolutely clear or completely unclear :-)
Therefore, let me comment on your questions from a coordinator's point of view:
1.) Yes, @applicationDirection describes the orientation of the balise group in relation to the underlaying netElement. The possible values are "normal" and "reverse".
2.) The child element <functionalType> with attribute @mileageDirection relates to a certain balise telegram that is submitted by the balise group. So, it is not really redundant, because a balise group can submit several telegrams that are effective for different directions of travel.
3.) If you want to describe a telegram that is valid for multiple driving directions, you would need to model it with several <functionalType> child elements where you specify the different @mileageDirection values, because there is no value "both".
Following this summary of the current situation, a question may be derived: Even though there are these two directions (1 orientation of the balise group; 2 driving direction for which a balise telegram is valid), should they better refer to the same basis (orientation of the underlaying netElement)?
As usual, any comments from the community are 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: Orientation of baliseGroup and validity direction of balise telegrams [message #3773 is a reply to message #3690] |
Mon, 27 October 2025 23:49 |
Karl-Friedemann Jerosch
Messages: 13
Registered: May 2020
|
Junior Member |
|
|
Dear Silvan,
thank you very much for the reported problems and suggested improvements.
Balise Group orientation
I recommend to implement proposal 1.) in the next railML version 3.4 which means:
- deletion of "baliseGroup@mileageDirection"
- update of the documentation in the xsd and wiki according to the provided explanation in 1.) for attribute @applicationDirection
By this, the balise group orientation is defined only in relation to the netElement orientation and avoid the inconsistencies described under 2.).
ETCS Packet Validity Direction
The optional element "functionalType" belonging to "baliseGroup" was defined to give information about the function(s) fulfilled by the balise group.
A balise group function requires usually the transmission of one specific ETCS packet (or a set of ETCS packets) by this balise group.
The validity direction of ETCS packets (given by the UNISIG variable Q_DIR) refers to the orientation of the balise group.
As the existing attribute "functionalType@mileageDirection" provides the values "nominal" or "reverse", but not the value "both",
I would recommend to create a new attribute (for example named "validityDirection") with the values "nominal", "reverse" and "both" (according to UNISIG SUBSET-026, section 7.5.1.103),
which shall substitute the attribute "functionalType@mileageDirection".
By this, the problem described in 3.) should be solved.
To be in line with SUBSET-026, the new attribute "functionalType@validityDirection" should refer to the balise group orientation as shown in the figure presented by Silvan (and should not refer to the netElement orientation).
kind regards
Karl Jerosch
|
|
|
|
|
|
| Re: Orientation of baliseGroup and validity direction of balise telegrams [message #3783 is a reply to message #3775] |
Mon, 03 November 2025 09:40 |
Silvan Gruber
Messages: 7
Registered: July 2024
|
Junior Member |
|
|
Hi Karl,
Thank you for your reply and your suggestion for a possible solution, which I would agree with.
Note: When modeling a new attribute "functionalType@validityDirection", it should be clarified how the direction specifications according to UNISIG SUBSET-026 (nominal, reverse, both) should be used. As I understand it, railML uses the value "normal" instead of "nominal".
Kind regards,
Silvan
|
|
|
|
Members
Search
Help
Login
Home
