User:Christian Rößiger

From railML 2 Wiki
Revision as of 20:02, 18 November 2017 by RailML Coord Governance (talk | contribs) (→‎{{Deu|Allgemeines}}: railML durch {{rml}} ersetzt; Hinweis auf Zug ergänzt)
Jump to navigation Jump to search

Angabe der durch einen Zug benutzten Gleise in einer Betriebsstelle und Bahnsteigkanten

Allgemeines

Grundsätzlich bestehen zwei alternative Möglichkeiten zur Abbildung der Gleisnutzungs-Informationen innerhalb einer Betriebsstelle:

  1. Angabe der Gleisbezeichnung direkt im Zuglauf
  2. Referenzierung von Elementen der Infrastruktur (Bahnhofsgleise, Bahnsteigkanten) aus dem Zuglauf, welche die eigentlichen Informationen tragen

Sind in der Infrastruktur einer railML®-Datei ohnehin die Gleise einer Betriebsstelle definiert, so sollten diese auch durch den Fahrplan des Zuges referenziert werden. Innerhalb einer railML®-Datei sollte die Abbildung der Gleisnutzung einheitlich in einer der beiden Varianten erfolgen.

Angabe der Gleisbezeichnung direkt im Zuglauf

Bei dieser Variante kann auf die Angabe von <track>-Elementen für die Gleise innerhalb einer <ocp> verzichtet werden. Der Name des von einem Zug genutzten Bahnhofsgleises wird direkt im Attribut trackInfo der <ocpTT> angegeben. Eine Angabe einer Bahnsteigkanten-Bezeichnung ist bei dieser Abbildungsvariante nicht möglich.

  <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>

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

Referenzierung von Bahnhofsgleisen und Bahnsteigkanten (platformEdge)

Bei dieser Abbildungsvariante wird die Bahnsteig- bzw. Gleisbezeichnung nicht innerhalb des <trainPart>s angegeben, stattdessen werden in der Infrastruktur entsprechende Elemente <track> bzw. <platformEdge> angelegt, die von der jeweiligen <ocpTT> des <trainPart>s referenziert werden. Die eigentlichen Bezeichnungen werden dann an den Elementen der Infrastruktur abgebildet. Hierfür können die Attribute code bzw. name verwendet werden, wobei code für einen externen Schlüssel (bspw. in einer Infrastruktur-Datenbank) vorgesehen ist, während name einen Anzeigenamen enthalten kann.

Ein <track> innerhalb einer <ocp> ist dadurch gekennzeichnet, dass seine jeweiligen <trackBegin>- / <trackEnd>-Elemente über das Attribut ocpRef die gleiche <ocp> referenzieren. Die Referenzierung von der <ocpTT> erfolgt über das Attribut trackRef.

Die Angabe einer <platformEdge> ist optional, d.h. sie muss nur definiert werden, wenn in der railML-Datei Angaben zu Bahnsteigkanten enthalten sein sollen und der jeweilige <track> über eine Bahnsteigkante verfügt. Sie wird als Unterelement eines <track> abgebildet, d.h. für jede <platformEdge> muss auch ein entsprechender <track> in der Infrastruktur angelegt werden. Die Referenzierung der <platformEdge> von der <ocpTT> erfolgt über das Attribut ref des <platformEdgeRef>-Elements. Da die <platformEdgeRef> ein Child-Element einer <stopDescription> ist, können Bahnsteigkanten nur für diejenigen <ocpTT> angegeben werden, an denen der Zug hält. Die Angabe des Attributs pos der <platformEdge> ist nicht in allen Anwendungsfällen (bspw. Fahrgastinformation) fachlich relevant, wird aber durch das railML-Schema erfordert. In diesen Fällen kann dieses Attribut auf den Wert 0 gesetzt werden.

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

    <trackElements>
      <platformEdges>
        <platformEdge id="_pe" code="1" name="1A" pos="0" />
      </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>

Das (unvollständige) Beispiel zeigt einen Zug, der in der Betriebsstelle "Zürich HB" das Gleis mit der betrieblichen Bezeichnung "12" und die Bahnsteigkante mit externen Schlüssel "1" nutzt. Der Anzeigename der Bahnsteigkante hat den Wert "1A".

Weitere Informationen


Angabe der Halteposition eines Zuges in einer Betriebsstelle

Allgemeines

Grundsätzlich bestehen zwei alternative Möglichkeiten zur Abbildung der Halteposition innerhalb einer Betriebsstelle:

  1. Angabe der Halteposition direkt im Zuglauf
  2. Referenzierung eines <stopPost>-Elements der Infrastruktur

Sind in einer railML-Datei <stopPost>-Elemente definiert, so sollten diese auch referenziert werden. Innerhalb einer railML-Datei sollte die Abbildung der Halteposition einheitlich in einer der beiden Varianten erfolgen.

Angabe der Halteposition direkt im Zuglauf

In dieser Abbildungsvariante wird die Halteposition des Zuges in der <ocpTT> durch eine Entfernung (offset) zur Betriebsstellenmitte sowie den Bezugspunkt des Zuges (alignment) darauf definiert. Die Fahrtrichtung des Zuges an diesem Halteplatz kann dabei nur implizit durch Analyse des Zug-Laufwegs und der Strecken-Topologie ermittelt werden.

  <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>

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

Referenzierung eines Halteplatzes (<stopPost>) der Infrastruktur

Bei dieser Abbildungsvariante wird der Halteort nicht innerhalb des <trainPart>s angegeben, stattdessen wird in der Infrastruktur ein <stopPost>-Element angelegt, welches über das Attribut stopPostRef der jeweiligen <ocpTT> referenziert wird.

Ein <stopPost> wird als Unterelement eines <track> abgebildet, d.h. für jeden <stopPost> muss auch ein entsprechender <track> in der Infrastruktur angelegt werden. Die Bezeichnung des <stopPost> kann mit Hilfe der Attribute code bzw. name definiert werden, wobei code für einen externen Schlüssel (bspw. in einer Infrastruktur-Datenbank) vorgesehen ist, während name einen Anzeigenamen enthalten kann. Die genaue Halteposition des Zuges kann über die Eigenschaft pos des <stopPost> auf dem übergeordneten <track> definiert werden.

  <track id="_tr" code="12" name="12">
    <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" code="B" name="Sektor B" 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>

Das Beispiel beschreibt einen Zug, der in der Betriebsstelle "Zürich HB" am Halteplatz mit dem externen Schlüssel "B" hält. Der Anzeigename dieses Halteplatzes ist "Sektor B".

Weitere Informationen



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