Home » railML newsgroups » railml.infrastructure » [railML3] Micro - Meso - Macro
[railML3] Micro - Meso - Macro [message #1677] Mon, 04 December 2017 14:30 Go to next message
christian.rahmig is currently offline  christian.rahmig
Messages: 65
Registered: January 2016
Member
Dear railML community members,

When talking about railML v3 the possibility to define railway network
topology on several levels plays a key role in the discussion.

A central question, however, has not yet been completely answered:
Which railway infrastructure elements are considered to be the correct
"border elements" at each topology level?

A relevant example for illustration:
A station is an <operationalPoint> and it can be demarcated by the
location of the station entrance signals. If aggregated at mesoscopic
level, one <netElement> shall reference all microscopic topology
elements covered by the <operationalPoint>. Is this demarcation
generally accepted among all of you?

Any comments are highly appreciated...

Best regards
Christian

--
Christian Rahmig - Infrastructure scheme coordinator
railML.org (Registry of Associations: VR 5750)
Phone Coordinator: +49 173 2714509; railML.org: +49 351 47582911
Altplauen 19h; 01187 Dresden; Germany www.railml.org
Re: [railML3] Micro - Meso - Macro [message #1681 is a reply to message #1677] Fri, 08 December 2017 13:03 Go to previous message
Dirk Bräuer is currently offline  Dirk Bräuer
Messages: 221
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.
Previous Topic: [railML3]: openend and Macroscopic nodes
Next Topic: Infrastructure registers
Goto Forum:
  


Current Time: Sun Jan 21 23:30:13 CET 2018