[railML 3.2] extending the <balise> element [message #2264] |
Fri, 01 November 2019 12:25 |
christian.rahmig
Messages: 447 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
|
|
|
|
Re: [railML 3.2] extending the <balise> element [message #2275 is a reply to message #2267] |
Mon, 25 November 2019 15:10 |
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
|
|
|