Home » railML newsgroups » railML.infrastructure » [railML 3.2] extending the <balise> element
[railML 3.2] extending the <balise> element [message #2264] Fri, 01 November 2019 12:25 Go to next message
christian.rahmig is currently offline  christian.rahmig
Messages: 474
Registered: January 2016
Senior Member
Dear all,

the railML use case working group "ETCS" that works on the "ETCS Track
Net" use case (see [1]) suggests to extend the current implementation of
<balise> in railML 3.x in order to fulfill requirements resulting from
ETCS specification.

I summarized the proposed changes in Trac ticket #366 (see [2]).

Please have a look at the proposed changes and let us know your short or
long comments.

In particular, I would like to know your opinion on the following issues:
a) Shall we implement a <balise>@countryID (integer, 0..1023) or shall
we make use of the ISO country code concept instead (see [3])?
b) Shall the location accuracy in <balise>@locationAccuracy (in meters)
be modelled as integer or float?
c) Do you suggest any pattern for storing the ETCS version in attribute
<balise>@etcsVersion?

[1] https://wiki2.railml.org/index.php?title=UC:IS:ETCS_track_ne t
[2] https://trac.railml.org/ticket/366
[3] https://en.wikipedia.org/wiki/ISO_3166-1_alpha-2

Best regards
Christian

--
Christian Rahmig - Infrastructure scheme coordinator
railML.org (Registry of Associations: VR 5750)
Phone Coordinator: +49 173 2714509; railML.org: +49 351 47582911
Altplauen 19h; 01187 Dresden; Germany www.railml.org

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

Report message to a moderator

Re: [railML 3.2] extending the <balise> element [message #2267 is a reply to message #2264] Fri, 01 November 2019 13:38 Go to previous messageGo to next message
Henrik Roslund is currently offline  Henrik Roslund
Messages: 6
Registered: August 2019
Location: Zürich
Junior Member
Dear all,

here is my feedback regarding the three issues:
a)
as @countryID, I suggest using NID_C instead, see: www.era.europa.eu/sites/default/files/activities/docs/ertms_ 040001_etcs_variables_values_en.pdf
b)
@locationAccuracy (in meters), I suggest float, because Q_SCALE can be set to 10cm, 0.010m.
c)
@etcsVersion, do you mean M_VERSION?

Best Regards
Henrik Roslund

Report message to a moderator

Re: [railML 3.2] extending the <balise> element [message #2275 is a reply to message #2267] Mon, 25 November 2019 15:10 Go to previous messageGo to next message
Fabrizio Cosso is currently offline  Fabrizio Cosso
Messages: 12
Registered: September 2017
Junior Member
Dear Henrik, Christian,
reading the SUBSET-026 I noticed that the location accuracy Q_LOCACC is defined as "defines the absolute value of the accuracy of the Balise location (i.e., the value 63m identifies a location accuracy of +/- 63m)" with resolution of 1 m.
If Q_LOCACC is the right value (instead of Q_SCALE) we should probably use integer instead of float.

BR

FAbrizio

Report message to a moderator

[railML3] balise location accuracy [message #3331 is a reply to message #2275] Mon, 07 October 2024 09:58 Go to previous message
christian.rahmig is currently offline  christian.rahmig
Messages: 474
Registered: January 2016
Senior Member
Dear all,

picking up the comment of Fabrizio five years ago:
In railML 3 the location accuracy of the ETCS balise group (modelled with \\baliseGroup\isEurobaliseGroup\@locationAccuracy as railML's representation of the ETCS variable Q_LOCACC) is still provided in (float) meters (tLengthM). If there is any need for changing this into integer meters with upcoming railML 3.3, please comment here asap.

Thank you very much and best regards
Christian


Fabrizio Cosso wrote on Mon, 25 November 2019 15:10
Dear Henrik, Christian,
reading the SUBSET-026 I noticed that the location accuracy Q_LOCACC is defined as "defines the absolute value of the accuracy of the Balise location (i.e., the value 63m identifies a location accuracy of +/- 63m)" with resolution of 1 m.
If Q_LOCACC is the right value (instead of Q_SCALE) we should probably use integer instead of float.

BR

FAbrizio

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

Report message to a moderator

Previous Topic: [railML3] Mandatory stop at level crossing
Next Topic: [railML3] balise telegrams
Goto Forum:
  

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

Current Time: Thu Dec 05 13:27:13 CET 2024