TT:operatingPeriod: Difference between revisions

From railML 2 Wiki
Jump to navigation Jump to search
[checked revision][checked revision]
(any element added)
(Open issue added for the missing dayOffset attribute)
Line 34: Line 34:
* {{Attr|bitMask}}: This is a bit mask with {{Enum|0}} or {{Enum|1}} for every day of the {{TT:Doc|timetablePeriod}}.
* {{Attr|bitMask}}: This is a bit mask with {{Enum|0}} or {{Enum|1}} for every day of the {{TT:Doc|timetablePeriod}}.


* {{Attr|dayOffset}} {{Intro|2.2}}: An offset of {{Enum|1}} indicates that the train starts on the bitMask days but after midnight, so the real date differs from the bitMask date by 1.
* {{Attr|dayOffset}} {{Intro|2.2}}: An offset of {{Enum|1}} indicates that the train starts on the bitMask days but after midnight, so the real date differs from the bitMask date by 1. (Please see Open Issues below)
 
|notes =
Please note that <{{TT:Doc|ocpTT}}>.<{{TT:Doc|times}}>.{{Attr|arrivalDay}}/{{Attr|departureDay}} and <{{TT:Doc|operatingPeriod}}>.{{Attr|dayOffset}} are very similar working attributes but they are not the same. The actual offset from an <{{TT:Doc|operatingPeriod}}> to the actual days of an arrival is the ''sum'' of {{Attr|dayOffset}} and {{Attr|arrivalDay}} (and similar for departures).
 
So, if you have to create a <{{TT:Doc|trainPart}}> with {{Attr|departureDay}}=1 at its first <{{TT:Doc|ocpTT}}>, do not repeat the {{Attr|departureDay}}=1 with {{Attr|dayOffset}}=1 at the <{{TT:Doc|operatingPeriod}}> of that <{{TT:Doc|trainPart}}>! This would result in ''two'' days shift of the {{Attr|bitMask}} of <{{TT:Doc|operatingPeriod}}>.
 
The <{{TT:Doc|operatingPeriod}}>.{{Attr|dayOffset}}>0 is intended to be used if a <{{TT:Doc|trainPart}}> ran over midnight ''before it’s first <ocpTT>'' - so it ‘inherited’ the midnight overrun from an earlier section. In such a case, the <{{TT:Doc|trainPart}}> would refer to an <{{TT:Doc|operatingPeriod}}> with {{Attr|dayOffset}}=1 but ''nevertheless start with {{Attr|departureDay}}=0 at its first <ocpTT>''.
 
If then the <{{TT:Doc|trainPart}}> runs over midnight again (a second time in total) we do have the situation of {{Attr|departureDay}}=1 and <{{TT:Doc|operatingPeriod}}>.{{Attr|dayOffset}}=1 - meaning that there were really two midnight overruns, one inherited from an earlier section and one in the current section.
 
It seams as if it is redundant whether a <{{TT:Doc|trainPart}}> starts with {{Attr|departureDay}}=1 or refers to an <{{TT:Doc|operatingPeriod}}> with {{Attr|dayOffset}}=1. It is not, since a train shall always start with {{Attr|departureDay}}=0 at its fist <{{TT:Doc|ocpTT}}> in its first section; {{Attr|departureDay}}>0 is intended to happen only in first <{{TT:Doc|ocpTT}}>s in further sections.
 
For more information, see [[TT:Midnight_overrun | How to indicate midnight overruns in RailML]]


|constraints =
|constraints =
Line 73: Line 60:
* [http://www.irfp.de/download/railml_beispiel_verkehrstage.pdf Weitere Informationen und RailML-Beispiel zu Verkehrstagen, PDF, 185 kByte]
* [http://www.irfp.de/download/railml_beispiel_verkehrstage.pdf Weitere Informationen und RailML-Beispiel zu Verkehrstagen, PDF, 185 kByte]
* [http://www.irfp.de/download/railml_beispiel_mueg.pdf RailML-Beispiel zu Mitternachtsübergängen, PDF, 269 kByte]
* [http://www.irfp.de/download/railml_beispiel_mueg.pdf RailML-Beispiel zu Mitternachtsübergängen, PDF, 269 kByte]
|notes =
Please note that <{{TT:Doc|ocpTT}}>.<{{TT:Doc|times}}>.{{Attr|arrivalDay}}/{{Attr|departureDay}} and <{{TT:Doc|operatingPeriod}}>.{{Attr|dayOffset}} are very similar working attributes but they are not the same. The actual offset from an <{{TT:Doc|operatingPeriod}}> to the actual days of an arrival is the ''sum'' of {{Attr|dayOffset}} and {{Attr|arrivalDay}} (and similar for departures).
So, if you have to create a <{{TT:Doc|trainPart}}> with {{Attr|departureDay}}=1 at its first <{{TT:Doc|ocpTT}}>, do not repeat the {{Attr|departureDay}}=1 with {{Attr|dayOffset}}=1 at the <{{TT:Doc|operatingPeriod}}> of that <{{TT:Doc|trainPart}}>! This would result in ''two'' days shift of the {{Attr|bitMask}} of <{{TT:Doc|operatingPeriod}}>.
The <{{TT:Doc|operatingPeriod}}>.{{Attr|dayOffset}}>0 is intended to be used if a <{{TT:Doc|trainPart}}> ran over midnight ''before it’s first <ocpTT>'' - so it ‘inherited’ the midnight overrun from an earlier section. In such a case, the <{{TT:Doc|trainPart}}> would refer to an <{{TT:Doc|operatingPeriod}}> with {{Attr|dayOffset}}=1 but ''nevertheless start with {{Attr|departureDay}}=0 at its first <ocpTT>''.
If then the <{{TT:Doc|trainPart}}> runs over midnight again (a second time in total) we do have the situation of {{Attr|departureDay}}=1 and <{{TT:Doc|operatingPeriod}}>.{{Attr|dayOffset}}=1 - meaning that there were really two midnight overruns, one inherited from an earlier section and one in the current section.
It seams as if it is redundant whether a <{{TT:Doc|trainPart}}> starts with {{Attr|departureDay}}=1 or refers to an <{{TT:Doc|operatingPeriod}}> with {{Attr|dayOffset}}=1. It is not, since a train shall always start with {{Attr|departureDay}}=0 at its fist <{{TT:Doc|ocpTT}}> in its first section; {{Attr|departureDay}}>0 is intended to happen only in first <{{TT:Doc|ocpTT}}>s in further sections.


For more information, see [[TT:Midnight_overrun | How to indicate midnight overruns in RailML]]
|openissues =
The attribute {{Attr|dayOffset}} has not been implemented in railML and although it was documented in the Wiki it is not present in the railML 2.2 XSD definition! There is currently a discussion in the railML Forum to decide whether or not it shall be introduced in version 2.4 ([http://www.railml.org/forum/index.php?t=msg&th=523&start=0& Link to forum]).
|backHome = TT:elements
|backHome = TT:elements
}}
}}

Revision as of 11:57, 21 June 2017


operatingPeriod
 


Scheme description / Schemenbeschreibung

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

Multiplicity / Anzahl

[1..1]

Semantics / Bedeutung

The Element <operatingPeriod> describes the operation of a train. This could either be in relation to certain days of a calendar or abstract based on a standard week (or both).

Das Element <operatingPeriod> beschreibt die Verkehrsperiode eines Zuges. Dies kann entweder im Bezug auf konkrete Kalendertage oder abstrakt über eine wochenbasierte Beschreibung mittels operatingDay erfolgen (oder beides).

Attributes of operatingPeriod / Attribute von operatingPeriod

  • 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.
  • 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.
  • timetablePeriodRef: This refers to the id attribute of the associated <timetablePeriod> element.
  • startDate: This is the first day of the period, if the operating period is shorter than the underlying timetablePeriod.
    Die Angabe von startDate beschränkt die Anwendung der Bildungsregel des operatingDay-Elements auf diesen Datumsbereich.
  • endDate: This is the last day of the period, if the operating period is shorter than the underlying timetablePeriod.
    Die Angabe von endDate beschränkt die Anwendung der Bildungsregel des operatingDay-Elements auf diesen Datumsbereich.
  • bitMask: This is a bit mask with 0 or 1 for every day of the timetablePeriod.
  • dayOffset (introduced with version 2.2): An offset of 1 indicates that the train starts on the bitMask days but after midnight, so the real date differs from the bitMask date by 1. (Please see Open Issues below)

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
  • bitMask optional, consisting of the digits 0 and/or 1
    The "string-length" has to be the number of days in the time period defined through startDate and endDate of the <timetablePeriod> element.
    This means: If the timetable period is reduced by attributes startDate+endDate of the element operatingPeriod the difference quantity of days in the bitmask has to be set to 0 but not to be skipped.

The attributes startDate and endDate are not allowed to enhance the time period given by the referenced timetablePeriod.
startDate und endDate sind nur gemeinsam zu benutzen und dürfen nur Tage innerhalb der Gültigkeitsperiode der timetablePeriod referenzieren.

Best practice & Examples / Empfohlene Anwendung & Beispiele

  <operatingPeriod id="op15" name="15" description="Mo-Fr" timetablePeriodRef="tp2005" bitMask="011111001111000111100011111...111110" />

see also

Notes / Anmerkungen

Please note that <ocpTT>.<times>.arrivalDay/departureDay and <operatingPeriod>.dayOffset are very similar working attributes but they are not the same. The actual offset from an <operatingPeriod> to the actual days of an arrival is the sum of dayOffset and arrivalDay (and similar for departures).

So, if you have to create a <trainPart> with departureDay=1 at its first <ocpTT>, do not repeat the departureDay=1 with dayOffset=1 at the <operatingPeriod> of that <trainPart>! This would result in two days shift of the bitMask of <operatingPeriod>.

The <operatingPeriod>.dayOffset>0 is intended to be used if a <trainPart> ran over midnight before it’s first <ocpTT> - so it ‘inherited’ the midnight overrun from an earlier section. In such a case, the <trainPart> would refer to an <operatingPeriod> with dayOffset=1 but nevertheless start with departureDay=0 at its first <ocpTT>.

If then the <trainPart> runs over midnight again (a second time in total) we do have the situation of departureDay=1 and <operatingPeriod>.dayOffset=1 - meaning that there were really two midnight overruns, one inherited from an earlier section and one in the current section.

It seams as if it is redundant whether a <trainPart> starts with departureDay=1 or refers to an <operatingPeriod> with dayOffset=1. It is not, since a train shall always start with departureDay=0 at its fist <ocpTT> in its first section; departureDay>0 is intended to happen only in first <ocpTT>s in further sections.

For more information, see How to indicate midnight overruns in RailML

Open issues / Offene Punkte/Pendenzen

The attribute dayOffset has not been implemented in railML and although it was documented in the Wiki it is not present in the railML 2.2 XSD definition! There is currently a discussion in the railML Forum to decide whether or not it shall be introduced in version 2.4 (Link to forum).