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: 436
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 #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
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 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
Previous Topic: [railML3] Mandatory <length> element for <track>s
Next Topic: [railML2] @dir
Goto Forum:
  


Current Time: Fri Mar 29 13:42:00 CET 2024