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 |
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.
|
|
|