User:Christian Rößiger: Difference between revisions

From railML 2 Wiki
Jump to navigation Jump to search
(Beispiele für Referenzierung von Bahnsteiggleisen ergänzt)
(Überarbeitung Artikel für Bahnhofsgleisreferenzierung und Halteposition)
Line 1: Line 1:
= Referenzierung von Bahnhofsgleisen, Bahnsteigkanten und Halteplätzen im makroskopischen Infrastrukturmodell =  
= {{Deu|Angabe der durch einen Zug benutzten Gleise in einer Betriebsstelle und Bahnsteigkanten}} =  


Generell existieren 3 verschieden Möglichkeiten im makroskopischen Infrastrukturmodell die Nutzung bestimmter Bahnhofsgleise und Bahnsteigkanten abzubilden:
== {{Deu|Allgemeines}} ==


== Ohne Abbildung von Bahnhofsgleisen in der Infrastruktur ==
{{Deu|Grundsätzlich bestehen zwei alternative Möglichkeiten zur Abbildung der Gleisnutzungs-Informationen innerhalb einer Betriebsstelle:}}
# {{Deu|Angabe der Gleisbezeichnung direkt im Zuglauf}}
# {{Deu|Referenzierung von Elementen der Infrastruktur (Bahnhofsgleise, Bahnsteigkanten) aus dem Zuglauf, welche die eigentlichen Informationen tragen}}


Sollen in der Infrastruktur keine {{IS:Tag|track}}-Elemente angelegt werden, so kann das von einem Zug benutzte Bahnhofsgleis im Attribut {{Attr|trackInfo}} der {{TT:Tag|ocpTT}} angegeben werden. Eine Angabe einer Bahnsteigkanten-Bezeichnung ist bei dieser Abbildungsvariante nicht möglich.  
{{Deu|Sind in der Infrastruktur einer railML-Datei ohnehin die Gleise einer Betriebsstelle definiert, so sollten diese auch referenziert werden. Innerhalb einer railML-Datei sollte die Abbildung der Gleisnutzung einheitlich in einer der beiden Varianten erfolgen.}}


Das Beispiel beschreibt einen Zug, der in der Betriebsstelle "Zürich HB" das Gleis mit der betrieblichen Bezeichnung "12" benutzt.
== {{Deu|Angabe der Gleisbezeichnung direkt im Zuglauf}} ==
 
{{Deu|Bei dieser Variante kann auf die Angabe von {{IS:Tag|track}}-Elementen für die Gleise innerhalb einer {{IS:Tag|ocp}} verzichtet werden. Der Name des von einem Zug genutzten Bahnhofsgleises wird direkt im Attribut {{Attr|trackInfo}} der {{TT:Tag|ocpTT}} angegeben. Eine Angabe einer Bahnsteigkanten-Bezeichnung ist bei dieser Abbildungsvariante nicht möglich.}}


<syntaxhighlight lang=xml>
<syntaxhighlight lang=xml>
Line 17: Line 21:
</syntaxhighlight>
</syntaxhighlight>


== Referenzierung von Bahnhofsgleisen (ohne Angabe einer platformEdge) ==
{{Deu|Das (unvollständige) Beispiel beschreibt einen Zug, der in der Betriebsstelle "Zürich HB" das Gleis mit der betrieblichen Bezeichnung "12" benutzt.}}
 
Die Bahnsteig- bzw. Gleisbezeichnung ist nicht innerhalb des {{TT:Tag|trainPart}}s angegeben, stattdessen wird in der Infrastruktur ein {{IS:Tag|track}}-Element angelegt, welches von der {{TT:Tag|ocpTT}} über das Attribut {{Attr|trackRef}} referenziert wird. Der Name des Gleises wird im Attribut {{Attr|code}} und der Name der Bahnsteigkante im Attribut {{Attr|name}} des {{IS:Tag|track}}s angegeben. Das referenzierte Bahnhofsgleis sollte am {{IS:Tag|trackBegin}} / {{IS:Tag|trackEnd}} über das Attribut {{Attr|ocpRef}} die jeweilige {{IS:Tag|ocp}} referenzieren.


Ungünstig ist bei dieser Variante die Verwendung des Attributs {{Attr|name}} des {{IS:Tag|track}}s für die Bezeichnung der Bahnsteigkante, da dieses Attribut üblicherweise den Namen des Elements, hier also des {{IS:Tag|track}}s enthalten sollte.
== {{Deu|Referenzierung von Bahnhofsgleisen und Bahnsteigkanten (platformEdge)}} ==


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


<syntaxhighlight lang=xml>
{{Deu|Ein {{IS:Tag|track}} innerhalb einer {{IS:Tag|ocp}} ist dadurch gekennzeichnet, dass seine jeweiligen {{IS:Tag|trackBegin}}- / {{IS:Tag|trackEnd}}-Elemente über das Attribut {{Attr|ocpRef}} die gleiche {{IS:Tag|ocp}} referenzieren. Die Referenzierung von der {{TT:Tag|ocpTT}} erfolgt über das Attribut {{Attr|trackRef}}.}}
  <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>
</syntaxhighlight>


== Referenzierung von Bahnhofsgleisen und Bahnsteigkanten (platformEdge) ==
{{Deu|Eine {{IS:Tag|platformEdge}} wird als Unterelement eines {{IS:Tag|track}} abgebildet, d.h. für jede {{IS:Tag|platformEdge}} muss auch ein entsprechender {{IS:Tag|track}} in der Infrastruktur angelegt werden. Die Referenzierung der {{IS:Tag|platformEdge}} von der {{TT:Tag|ocpTT}} erfolgt über das Attribut {{Attr|ref}} des {{TT:Tag|platformEdgeRef}}-Elements. Da das {{TT:Tag|platformEdgeRef}} ein Child-Element einer {{TT:Tag|stopDescription}} ist, können Bahnsteigkanten nur für diejenigen {{TT:Tag|ocpTT}} angegeben werden, an denen der Zug hält.}}
Zusätzlich zur vorigen Variante wird innerhalb eines {{IS:Tag|track}}-Elements zusätzlich ein eigenes {{IS:Tag|platformEdge}}-Element angelegt. Der Name der Bahnsteigkante kann jetzt direkt im {{Attr|code}}-Attribute des {{IS:Tag|platformEdge}}-Element angegeben werden. Aus der {{TT:Tag|ocpTT}} wird die {{IS:Tag|platformEdge}} über das Attribut {{Attr|ref}} des {{TT:Tag|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.
{{Deu|Die Angabe des Attributs {{Attr|pos}} der {{IS:Tag|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.}}


<syntaxhighlight lang=xml>
<syntaxhighlight lang=xml>
   <track id="_tr" code="12" type="stationTrack">
   <track id="_tr" code="12" name="12">
     <trackTopology>
     <trackTopology>
       <trackBegin id="_tb" pos="0">
       <trackBegin id="_tb" pos="0">
         <macroscopicNode ocpRef="_85ZUE" />
         <macroscopicNode ocpRef="_85ZUE" />
       </trackBegin>
       </trackBegin>
       <trackEnd id="_te" pos="647">
       <trackEnd id="_te" pos="0">
         <macroscopicNode ocpRef="_85ZUE" />
         <macroscopicNode ocpRef="_85ZUE" />
       </trackEnd>
       </trackEnd>
Line 63: Line 46:
     <trackElements>
     <trackElements>
       <platformEdges>
       <platformEdges>
         <platformEdge id="_pe" code="1" pos="55" />
         <platformEdge id="_pe" code="1" name="1A" pos="0" />
       </platformEdges>
       </platformEdges>
     </trackElements>
     </trackElements>
Line 78: Line 61:
</syntaxhighlight>
</syntaxhighlight>


= Angabe der Halteposition in einer Betriebsstelle =
{{Deu|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".}}
== Abbildung in Relation zur Betriebsstellenmitte ==
 
== {{Deu|Weitere Informationen}} ==
* [[TT:How_To_Reference_Infrastructure|How To Reference Infrastructure]]
* Todo: Link auf Angabe der Halteposition
 
<hr>


Das Beispiel beschreibt einen Zug, der in der Betriebsstelle "Zürich HB" mit der Zugspitze ({{Attr|alignment}}=head) 10m vor dem Betriebsstellen-Querschnitt hält.
= {{Deu|Angabe der Halteposition eines Zuges in einer Betriebsstelle}} =
== {{Deu|Allgemeines}} ==
{{Deu|Grundsätzlich bestehen zwei alternative Möglichkeiten zur Abbildung der Halteposition innerhalb einer Betriebsstelle:}}
# {{Deu|Angabe der Halteposition direkt im Zuglauf}}
# {{Deu|Referenzierung eines {{IS:Tag|stopPost}}-Elements der Infrastruktur}}
{{Deu|Sind in einer railML-Datei {{IS:Tag|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.}}
 
== {{Deu|Angabe der Halteposition direkt im Zuglauf}} ==
 
{{Deu|In dieser Abbildungsvariante wird die Halteposition des Zuges in der {{TT:Tag|ocpTT}} durch eine Entfernung ({{Attr|offset}}) zur Betriebsstellenmitte sowie den Bezugspunkt des Zuges ({{Attr|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.}}


<syntaxhighlight lang=xml>
<syntaxhighlight lang=xml>
Line 91: Line 88:
</syntaxhighlight>
</syntaxhighlight>


== Abbildung über die Angabe von Halteplätzen (<stopPost>) ==
{{Deu|Das Beispiel beschreibt einen Zug, der in der Betriebsstelle "Zürich HB" mit der Zugspitze ({{Attr|alignment}}<nowiki>=head</nowiki>) 10m vor der Betriebsstellen-Mitte hält.}}
 
== {{Deu|Referenzierung eines Halteplatzes (<stopPost>) der Infrastruktur}} ==
 
{{Deu|Bei dieser Abbildungsvariante wird der Halteort nicht innerhalb des {{TT:Tag|trainPart}}s angegeben, stattdessen wird in der Infrastruktur ein {{IS:Tag|stopPost}}-Element angelegt, welches über das Attribut {{Attr|stopPostRef}} der jeweiligen {{TT:Tag|ocpTT}} referenziert wird.}}
 
{{Deu|Ein {{IS:Tag|stopPost}} wird als Unterelement eines {{IS:Tag|track}} abgebildet, d.h. für jeden {{IS:Tag|stopPost}} muss auch ein entsprechender {{IS:Tag|track}} in der Infrastruktur angelegt werden. Die Bezeichnung des {{IS:Tag|stopPost}} kann mit Hilfe der Attribute {{Attr|code}} bzw. {{Attr|name}} definiert werden, wobei {{Attr|code}} für einen externen Schlüssel (bspw. in einer Infrastruktur-Datenbank) vorgesehen ist, während {{Attr|name}} einen Anzeigenamen enthalten kann. Die genaue Halteposition des Zuges kann über die Eigenschaft {{Attr|pos}} des {{IS:Tag|stopPost}} auf dem übergeordneten {{IS:Tag|track}} definiert werden.}}


<syntaxhighlight lang=xml>
<syntaxhighlight lang=xml>
   <track id="_tr">
   <track id="_tr" code="12" name="12">
     <trackTopology>
     <trackTopology>
       <trackBegin id="_tb" pos="0">
       <trackBegin id="_tb" pos="0">
Line 106: Line 109:
     <ocsElements>
     <ocsElements>
       <stopPosts>
       <stopPosts>
         <stopPost id="_sp" pos="10"/>
         <stopPost id="_sp" code="B" name="Sektor B"  pos="10"/>
       </stopPosts>
       </stopPosts>
     </ocsElements>
     </ocsElements>
Line 117: Line 120:
   </ocpTT>
   </ocpTT>
</syntaxhighlight>
</syntaxhighlight>
{{Deu|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".}}
== {{Deu|Weitere Informationen}} ==
* [[TT:How_To_Reference_Infrastructure|How To Reference Infrastructure]]
* Todo: Link auf Angabe Bahnhofsgleisnutzung/Bahnsteigkante


<hr>
<hr>

Revision as of 15:02, 10 November 2017

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

Eine <platformEdge> 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 das <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