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 #2945 is a reply to message #2919] Wed, 09 March 2022 16:24 Go to previous messageGo to previous message
Thomas Langkamm is currently offline  Thomas Langkamm
Messages: 25
Registered: April 2019
Junior Member
Dear Dirk,

I'm not quite sure that I understand what you're proposing. Could you be more specific? There are several use cases where it's necessary to track the orientation/position of a railcar [possibly in a formation] independent of a timetable, and therefore we can't really use changes of direction supplied in TT.


  • For example, in conflict management we may have to reroute a train over a different part of the network (a detour) because the original travel path (which could be fairly long, more than just a couple of track routes) is not available. Here it's necessary to know if the train changes orientation because it uses this detour.
  • In maintainance planning (more specifically, planning of the necessary shunting), a typical case is that a railcar is located at some station and needs to be moved to a workshop at a different station. Assuming that we achieve this by adding the railcar to the end (or front) of existing trains, we need to find a sequence of train journeys that get the train to the workshop but also in a way that shunting is minimized (for example the railcar ends up as first railcar on the overnight parking track). Here it's not practical to look at all train journeys in a timetable, but rather we'll look for a travel path (macroscopic or mesoscopic) first and then find train journeys covering the distance second, hence we need changes of direction in the macroscopic model.
  • As for the other attributes (that are mostly related to routing) I don't see how they would work in a timetable context either. If we have two possible travel paths between A and B via C (say using different platforms at C) and we want to encode a priority for routing (say one travel path should only be used in emergencies), there is no timetable context.
 
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: Sun May 12 14:59:33 CEST 2024