TT:trainPart: Difference between revisions
[checked revision] | [checked revision] |
(+) |
(syntax) |
||
Line 96: | Line 96: | ||
</rail:ocpsTT> | </rail:ocpsTT> | ||
</rail:trainPart> | </rail:trainPart> | ||
</syntaxhighlight>{{unlock|2.4|2= | </syntaxhighlight>{{unlock|2.4|2=<br> | ||
===Usage of {{@|onRequest}}=== | ===Usage of {{@|onRequest}}=== | ||
{{deu|1=Bedarfszüge sind Züge, die im Rahmen der Fahrplanplanung bereits geplant werden. Es werden also bereits Fahrwege mit entsprechenden Fahrzeiten durch das Netz geplant, allerdings ist bei diesen Zügen von vornherein klar, dass diese nur nach Eingriff des Disponenten eingesetzt werden. Tatsächlich schwindet die Bedeutung solcher Bedarfszüge mit zunehmender Verbesserung der beteiligten Systeme | {{deu|1=Bedarfszüge sind Züge, die im Rahmen der Fahrplanplanung bereits geplant werden. Es werden also bereits Fahrwege mit entsprechenden Fahrzeiten durch das Netz geplant, allerdings ist bei diesen Zügen von vornherein klar, dass diese nur nach Eingriff des Disponenten eingesetzt werden. Tatsächlich schwindet die Bedeutung solcher Bedarfszüge mit zunehmender Verbesserung der beteiligten Systeme | ||
nach und nach, da das Planen eines neuen Zuges stetig mit geringerem Aufwand verbunden ist. Nichtsdestotrotz arbeiten viele EVU nach wie vor mit diesem Konzept. | nach und nach, da das Planen eines neuen Zuges stetig mit geringerem Aufwand verbunden ist. Nichtsdestotrotz arbeiten viele EVU nach wie vor mit diesem Konzept.<br><br>Bis einschließlich Version 2.4 von {{rml}} war es nicht möglich Bedarfszüge standardisiert abzubilden. Oft wurde mittels einer besonderen Zugskategorie versucht diesen Mangel zu umgehen, allerdings erfordert dieses Vorgehen immer, dass zwischen Produzent und Konsument zumindest der Name dieser Spezialkategorie ausgetauscht wird. Eine andere verbreitete Lösung war die Nutzung von Custom-Erweiterungen des Standards, die aber ebenfalls eine detaillierte Abstimmung zwischen Produzenten und Konsumenten erforderte. Mit railML 2.5 ist es nun möglich einen Zug als Bedarfszug zu markieren.<br><br>Um Bedarfszüge in {{rml|2.5}} als solche zu markieren wurde die Definition des Elements {{tag|TT|trainPart}} um das boolesche Attribut {{@|onRequest}} erweitert. Bei einem reinen Bedarfszug würden also alle trainParts eines {{tag|TT|train}} mit {{@|onRequest}} = „true“ markiert werden. Über diese Modellierung ist es natürlich auch möglich nur Teile von Fahrten als „Bei Bedarf“ zu kennzeichnen, etwa um einen Zug im Falle hohen Fahrgastaufkommens über das geplante Ziel hinaus fahren bzw. früher einsetzen zu lassen. }} | ||
Bis einschließlich Version 2.4 von {{rml}} war es nicht möglich Bedarfszüge standardisiert abzubilden. Oft wurde mittels einer besonderen Zugskategorie versucht diesen Mangel zu umgehen, allerdings erfordert dieses Vorgehen immer, dass zwischen Produzent und Konsument zumindest der Name dieser Spezialkategorie ausgetauscht wird. Eine andere verbreitete Lösung war die Nutzung von Custom-Erweiterungen des Standards, die aber ebenfalls eine detaillierte Abstimmung zwischen Produzenten und Konsumenten erforderte. Mit railML 2.5 ist es nun möglich einen Zug als Bedarfszug zu markieren. | |||
Um Bedarfszüge in {{rml|2.5}} als solche zu markieren wurde die Definition des Elements {{tag|TT|trainPart}} um das boolesche Attribut {{@|onRequest}} erweitert. Bei einem reinen Bedarfszug würden also alle trainParts eines {{tag|TT|train}} mit {{@|onRequest}} = „true“ markiert werden. Über diese Modellierung ist es natürlich auch möglich nur Teile von Fahrten als „Bei Bedarf“ zu kennzeichnen, etwa um einen Zug im Falle hohen Fahrgastaufkommens über das geplante Ziel hinaus fahren bzw. früher einsetzen zu lassen. }} | |||
}} | }} | ||
|backHome = TT:elements | |backHome = TT:elements | ||
}} | }} |
Revision as of 16:25, 21 September 2020
trainPart
Scheme description / Schemenbeschreibung
Position of trainPart in the XML-Tree / Position von trainPart im XML-Baum
- Parent: <trainParts>
- Children: <additionalName> (introduced with version 2.1), <formationTT>, <operatingPeriodRef>, <ocpsTT>, <organizationalUnitBinding> (introduced with version 2.2), <annotationRef> (introduced with version 2.2), <origin> (introduced with version 2.5), <destination> (introduced with version 2.5), <xs:any>
Multiplicity / Anzahl
Semantics / Bedeutung
The Element <trainPart> describes the most basic part of a train. Hence there is no changement of the formation or operating period allowed during a train parts route.
Das Element <trainPart> beschreibt die kleinste Einheit eines Zuges. Innerhalb des Laufweges eines trainPart sind daher keinerlei Wechsel der Zugkonfiguration oder der Verkehrsperiode möglich.
Attributes of trainPart / Attribute von trainPart
- 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. - line: This is the code or number of the train service that this train part belongs to. Linienbezeichnung.
- trainLine (deprecated with version 2.1): Use line instead.
- trainNumber: This attribute may contain the number of the train part or the number of the corresponding train (as the name may suggest). There is no direct way to identify the number of the corresponding train since there may be for instance an operational and a commercial train referring to this train part. However, it is possible to follow the attribute <trainPartRef>.ref from any train to find out which one (or more) refers to the current train part.
For more information on trains an train parts, see examples below and Train Coupling And Sharing.
- additionalTrainNumber: The precise semantics of this attribute are not fixed in the standard. The general idea for this is to allow for specifying an attribute that distinguishes between trains, that though running with the same train number, are alternative variants of a train. In general identity is very important when it comes to data transfers, in particular with updates to previous data transfers. In order to achieve a unique identity several attributes can be used, such as trainNumber, scope and <organizationalUnitBinding>. If variants still exist, using these, or if identity cannot be achieved that way (e.g. organizational unit data is not available in the participating systems), additionalTrainNumber may be used to distinguish between variants of a train part.
- processStatus: It describes the trainPart status in relation to a working process. (deprecated with version 2.5)
|
Possible values are:
- planned
- actual
- calculated
- toBeChecked
- changed
- imported
- 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.
- debitcode: This is a debitor code for financial considerations.
- remarks: This is a free remark for further description.
|
- timetablePeriodRef: This refers to the id attribute of the associated <timetablePeriod> element.
- categoryRef: This refers to the id attribute of the associated <category> element.
- operator (deprecated with version 2.3): This is the train operator. It is recommended to use <organizationalUnitBinding> instead of operator.
- cancellation (introduced with version 2.3): Indicates, that this trainPart is no longer valid and should be canceled out of a previously delivered set (i. e. out of a previously railML® file).
- onRequest (introduced with version 2.5): indicates, that this trainPart is considered on request if this flag is true. This means that there is a planned train, but normally its not run.
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
- line xs:string, optional
- trainLine xs:string, optional
- trainNumber xs:string, optional
- additionalTrainNumber xs:string, optional
- debitcode xs:integer, optional
|
- remarks xs:string, optional
- timetablePeriodRef xs:IDREF, optional
- categoryRef xs:IDREF, optional
- operator xs:string, optional
- cancellation xs:boolean, optional
- onRequest xs:boolean
Best practice & Examples / Empfohlene Anwendung & Beispiele
Usage of @scope
- See Modeling of supplementary timetables using the 'scope' attribute ()
- Siehe Abbildung von Ergänzungsfahrplänen unter Verwendung des ‚scope‘-Attributes ()
Usage of @trainNumber
The same <trainPart> could be referenced by several operational and commercial trains. Therefore the trainNumber within a trainPart is in the best case redundant, if it is used as a shortcut to the commercial train number. The recommended practice is to use trainNumber only on train level.
Example
Part of the City Night Line 242:
<rail:trainPart id="CNL_242_2" trainNumber="242" processStatus="actual" description="CNL 242" timetablePeriodRef="J08" categoryRef="cCNL"> <rail:ocpsTT> ... </rail:ocpsTT> </rail:trainPart>
Usage of @onRequest
Bedarfszüge sind Züge, die im Rahmen der Fahrplanplanung bereits geplant werden. Es werden also bereits Fahrwege mit entsprechenden Fahrzeiten durch das Netz geplant, allerdings ist bei diesen Zügen von vornherein klar, dass diese nur nach Eingriff des Disponenten eingesetzt werden. Tatsächlich schwindet die Bedeutung solcher Bedarfszüge mit zunehmender Verbesserung der beteiligten Systeme
nach und nach, da das Planen eines neuen Zuges stetig mit geringerem Aufwand verbunden ist. Nichtsdestotrotz arbeiten viele EVU nach wie vor mit diesem Konzept.
Bis einschließlich Version 2.4 von railML® war es nicht möglich Bedarfszüge standardisiert abzubilden. Oft wurde mittels einer besonderen Zugskategorie versucht diesen Mangel zu umgehen, allerdings erfordert dieses Vorgehen immer, dass zwischen Produzent und Konsument zumindest der Name dieser Spezialkategorie ausgetauscht wird. Eine andere verbreitete Lösung war die Nutzung von Custom-Erweiterungen des Standards, die aber ebenfalls eine detaillierte Abstimmung zwischen Produzenten und Konsumenten erforderte. Mit railML 2.5 ist es nun möglich einen Zug als Bedarfszug zu markieren.
Um Bedarfszüge in railML® 2.5 als solche zu markieren wurde die Definition des Elements <trainPart> um das boolesche Attribut @onRequest erweitert. Bei einem reinen Bedarfszug würden also alle trainParts eines <train> mit @onRequest = „true“ markiert werden. Über diese Modellierung ist es natürlich auch möglich nur Teile von Fahrten als „Bei Bedarf“ zu kennzeichnen, etwa um einen Zug im Falle hohen Fahrgastaufkommens über das geplante Ziel hinaus fahren bzw. früher einsetzen zu lassen.
Notes / Anmerkungen
There are several ways to describe an empty run (inside a station) or depot run. If it is planned in all details in the timetable, it is treated as a train and will be defined with appropriate <ocpTT>'s in the trainPart, possibly with <serviceSectionRef>'s if known. If it is loosely planned with time constants but not infrastructural references, it is not treated as a train run and will be defined as <blockPart> with an appropriate mission value.
To find out whether a train part is passenger or freight hauling, see Train types, categories, products, and passenger usage.
Open issues / Offene Punkte/Pendenzen
Not yet described. / Noch nicht beschrieben.