| Re: railML 3.2: Additional information for travel paths in a macroscopic netElement [message #2948 is a reply to message #2946] |
Thu, 10 March 2022 12:43  |
Thomas Langkamm
Messages: 25
Registered: April 2019
|
Junior Member |
|
|
Dear Dirk,
Dirk Bräuer wrote on Wed, 09 March 2022 18:13
So, can we agree that in general, there is already a solution for your problem: Use a microscopic model of infrastructure!
True. But many systems doing passenger information, vehicle dispatch or maintainance planning do not support a microscopic model, only a mesoscopic model (they know the different tracks in a station where a train might stop in a train journey or for parking, but have no detailled information about switches and the rest of the network). In some cases they will work only on a macroscopic model (stations as atoms).
Dirk Bräuer wrote on Wed, 09 March 2022 18:13
In my view, this would have to be matrix for each (macroscopic) junction of the network.
(A "macroscopic junction" is a node with more than two edges, so either a station or a junction with at least one branch line.)
I don't think that a matrix involving the number of CODs would work. (You need to distinguish between 0 and 2, because not all trains can travel in both directions.) There may be several ways to construct a travel path from A to B (say both being a tuple of track and direction), for example one that involves only one change of direction and another one involving 3 changes of direction. However, the latter one may still be preferrable because it uses a part of the network that is rarely used and therefore the required shunting wouldn't block part of the tracks that need a high availability.
To encode both variants and the other attributes we end up using a solution that is structurally very similar to the one I proposed. Instead of primitives (bool, int or double) in the matrix you would end up with a list of complex entries.
Finally, the matrix doesn't work for pure macroscopic models. Look at my example again: You can go from A to C and from C to E without a change of direction, yet if you go from A to C to E it depends on which platform you use in C if you need 0 or 2 change of directions. The matrix would work only on the mesoscopic levels if we have all platforms. And again, some systems may not have that detail, especially parking areas are often treated as "black boxes" by long-term planning systes.
I'm not at all emotionally tied to my proposal in any way, if there is a better way to do things then I'm all for it. But the solution has to work for systems that have incomplete information about the model. The main purpose IMO is to allow adding information on a mesoscopic/macroscopic leve that can (of course) be derived from the microscopic model, but isn't available because the systems do not support storing/evaluating a microscopic or mesoscopic model.
|
|
|
|
Members
Search
Help
Login
Home
