User:Christian Rößiger

This page is under construction since December 04th 2017. Task: Adjust layout. Sorry for temporary problems. See the discussion page to find a summary of the tasks and to coordinate the work on this page. Recognize that the content of this page may change quickly. Coordination --Coordination (talk) 10:13, 4 December 2017 (CET)

Specifying the stop position of a train within a station / Angabe der Halteposition eines Zuges in einer Betriebsstelle

General / Allgemeines

In general there is two ways of specifying the stop position within a station/operational stop:

1. Direct specification of the stop position within the train part
2. Referring to a <stopPost>-element of the infrastructure

If a railML file already includes the definition of <stopPost>-elements as part of the infrastructure, these stopPosts should also be used to specify the stop position. Within one railML file only one approach to specifying stop positions should be used consistently.

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.

Direct specification of the stop position within the train part / Angabe der Halteposition direkt im Zuglauf

For this approach the stop position of a train is specified with the attribute offset of the <ocpTT>. It describes the offset to the center of the operation control point measuring from a reference point of the train indicated by the attribute alignment. In this case the direction of the train - which be required for evaluating this information - can only be determined by analyzing the the train part and its underlying topology.

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>

In the above example the stop position of a train at the station "Zürich HB" is specified with 10 m in front of the center of the station measured from the head of the train (alignment=head).

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

Referring to a <stopPost>-element of the infrastructure / Referenzierung eines Halteplatzes (<stopPost>) der Infrastruktur

With this approach the stop position is not specified within the <trainPart>s. Instead, <stopPost> elements are included in the infrastructure which can be referred to from an <ocpTT> using the attribute stopPostRef.

A <stopPost> is defined as a child element of a <track>. This implies that for each <stopPost> required, a corresponding <track> needs to be specified as part of the infrastructure. In order to specify a designation for a <stopPost> the attributes code and name can be supplied. code should be used to indicate an external key, used to identify a corresponding object in an infrastructure database. name can be used to specify a display name which for example could be used for passenger information. In order to specify the exact position of the <stopPost> on the containing <track> the attribute pos is used.

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>

In the above example a train stops at the station "Zürich HB" at the stop post with the external key "B". The display name of the stop post is given as "Sektor B". 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".

Additional information / Weitere Informationen

• How To Reference Infrastructure
• Todo: Link auf Angabe Bahnhofsgleisnutzung/Bahnsteigkante

---

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