Home » railML newsgroups » railML.infrastructure » railML 3.2: Additional information for travel paths in a macroscopic netElement
Re: railML 3.2: Additional information for travel paths in a macroscopic netElement [message #2949 is a reply to message #2934] Thu, 10 March 2022 12:53 Go to previous messageGo to previous message
Thomas Langkamm is currently offline  Thomas Langkamm
Messages: 25
Registered: April 2019
Junior Member
Dear Christian,

christian.rahmig wrote on Mon, 07 March 2022 12:09

I want to suggest a very basic change in the RTM foundation. Currently, a <netRelation> connects two <netElement> objects via child elements <elementA> and <elementB>. Based on discussions related to the driving directions in macroscopic nodes, I propose to adapt the model for enabling connections of more than two <netElement> objects. In particular, the approach foresees:
* renaming elements <elementA> and <elementB> into <fromElement> and <toElement>
* adding new optional, repeatable child element <viaElement> (0..*)
I think this would be a valid approach if we were working on a new major version of railML and had decided to tweak the netElement/netRelation structure anyway, but in railML 3.x I would strongly prefer storing the information either as new object or somewhere else, but not as part of the netElement/netRelation structure. The reasons for this are as follows:


  1. The netElement and netRelation objects are the very fundament of the model. Even renaming objects should only be considered for new major versions, and should be done only if there are major reasons for it (or against keeping the old structure).

  2. This suggestion does not only rename, but it changes semantics. Right now we can assume that netRelations connect netElements that are adjacent, so the netRelation itself has no extension, travel time or other dimension. The netElement are the places that have an extension where a train can be. Your suggestion changes this, now there could be an extension between fromElement and toElement. This would break any code that, for example, assumes that there is zero travel time and distance between netElements when traversing a netRelation.

[Updated on: Thu, 10 March 2022 12:53]

Report message to a moderator

 
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Previous Topic: Single and double derailer
Next Topic: [railML 3.2] "isSpeedSignal": Suggestion to delete the value "midOfTrain" of element "trainRelation"
Goto Forum:
  


Current Time: Mon May 13 04:02:20 CEST 2024