| [railML2] Adding a new element <turningResistance> to <ocp> [message #2767] |
Fri, 18 June 2021 12:53  |
Michael Gruschwitz
Messages: 12
Registered: May 2020
|
Junior Member |
|
|
*** Deutsche Version siehe unten ***
Dear colleagues!
Within the framework of our BMVI-funded research project "Indres", route
networks are to be handed over to the project partners and third parties
as macroscopic modelling. Here, the relations of a node are to be
assigned turning resistances at the transition from one route section to
another route section (or in the special case of turning: to the same
section). An exemplary application are path search algorithms for the
compilation of trip relations before the train path order of a train.
Other applications such as the mapping of wagon orders or traction
representations for circulation plans are conceivable, but not the focus
of our project.
This macroscopic mapping of the turning resistances is necessary,
because in most cases a track-exact microscopic modelling is not yet
possible at this stage of the process or these data are not available in
the source systems. We had already made suggestions on this at the last
meetings, here is the proposal for discussion:
This extension of railML 2 should be implemented explicitly only for an
exchange of data in macroscopic modelling (tracks of a line as an edge;
stations as a node; station tracks at a node). In this respect, these
turning resistances cannot and should not be used as the exclusive
criterion of concrete timetables or line occupancies.
We propose the following extensions in this respect:
Introduction of a Turning Resistance element at <ocp> with the following
attributes:
- Enumeration of relations depending on the number of edges (e.g. 3
routes = 9 relations).
Here I would suggest to make the complete specification of all relations
semantically obligatory when using the element in order to exclude
different interpretations by reading programmes.
- Turning resistance with properties such as "with/without vehicle
turn", possible obstruction by "oncoming traffic", necessity of manoeuvring.
- priority (integer between 1 and 99; 1 = highest priority; 99 = lowest
priority)
- Average delay time due to waiting, shunting or other delays (duration;
supplemented by time periods, if necessary, in order to be able to map
different obstruction classes (e.g. peak hours/non-peak hours)).
I would leave the exact modelling to the experts. We would be happy to
provide a graphical representation as a basis for discussion and also
for later documentation.
Best regards,
--
Michael Gruschwitz
Bahnkonzept Dresden/Germany
***************************
Liebe Kollegen!
Im Rahmen unseres BMVI-geförderten Forschungsprojektes "Indres" sollen
Streckennetze als makroskopische Modellierung an die Projektpartner und
Dritte übergeben werden. Hierbei sollen den Relationen eines Knotens
Abbiegewiderstände beim Übergang von einem Streckenabschnitt auf einen
anderen Streckenabschnitt (bzw. im Sonderfall des Wendens: auf den
selben Abschnitt) zugewiesen werden. Eine beispielhafte Anwendung sind
Wegesuch-Algorithmen für die Zusammenstellung von Fahrt-Relationen vor
der Trassenbestellung eines Zuges. Weitere Anwendungen wie die Abbildung
von Wagenreihungen oder Traktionsdarstellungen für Umlaufpläne sind
denkbar, allerdings nicht im Fokus unseres Projektes.
Diese makroskopische Abbildung der Abbiegewiderstände ist notwendig, da
eine gleisgenaue mikroskopische Modellierung in den meisten Fällen in
diesem Prozeßstadium noch nicht möglich ist oder diese Daten in den
Quellsystemen nicht vorliegen. Wir hatten dazu bereits bei den letzten
Treffen Anregungen gegeben, hier nun der Vorschlag zur Diskussion:
Diese Erweiterung von railML 2 soll ausdrücklich nur für eine Austausch
von Daten in makroskopischen Modellierungen (Gleise einer Strecke als
Kante; Bahnhöfe/Stationen als ein Knoten; Stationsgleise an einem
Knoten) umgesetzt werden. Dahingehend können und sollen diese
Abbiegewiderstände nicht als ausschließliches Kriterium konkreter
Fahrpläne oder Streckenbelegungen verwendet werden.
Folgende Erweiterungen schlagen wir dahingehend vor:
Einführung eines Elements Abbiegewiderstand am <ocp> mit folgenden
Attributen:
- Aufzählung der Relationen je nach Anzahl der Kanten (z.B. 3 Strecken =
9 Relationen)
Hier würde ich vorschlagen, bei Verwendung des Elements die vollständige
Angabe aller Relationen semantisch verpflichtend zu machen, um
unterschiedliche Interpretationen bei lesenden Programmen auszuschließen.
- Abbiegewiderstand mit Eigenschaften wie „mit/ohne Fahrzeug-Wende“,
mögliche Behinderung durch „Gegenverkehr“, Notwendigkeit des Rangierens
- Priorität (Ganzzahl zwischen 1 und 99; 1 = höchste Priorität; 99 =
geringste Priorität)
- durchschnittliche Verzögerungszeit durch Warten, Rangieren oder andere
Verzögerungen (Zeitdauer; ggf. ergänzt durch Zeitperioden, um
unterschiedliche Behinderungsklassen (HVZ/NVZ) abbilden zu können)
Die genaue Modellierung würde ich den Experten überlassen. Gern können
wir noch eine graphische Darstellung als Diskussionsgrundlage und auch
für die spätere Dokumentation zur Verfügung stellen.
Freundliche Grüße,
Michael Gruschwitz
Bahnkonzept Dresden
|
|
|
|
Members
Search
Help
Login
Home
