Home » railML newsgroups » railML.infrastructure » [railML3] measure and distance in linear positioning systems (distanceToNext seems to be the better choice than measureToNext)
[railML3] measure and distance in linear positioning systems [message #3289] Fri, 30 August 2024 10:35 Go to next message
christian.rahmig is currently offline  christian.rahmig
Messages: 465
Registered: January 2016
Senior Member
Dear all,

have you ever wondered what the attribute @measureToNext in //linearPositioningSystem/anchor/ is used for?
If not, you may be aware of the best practice documentation on the wiki page of the <anchor> element [1]

However, the attribute name @measureToNext is little bit confusing. because the other anchor attribute, which describes the linear position value, is named @measure, too. What @measureToNext actually describes is a distance. It is the distance from this anchor until the next anchor or until the end of the linear positioning system. Therefore, I suggest to rename @measureToNext into @distanceToNext. The topic is already documented in a new ticket [2].

What are your ideas on this proposal?
What about the datatype for the @distanceToNext? Shall it be fixed with tLengthM in metres, or shall we leave the unit open to be decided by the user (@units is an already existing attribute in linearPositioningSystem)?

As usual, any feedback is highly appreciated.

Best regards
Christian


[1] https://wiki3.railml.org/wiki/RTM:anchor
[2] https://development.railml.org/railml/version3/-/issues/566

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: [railML3] measure and distance in linear positioning systems [message #3293 is a reply to message #3289] Mon, 02 September 2024 11:11 Go to previous messageGo to next message
David Lichti is currently offline  David Lichti
Messages: 20
Registered: December 2020
Junior Member
Hi Christian,

I had the same issue with this attribute. I strongly support renaming it to avoid confusion.

Implicitly using the same unit (i.e. @units) for relative distances as for the absolute reference points of the linear positioning system would be unnecessarily restrictive, I think. Ideally, railML would have a type for measures with explicit units. Until then, it may be best to use the fixed-unit type tLengthM.

Regards

David

Report message to a moderator

Re: [railML3] measure and distance in linear positioning systems [message #3294 is a reply to message #3293] Tue, 03 September 2024 14:43 Go to previous messageGo to next message
Thomas Nygreen is currently offline  Thomas Nygreen
Messages: 75
Registered: March 2008
Member
Hi all,

For consistency, I find it highly preferable that @measure and @distanceToNext (and @startMeasure and @endMeasure) is given in the same unit, i.e. the @units of the <linearPositioningSystem>.

I like David's idea of explicitly providing units for a measure. However, that would change existing attributes into elements with a pair of attributes for value and unit, and would constitute quite a major change. I'm also concerned about staying consistent with the same unit for different measures that would naturally be compared. I think this idea should go on the stack of possible improvements in a future version.

One more concern: the @units attribute is a completely unrestricted text string. As an example, I can think of ten different ways to specify the preferred (SI) unit metre (abbreviated/full, british/american spelling, singular/plural, lowercase/capitalised). Can we restrict the @units to an enumeration? As all the measures are decimal numbers, common mixed units such as miles and chains are ruled out, but decimal miles are possible. If we include "other:*", it is sufficient to include units that have a certain usage. Would "metre", "mile" and "other:*" be enough, or are there other units that should be included (e.g. multiples of these, like kilometre and feet)?

Best regards
Thomas

Thomas Nygreen – Common Schema Coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org

Report message to a moderator

Re: [railML3] measure and distance in linear positioning systems [message #3295 is a reply to message #3294] Tue, 03 September 2024 15:22 Go to previous messageGo to next message
David Lichti is currently offline  David Lichti
Messages: 20
Registered: December 2020
Junior Member
Of course, it would be nice, if absolute reference points (i.e. mileage) and relative distances would use the same units. But the mere necessity of the anchor element is evidence of the fact that mileage-kilometers are often different from distance-kilometers.

The original data and its units are out of the scope and control of railML. If the source data uses different units, but railML requires the conversion to a common unit, then an export would necessarily loose precision. It should be up to the receiver to decide, what units to accept, and whether unit conversion is acceptable.

Instead of restricting the admissible units for absolut reference positions, it would be better to loosen the format to allow lossless representations of non-decimal measure.

Report message to a moderator

Re: [railML3] measure and distance in linear positioning systems [message #3305 is a reply to message #3295] Wed, 04 September 2024 16:03 Go to previous message
Thomas Nygreen is currently offline  Thomas Nygreen
Messages: 75
Registered: March 2008
Member
Dear David,

Mileage-kilometres and distance-kilometres are still the same unit: kilometres. Or kilometers, Kilometres, Kilometers, km, KM, etc.

Requiring @distanceToNext to be given in metres is more strict than letting it be given in @units, and will require a conversion every time the source data and the other measures are given in a unit other than metres.

I am not suggesting to restrict the admissible units. I have simply suggested to restrict the spelling of the most common units, to be able to specify the unit in a computer-readable way, without excluding any possible units. If anyone wants to use a unit we do not include in the enumerated list, the only difference from now will be the "other:" prefix.

Best regards,
Thomas

Thomas Nygreen – Common Schema Coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org

Report message to a moderator

Previous Topic: [railML3] Request for feedback on changes of our deprecation policy
Next Topic: [railML3] netElement aggregation
Goto Forum:
  

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

Current Time: Wed Oct 02 12:25:43 CEST 2024