TT:rostering

From railML 2 Wiki
Jump to navigation Jump to search


rostering
 


Scheme description / Schemenbeschreibung

Position of rostering in the XML-Tree / Position von rostering im XML-Baum

Multiplicity / Anzahl

[1..∞]

Semantics / Bedeutung

The element <rostering> contains all data, which are related to a working schedule (rostering). This schedule is focussed on the trains rather than on the personell operating the trains.

In dem Element <rostering> werden alle Informationen für einen Umlaufplan beschrieben. Dieser Fahrplan konzentriert sich auf die Züge und nicht auf das Personal, das die Züge bedient.

Please, be aware of the semantic constraint(s)!
 
Please, be aware of the semantic constraint(s)!

Attributes of rostering / Attribute von rostering

  • id: XML-file-wide unique, machine-interpretable identity, required for later referencing that element internally. For a detailed explanation see Dev:identities.
    XML-Datei-weit eindeutige, maschineninterpretierbare Identität, die für die spätere interne Referenzierung dieses Elements erforderlich ist. Für eine detaillierte Erklärung siehe Dev:identities.
  • code (introduced with version 2.1): Machine-interpretable string (e.g. an abbreviation) used for identification of the object across exchange partners, usecase specific uniqueness constraints may apply. Please see our description of the differences between id, code and human-readable identifiers.
    Maschineninterpretierbare Zeichenkette (z.B. Abkürzung), die zur Identifizierung des Objekts auch bei Austauschpartnern verwendet wird, wobei spezifische Eindeutigkeitsbeschränkungen gelten können. Bitte beachten Sie unsere Erläuterung zu den Unterschieden zwischen id, code and menschenlesbaren Kennzeichnungen.
    This is the short string which is known for identifying the rostering across the involved staff.
  • name: Established, human-readable short string, giving the object a name. Not intended for machine interpretation, please see our notice on human interpretable data fields.
    Etablierte, menschenlesbare kurze Zeichenkette, die das Objekt benennt. Nicht zur maschinellen Interpretation bestimmt, siehe Hinweise zu menschenlesbaren Datenfeldern.
  • description: Human-readable, more detailed description as addition to the name. It should give additional explanations or hints to the contents of this element. Not intended for machine interpretation, please see our notice on human interpretable data fields.
    Menschenlesbare, detailliertere Beschreibung als Ergänzung zu name. Sie soll zusätzliche Erläuterungen oder Hinweise auf den Inhalt dieses Elements geben. Nicht zur maschinellen Interpretation bestimmt, siehe Hinweise zu menschenlesbaren Datenfeldern.
  • xml:lang (introduced with version 2.1): This is a unique identifier of language. It uses basically the language standard IETF BCP 47 (external link) which may be different to ISO 639-1 (external link) or ISO 639-2 (external link). For mapping hints see relation to other standards (external link).
    This defines the language used for name and description. Use <additionalName> to provide a name and/or description in other languages.
  • vehicleRef: This refers to the id attribute of the associated <vehicle> element.
    This "default vehicle" is normally identical for all blockParts, but can be superset by a certain blockPart.
  • formationRef: This refers to the id attribute of the associated <formation> element.
    This "default formation" is normally identical for all blockParts, but can be superset by certain blockPart.
  • depot: This is the depot or location the rostering belongs to.
  • defaultPreProcessingTime: This is the default duration from the beginning of blocking of the ressource until start of blockPart.
    definiert die (Standard-)Vorbereitungszeit, die gilt, wenn keine abweichende Angabe bei blockPartSequence erfolgt
  • defaultPostProcessingTime: This is the default duration from the end of blockPart until the end of blocking of the ressource.
    definiert die (Standard-)Nachbereitungszeit, die gilt, wenn keine abweichende Angabe bei blockPartSequence erfolgt
  • scope: Allows identifying a real rostering from input to rostering and conceptual rosterings. Possible values are:
  • conceptional for conceptual vehicle schedules.
  • operational for operational rosters (individual vehicles, calendar days), usually the output of rostering systems that is used in subsequent systems, such as TMS
  • timetable a rostering with this scope actually is no rostering at all, it carries restrictions and conditions that are input to a rostering calculation
  • other:anything: Any value that does not fit any value from the previous enumeration list, fulfilling the constraint: at minimum two characters, whitespace is not allowed. Please, apply Dev:usingAny accordingly.

Syntactic Constraints / Syntaktische Beschränkungen

  • id: xs:ID, required
    a string, starting with a letter (a..zA..Z) or an underscore (_),
    followed by a non-colonized and non-spaced string consisting of letters, digits, points (.), dashes (-) or underscores (_)
  • code: xs:string, optional
  • name: xs:string, optional
  • description: xs:string, optional
  • xml:lang: xs:language, language identification, optional
  • scope: union of (restriction of xs:string, tOtherEnumerationValue); tOtherEnumerationValue is an arbitrary string starting with 'other:' followed by at minimum two characters, white space not allowed for extending railML® enumeration lists, optional

Semantic Constraints / Semantische Beschränkungen

Private-cloud-icon.png Semantic Constraint "TT:005":
 
vehicleRef and formationRef are to be used exceptional since the circulation plan is either one for a certain vehicle or one for a whole formation.
Es ist nur entweder vehicleRef oder formationRef anzugeben (nicht jedoch beide gleichzeitig), da es sich entweder um einen Umlauf eines Einzelfahrzeugs oder einer Fahrzeuggruppe handelt.
 
Proposed on May 22nd 2019
Approved on June 25th 2019
FIXME: add Link to discussion!
Please, recognize our guidelines on semantic constraints

Best practice & Examples / Empfohlene Anwendung & Beispiele

see railML®-Beispiel Umlauf aus FBS (external link, May 2012, PDF, 🇩🇪; by Dirk Bräuer, iRFP Dresden)

Notes / Anmerkungen

Starting with version 2.4 <blocks> has been made optional in order to allow for modelling of special track occupation. See the forum discussion: https://www.railml.org/forum/index.php?t=msg&th=571&start=0& (link to the railML® website)

Mit Version 2.4 wurde <blocks> als optional zugelassen. Damit soll ermöglicht werden Sonderbelegungen eines Gleises abzubilden. Siehe dazu im Forum: https://www.railml.org/forum/index.php?t=msg&th=571&start=0& (link to the railML® website)

Usage of @scope

The attribute @scope was introduced to allow users to exchange a timetable that already contains information that influences rostering calculation, although no rostering calculation has been performed yet. For example the fact that two consecutive trips are required to be operated with the same vehicles can be provided as input for a rostering calculation. In order to keep this kind of interconnection apart from connection information the attribute @scope was introduced. A rostering that contains the mentioned constraints for a rostering calculation is marked with the @scope enumeration value timetable, whereas a the result of a rostering calculation is identified by the value operational. It is assumed that a rostering calculation would result in a complete rostering that includes all parts described with a <rostering> of @scope timetable. The operationally relevant rostering is the one marked with the value operational. If no @scope is provided for this optional attribute its value is assumed to be operational for reasons of backward-compatibility.

For further information see: raiML forum section

Das Attribut @scope wurde eingeführt, damit Benutzer einen Fahrplan austauschen können, der bereits Informationen enthält, die die Umlaufberechnung beeinflussen, auch wenn noch keine Umlaufberechnung durchgeführt worden ist. So kann z.B. die Tatsache, dass zwei aufeinanderfolgende Fahrten mit denselben Fahrzeugen, der selben Formation, durchgeführt werden sollen, als Input für eine Umlaufberechnung beschrieben werden. Um diese Art der Verknüpfung von den Anschlussinformationen getrennt zu halten, wurde das Attribut @scope eingeführt. Ein Umlaufplan, der die genannten Randbedingungen für eine Umlaufberechnung enthält, wird mit @scope timetable gekennzeichnet, während das Ergebnis einer Umlaufberechnung durch den Wert operational gekennzeichnet ist. Es wird angenommen, dass eine Umlaufberechnung zu einem vollständigen Umlauf führt, der die mit einem <rostering> vom Typ @scope timetable beschriebenen Teile vollständig beinhaltet.
Das <rostering>, das operativ relevant ist, ist mit dem Wert operational gekennzeichnet. Wird dieses optionale Attribut nicht angegeben, so wird aus Gründen der Abwärtskompatibilität der Wert operational angenommen.

Für weitere Informationen finden Sie hier: railML® forum section (link to the railML® website)

Open issues / Offene Punkte/Pendenzen

Not yet described. / Noch nicht beschrieben.

Retrieved from "https://wiki2.railml.org/index.php?title=TT:rostering&oldid=15307"