Home » railML newsgroups » railML.infrastructure » [railML2] Adding a new element <turningResistance> to <ocp>
[railML2] Adding a new element <turningResistance> to <ocp> [message #2767] Fri, 18 June 2021 12:53 Go to next message
Michael Gruschwitz is currently offline  Michael Gruschwitz
Messages: 11
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
Re: [railML2] Adding a new element <turningResistance> to <ocp> [message #2769 is a reply to message #2767] Fri, 18 June 2021 14:37 Go to previous messageGo to next message
christian.rahmig is currently offline  christian.rahmig
Messages: 436
Registered: January 2016
Senior Member
Dear Michael,

thank you for your input. I already filed a Trac ticket for this issue: #413 [1].

[1] https://trac.railml.org/ticket/413

Best regards
Christian


Christian Rahmig – Infrastructure scheme coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org
Re: [railML2] Adding a new element <turningResistance> to <ocp> [message #2790 is a reply to message #2769] Fri, 16 July 2021 13:22 Go to previous messageGo to next message
christian.rahmig is currently offline  christian.rahmig
Messages: 436
Registered: January 2016
Senior Member
Dear Michael,
dear all,

did you already have a look at the railML 2.5 solution proposal for the topic of turning resistances in OCPs [1]? How do you like it? What are you missing or what would you change?

Further, here is one question from my side:
* A <relation> refers with its child elements <from> and <to> and included attributes @line and @ocp to neighbouring elements. Shall this reference be modelled using real references or do we want to allow for plain text strings, too? The first option requires that all referenced lines and OCPs have to exist as elements in the same railML file. The second option is more flexible, but provides potential for conflicting entries.

It will be great to hear about opinions and preferences of the community...

[1] https://trac.railml.org/ticket/413

Best regards
Christian


Christian Rahmig – Infrastructure scheme coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org
Re: [railML2] Adding a new element <turningResistance> to <ocp> [message #2804 is a reply to message #2790] Fri, 06 August 2021 15:18 Go to previous messageGo to next message
Michael Gruschwitz is currently offline  Michael Gruschwitz
Messages: 11
Registered: May 2020
Junior Member
Dear Christian, dear all,

Thank you for the modelling, which seems appropriate for us. We ask that
you implement it and incorporate it into the railML 2.5 standard (as
well as in the 3.x standard later on).

With regard to the <relationship>, we consider the free modelling as a
string to be attractive and open for a wide range of applications, but
we are afraid of various problems when importing into databases and the
resulting inconsistencies. Therefore, we ask for modelling using real
references for the time being.

With regard to the turning relationship, we would consider a detailed
modelling with regard to train movements and shunting movements to be
advantageous and submit a proposal for this.

Best regards,
--
Michael Gruschwitz
Bahnkonzept Dresden/Germany

Am 16.07.2021 um 13:22 schrieb Christian Rahmig:
> Dear Michael,
> dear all,
>
> did you already have a look at the railML 2.5 solution
> proposal for the topic of turning resistances in OCPs [1]?
> How do you like it? What are you missing or what would you
> change?
>
> Further, here is one question from my side:
> * A <relation> refers with its child elements <from> and
> <to> and included attributes @line and @ocp to neighbouring
> elements. Shall this reference be modelled using real
> references or do we want to allow for plain text strings,
> too? The first option requires that all referenced lines and
> OCPs have to exist as elements in the same railML file. The
> second option is more flexible, but provides potential for
> conflicting entries.
>
> It will be great to hear about opinions and preferences of
> the community...
>
> [1] https://trac.railml.org/ticket/413
>
> Best regards
> Christian
Re: [railML2] Adding a new element <turningResistance> to <ocp> [message #2805 is a reply to message #2804] Mon, 09 August 2021 06:20 Go to previous message
christian.rahmig is currently offline  christian.rahmig
Messages: 436
Registered: January 2016
Senior Member
Dear Michael,

thank you very much for your feedback. I changed the links from the relations to OCP and line from type string to references. Further, I added two more OCP relation type enumeration values: "requiresShunting" and "crossesContraflowTraffic". The complete solution is documented in Trac ticket #413 [1].

[1] https://trac.railml.org/ticket/413

Best regards
Christian


Christian Rahmig – Infrastructure scheme coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org
Previous Topic: [railML2] Adding a new element mediaResources to infrastructure subschema
Next Topic: [railML2] adding new element <area> for the mapping of track sections
Goto Forum:
  


Current Time: Fri Mar 29 14:56:05 CET 2024