Home » railML newsgroups » railML.infrastructure » How to model 3 topology levels in rail.ML
Re: How to model 3 topology levels in rail.ML [message #2215 is a reply to message #2202] Fri, 05 July 2019 12:08 Go to previous message
christian.rahmig is currently offline  christian.rahmig
Messages: 436
Registered: January 2016
Senior Member
Dear Thomas,

Am 07.06.2019 um 10:44 schrieb Thomas Langkamm:
> I guess part of my confusion came from the rail.ML simple
> tutorial, where there is no clear distinction between
> mesoscopic and macroscopic topology and two tracks belonging
> to different platform edges are grouped to one mesoscopic
> netElement. [...]

You are right, the Simple Example Tutorial is not exact on this topic,
also because there have been no clear semantic constraints so far for
distinguishing between micro, meso and macro level of railway topology
network.

@all: Do you prefer flexibility in defining topology levels or do you
want to have fixed levels with clear constraints on their content?

In case of fixed levels, this is Thomas' proposal of aggregation between
micro and meso topology level:

> In open areas (outside of stations/operational points), the
> modelliung is up to the user. If we consider simple tracks
> between stations, we may have only one netElement for a
> single track and two netElements if we have double tracks.
> More elements if we have a more complex connectivity.
> Within stations we have to distinguish between tracks that
> have an associated platform edge, and the remaining tracks.
> All netElements incident to one platform edge will be
> grouped to one mesoscopic netElement, so we end up with
> exactly one mesoscopic netElement for every per track
> visible in a printed timetable.
> For parking tracks we'll have either one mesoscopic
> netElement for a group of parking tracks, or one mesoscopic
> netElement per track in the depot.
> Maintenance areas are handled similar to parking areas.
> For the remaining tracks, any modelling is feasible as long
> as it maintains the correct connectivity between the
> previously defined mesoscopic netElements.

@all: Any comments?

> As for 3 being enough, on that level of detail I think we're
> right. But there may be other topologies on top of macro,
> for example grouping operational points to areas (perhaps
> controlled by interlockings, perhaps belonging to different
> regions or countries).

The advantage of having a flexible interpretation of topology levels is
that there can be more than three levels of detail without any problem.
Alternatively, we need to think about new levels apart from "micro",
"meso" and "macro"...

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


Christian Rahmig – Infrastructure scheme coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org
 
Read Message
Read Message
Read Message
Read Message
Previous Topic: Differences between <screenCoordinates> and <Infrastructure visualization> tags
Next Topic: How to represent Line Continuation on railML
Goto Forum:
  


Current Time: Fri Apr 19 20:02:28 CEST 2024