User:Christian Rößiger

From railML 2 Wiki
Revision as of 17:38, 7 November 2017 by Christian Rößiger (talk | contribs) (Beispiele für Referenzierung von Bahnsteiggleisen ergänzt)
Jump to navigation Jump to search

Referenzierung von Bahnhofsgleisen, Bahnsteigkanten und Halteplätzen im makroskopischen Infrastrukturmodell

Generell existieren 3 verschieden Möglichkeiten im makroskopischen Infrastrukturmodell die Nutzung bestimmter Bahnhofsgleise und Bahnsteigkanten abzubilden:

Ohne Abbildung von Bahnhofsgleisen in der Infrastruktur

Sollen in der Infrastruktur keine <track>-Elemente angelegt werden, so kann das von einem Zug benutzte Bahnhofsgleis im Attribut trackInfo der <ocpTT> angegeben werden. Eine Angabe einer Bahnsteigkanten-Bezeichnung ist bei dieser Abbildungsvariante nicht möglich.

Das Beispiel beschreibt einen Zug, der in der Betriebsstelle "Zürich HB" das Gleis mit der betrieblichen Bezeichnung "12" benutzt. 

  <ocp id="_85ZUE" code="85ZUE" name="Zürich HB" />
  ...
  <ocpTT ocpRef="_85ZUE" trackInfo="12">
    <times scope="scheduled" arrival="10:59:00" departure="11:04:00"/>
  </ocpTT>

Referenzierung von Bahnhofsgleisen (ohne Angabe einer platformEdge)

Die Bahnsteig- bzw. Gleisbezeichnung ist nicht innerhalb des <trainPart>s angegeben, stattdessen wird in der Infrastruktur ein <track>-Element angelegt, welches von der <ocpTT> über das Attribut trackRef referenziert wird. Der Name des Gleises wird im Attribut code und der Name der Bahnsteigkante im Attribut name des <track>s angegeben. Das referenzierte Bahnhofsgleis sollte am <trackBegin> / <trackEnd> über das Attribut ocpRef die jeweilige <ocp> referenzieren.

Ungünstig ist bei dieser Variante die Verwendung des Attributs name des <track>s für die Bezeichnung der Bahnsteigkante, da dieses Attribut üblicherweise den Namen des Elements, hier also des <track>s enthalten sollte.

Das Beispiel zeigt einen Zug, der in der Betriebsstelle "Zürich HB" das Gleis mit der betrieblichen Bezeichnung "12" benutzt und an der Bahnsteigkante "1" hält. 

  <track id="_tr" code="12" name="1" type="stationTrack">
    <trackTopology>
      <trackBegin id="_tb" pos="0">
        <macroscopicNode ocpRef="_85ZUE" />
      </trackBegin>
      <trackEnd id="_te" pos="647">
        <macroscopicNode ocpRef="_85ZUE" />
      </trackEnd>
    </trackTopology>
  </track>
  ...
  <ocp id="_85ZUE" code="85ZUE" name="Zürich HB" />
  ...
  <ocpTT ocpRef="_85ZUE" trackRef="_tr">
    <times scope="scheduled" arrival="10:59:00" departure="11:04:00"/>
  </ocpTT>

Referenzierung von Bahnhofsgleisen und Bahnsteigkanten (platformEdge)

Zusätzlich zur vorigen Variante wird innerhalb eines <track>-Elements zusätzlich ein eigenes <platformEdge>-Element angelegt. Der Name der Bahnsteigkante kann jetzt direkt im code-Attribute des <platformEdge>-Element angegeben werden. Aus der <ocpTT> wird die <platformEdge> über das Attribut ref des <platformEdgeRef>-Elements referenziert.

Das Beispiel zeigt einen Zug, der in der Betriebsstelle "Zürich HB" das Gleis mit der betrieblichen Bezeichnung "12" benutzt und an der Bahnsteigkante "1" hält. 

  <track id="_tr" code="12" type="stationTrack">
    <trackTopology>
      <trackBegin id="_tb" pos="0">
        <macroscopicNode ocpRef="_85ZUE" />
      </trackBegin>
      <trackEnd id="_te" pos="647">
        <macroscopicNode ocpRef="_85ZUE" />
      </trackEnd>
    </trackTopology>

    <trackElements>
      <platformEdges>
        <platformEdge id="_pe" code="1" pos="55" />
      </platformEdges>
    </trackElements>
  </track>
  ...
  <ocp id="_85ZUE" code="85ZUE" name="Zürich HB" />
  ...
  <ocpTT ocpRef="_85ZUE" trackRef="_tr">
    <times scope="scheduled" arrival="10:59:00" departure="11:04:00"/>
    <stopDescription>
      <platformEdgeRef ref="_pe" />
    </stopDescription>
  </ocpTT>

Angabe der Halteposition in einer Betriebsstelle

Abbildung in Relation zur Betriebsstellenmitte

Das Beispiel beschreibt einen Zug, der in der Betriebsstelle "Zürich HB" mit der Zugspitze (alignment=head) 10m vor dem Betriebsstellen-Querschnitt hält. 

  <ocp id="_85ZUE" code="85ZUE" name="Zürich HB" />
  ...
  <ocpTT ocpRef="_85ZUE" alignment="head" offset="-10">
    <times scope="scheduled" arrival="10:59:00" departure="11:04:00"/>
  </ocpTT>

Abbildung über die Angabe von Halteplätzen (<stopPost>)

  <track id="_tr">
    <trackTopology>
      <trackBegin id="_tb" pos="0">
        <macroscopicNode ocpRef="_85ZUE" />
      </trackBegin>
      <trackEnd id="_te" pos="647">
        <macroscopicNode ocpRef="_85ZUE" />
      </trackEnd>
    </trackTopology>

    <ocsElements>
      <stopPosts>
        <stopPost id="_sp" pos="10"/>
      </stopPosts>
    </ocsElements>
  </track>
  ...
  <ocp id="_85ZUE" code="85ZUE" name="Zürich HB" />
  ...
  <ocpTT ocpRef="_85ZUE" stopPostRef="_stp" trackRef="_tr">
    <times scope="scheduled" arrival="10:59:00" departure="11:04:00"/>
  </ocpTT>

Default values of stop description and their dependencies

Nr. <ocpTT> <stopDescription> Description
ocpType guaranteedPass commercial onOff stopOnRequest operationalStopordered  
1.1 pass true attribute not to be used attribute not to be used attribute not to be used attribute not to be used guaranteed pass
1.2 false attribute not to be used attribute not to be used attribute not to be used attribute not to be used non-guaranteed pass
2.1 stop, begin, end attribute not to be used true both true attribute not to be used commercial stop on request for on and off
2.2 attribute not to be used true both false attribute not to be used commercial stop for on and off
2.3 attribute not to be used true on true attribute not to be used commercial stop on request for on only
2.4 attribute not to be used true on false attribute not to be used commercial stop for on only
2.5 attribute not to be used true off true attribute not to be used commercial stop on request for off only
2.6 attribute not to be used true off false attribute not to be used commercial stop for off only
2.7 attribute not to be used false currently not supported currently not supported true operational stop ordered by the TOC
2.8 attribute not to be used false currently not supported currently not supported false operational stop introduced by the IM

Comments:

  • Values "begin" and "end" of the attribute "ocpType" are deprecated with railML2.2
  • green cells are default values
  • if no <stopDescription> is given, then it is either a non-guaranteed pass (1.2) or a stop with undefined properties, depending on the attribute "ocpType"
  • The term "commercial" of the attribute in railML traditionally refers to the contractual relationship between TOC and end-customer, not to the contractual relationship between IM and TOC.
  • The term "ordered" in the attribute operationalStopOrdered refers to the contractual relationship between IM and TOC.

Sand box

Diskussion timetable Treffen Wien 16.03.2015

  • <trainPart>.trainNumber: nichts oder (redundant) Nummer des verkehrlichen/commercial Zugs wie <train>.trainNumber
  • <trainPart>.code: Nummer des Zugteils (wie "61458" für Praha - Erfurt) -> Verwendung unklar
  • <trainPart>.name: optional Name des Zugteils (wie "Canopus")

An einem operational train sollte kein Znr-Wechsel modelliert werden. trainNumber vom <trainPart> sollte nicht verwendet werden, zur Abbildung von Zugnummerwechseln bei durchlaufenden Zügen. Hierfür müsste ein neues Attribut an der trainPartsequence vorgesehen werden.

Offen ist, ob ein Wechsel der Zugnummern bei betrieblichen Zügen praktisch vorkommen kann.

trainNumber und name sollen inhaltlich zum commercial train verschoben werden -> evtl. in 2.3. als deprecated erklären. code soll am trainPart erhalten bleiben.

operational trains:

  • <train>.trainNumber/scope/additionalTrainNumber: wie bekannt in der "Summe" (als Tripel) Eindeutigkeitskriterum über alle operational trains
  • <train>.code: frei für eine Art Schlüssel des Zuges, der über die railML-Datei hinaus Bedeutung haben kann
  • <train>.name: nicht verwendet

commercial trains:

  • <train>.trainNumber/scope/additionalTrainNumber: wie bekannt in der "Summe" (als Tripel) Eindeutigkeitskriterum über alle commercial trains (Besonderheit FBS: hier nur trainNumber benutzt, scope/additionalTrainNumber immer leer)
  • <train>.code: frei für eine Art Schlüssel des Zuges, der über die railML-Datei hinaus Bedeutung haben kann
  • <train>.name: optional Name des Zuges (wie "Canopus")

trainNumber vs. code im Allgemeinen:

code soll für jeden Tag eine eindeutige Bezeichnung eines Zuges herstellen (im Gegensatz zur trainNumber, die an einem Tag mehrfach vorkommen kann, z.B. verschiedene EVU, etc.). code soll eine eindeutige Id für den Zug darstellen und darf deswegen nicht Zugeigenschaften, wie Verkehrstage, Laufweg etc. abbilden.

für die "Betitelung" (Vermarktung) von commercial trains dem Reisenden gegenüber = Spaltenüberschrift im Kursbuch gilt: wenn <commercial train>.trainNumber angegeben ist, wird diese verwendet. Ansonsten wird <commercial train>.name verwendet. Eines von beiden muss angegeben sein.

besondere Bedingungen für das Einlesen von RailML-Dateien in FBS: - <commercial train>.trainNumber/scope/additionalTrainNumber/name werden nicht ausgewertet

Retrieved from "https://wiki2.railml.org/index.php?title=User:Christian_Rößiger&oldid=7153"