User:Christian Rößiger

From railML 2 Wiki
Revision as of 10:23, 8 May 2017 by Christian Rößiger (talk | contribs) (Added chapter stop descriptions)
Jump to navigation Jump to search

Default values of stop description and their dependencies

Nr. <ocpTT> <stopDescription>
ocpType guaranteedPass commercial onOff stopOnRequest operationalStopordered
1.1 pass true not allowed not allowed not allowed not allowed
1.2 false not allowed not allowed not allowed not allowed
2.1 stop, begin, end not allowed true both true not allowed
2.2 not allowed true both false not allowed
2.3 not allowed true on true not allowed
2.4 not allowed true on false not allowed
2.5 not allowed true off true not allowed
2.6 not allowed true off false not allowed
2.7 not allowed false not allowed true true
2.8 not allowed false not allowed true false
2.9 not allowed false not allowed false true
2.10 not allowed false not allowed false false
  • 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"

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