Forum - RDF feed
https://www.railml.org/forum/index.php
[railML 3.2] extending the <balise> element
https://www.railml.org/forum/index.php?t=rview&goto=2264&th=687#msg_2264
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?
--
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.rahmig2019-11-01T11:25:08-00:00Re: [railML 3.2] extending the <balise> element
https://www.railml.org/forum/index.php?t=rview&goto=2267&th=687#msg_2267
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
]]>Henrik Roslund2019-11-01T12:38:01-00:00Re: [railML 3.2] extending the <balise> element
https://www.railml.org/forum/index.php?t=rview&goto=2275&th=687#msg_2275
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.