| Re: [railML3] Micro - Meso - Macro [message #1681 is a reply to message #1677] |
Fri, 08 December 2017 13:03  |
Dirk Bräuer
Messages: 311
Registered: August 2008
|
Senior Member |
|
|
Dear Christian,
> Which railway infrastructure elements are considered to be the correct "border elements" at each topology level?
I am not sure whether there are such "border elements" you are looking for in all cases.
For instance, the borders of a station are not well-defined in Germany: Depending on the scope, the borders of a station can be either the entry signals, the place of the entry signal of the neighbouring track, the shunting limit (Ra10), the outermost point or a certain virtual place in this area (Fahrwegprüfbezirksgrenze). Stations can overlap each other.
In other countries, there are no such elements as stations defined at all. In general, it is not necessary to have well-defined stations for railway operation. But in many of the cases without well-defined stations, we still have timetables.
In the following, I am writing from a timetable scope of view. I guess our <timetable> view is regarded "macroscopic" by you.
From a timetable scope of view, we need to have places like <ocp>s along the infrastructure.
- An <ocp> is best described as "timetable measuring place" or "run-time measuring place" (Fahrzeitmesspunkt).
- An <ocp> can be imagined as a cross section (Querschnitt) through one or more tracks of infrastructure.
- An <ocp> in this meaning has no size, is a deterministic small point only, purely virtual, with just a mileage (Kilometrierung).
- An <ocp> can be a station (better: can be assigned to a station) but does not need to.
- An <ocp> which is assigned to a station will normally lie within the station limits (wherever these are).
- There can be more than one <ocp> assigned to one station depending on the route of trains.
From the "macroscopic" (timetable-oriented) view seen "down" into more microscopic levels,
1) A train relates to the infrastructure by referencing <ocp>s (and <line>s and <track>s).
2) An <ocp> relates to stations (or other operational constructs) by referencing registers with codes (in railML 2.3: <designator>s).
3) An <ocp> relates to lower infrastructure levels by belonging to one or several <tracks> with a certain mileage. (The <track>s can belong to <line>s.)
As you see, 2 and 3 are independently from each other. Normally we regard 2 as mandatory and 3 as optional for timetables.
My conclusion:
- I would not look for "border elements" between infrastructure levels.
- I would rather follow the concept of "cross sections" through all infrastructure levels (as an <ocp> as a dimensionless point can exist in all levels) and grouping of elements in a higher level by assigning (as switches, signals, <ocp>s can be grouped to a station or signal box by assigning the same register or signal box code).
With best regards,
Dirk.
|
|
|
|
Members
Search
Help
Login
Home
