TT:trainPart: Difference between revisions

From railML 2 Wiki
Jump to navigation Jump to search
[unchecked revision][checked revision]
No edit summary
(removed section that was untrue claiming the inablílity of modelling on request trains in railML prior to 2.5)
 
(40 intermediate revisions by 7 users not shown)
Line 11: Line 11:


|childs =  
|childs =  
{{TT:Tag|additionalName|trainPart}} {{Intro|2.1}}, {{TT:Tag|formationTT}}, {{TT:Tag|operatingPeriodRef}}, {{TT:Tag|ocpsTT}}, {{TT:Tag|organizationalUnitBinding}} {{Intro|2.2}}, {{TT:Tag|annotationRef|trainPart}} {{Intro|2.2}}
{{TT:Tag|additionalName|trainPart}} {{Intro|2.1}}, {{TT:Tag|formationTT}}, {{TT:Tag|operatingPeriodRef|trainPart}}, {{TT:Tag|ocpsTT|trainPart}}, {{TT:Tag|organizationalUnitBinding|trainPart}} {{Intro|2.2}}, {{TT:Tag|annotationRef|trainPart}} {{Intro|2.2}}, {{TT:Tag|origin}} {{intro|2.5}}, {{tag|TT|destination}} {{intro|2.5}}, {{any}}
 
|maxocc=∞
|inheritedAttributes =  
|inheritedAttributes =  
{{InheritIdName
{{InheritIdName
Line 22: Line 22:


|ownAttributes =
|ownAttributes =
* {{Attr|line}} {{Intro|2.0}}: This is the "train part line", which could be different from the "train line".
* {{Attr|line}}: This is the code or number of the train ''service'' that this train part belongs to.<br/>{{Deu|Linienbezeichnung des Zuges, zu dem dieser Zugteil gehört.}}


* {{Attr|trainLine}} {{Depr|2.1}}: This is the "train line", used differently.
* {{Attr|trainLine}} {{Depr|2.1}}: Use {{Attr|line}} instead.


* {{Attr|trainNumber}}:<br>
* {{Attr|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 {{TT:Tag|trainPartRef}}.{{Attr|ref}} from any train to find out which one (or more) refers to the current train part.<br>
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 {{TT:Tag|trainPartRef}}.{{Attr|ref}} from any train to find out which one (or more) refers to the current train part.<br>
For more information on trains an train parts, see examples below and [[Dev:Train_Coupling_And_Sharing | Train Coupling And Sharing]].
For more information on trains an train parts, see examples below and [[TT:Train_Coupling_And_Sharing | Train Coupling And Sharing]].


* {{Attr|additionalTrainNumber}}: This is a train number appendix, used to provide uniqueness.
* {{Attr|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 {{Attr|trainNumber}}, {{Attr|scope}} and {{TT:Tag|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), {{Attr|additionalTrainNumber}} may be used to distinguish between variants of a train part.


{{InheritProcessStatus
{{InheritProcessStatus
Line 38: Line 37:
}}
}}


* {{Attr|debitcode}}: This is a debitor code for finacial considerations.
* {{Attr|debitcode}}: This is a debitor code for financial considerations.
 
* {{Attr|remarks}}: This is a free remark for further description.


* {{Attr|remarks}}: This is a free remark for further description.{{human}}
{{InheritRef
{{InheritRef
|attributeName = timetablePeriodRef
|attributeName = timetablePeriodRef
Line 54: Line 52:
}}
}}


* {{Attr|operator}} {{Depr|2.3}}:  This is a train operator. Due to the new element {{TT:Tag|organizationalUnitBinding}} from version 2.2, it is recommended to rather use {{TT:Tag|organizationalUnitBinding}} than {{Attr|operator}}, which may become deprecated in future.
* {{Attr|operator}} {{Depr|2.3}}:  This is the train operator. It is recommended to use {{TT:Tag|organizationalUnitBinding}} instead of {{Attr|operator}}.
 
* {{Attr|cancellation}} {{Intro|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).


* {{Attr|cancellation}} {{Intro|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 {{rml}} file).
*{{attr|onRequest}} {{intro|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.
*{{attr|lineTTRef}} {{intro|2.5}}: This refers to the id attribute of the associated {{TT:Tag|lineTT}} element.
*{{Attr|lastModified}} {{intro|2.5}}: This allows specifying when the {{TT:Tag|trainPart}} last was changed in the exporting system. May be used by importing systems to detect changed {{TT:Tag|trainPart}}s.
|constraints =
|constraints =
{{InheritIdNameConstraints}}
{{InheritIdNameConstraints}}
Line 69: Line 69:
*{{Attr|additionalTrainNumber}} {{XsdType|string}}, optional
*{{Attr|additionalTrainNumber}} {{XsdType|string}}, optional


*{{Attr|debitcode}} {{XsdType|integer}}, optional
*{{Attr|debitcode}} {{XsdType|integer}}, optional{{human}}
 
*{{Attr|remarks}} {{XsdType|string}}, optional
*{{Attr|remarks}} {{XsdType|string}}, optional


Line 80: Line 79:


*{{Attr|cancellation}} {{XsdType|boolean}}, optional
*{{Attr|cancellation}} {{XsdType|boolean}}, optional
*{{attr|onRequest}} {{XsdType|boolean}}
*{{Attr|lineTTRef}} {{RailMLType|tGenericRef}}, optional
*{{Attr|lastModified}} {{XsdType|dateTime}}, optional
|notes = 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 {{TT:Tag|ocpTT}}'s in the {{TT:Doc|trainPart}}, possibly with {{TT:Tag|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 {{TT:Tag|blockPart}} with an appropriate {{Attr|mission}} value.


To find out whether a train part is passenger or freight hauling, see [[Dev:categoryUsage|Train types, categories, products, and passenger usage]].
|bestpractice =  
|bestpractice =  
===Discussed within timetable meeting in Vienna 16.03.2015:===
===Usage of {{@|trainNumber}}===
 
The same {{TT:Tag|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.
'''trainNumber:''' The same {{TT:Tag|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
 
|notes = 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 {{TT:Doc|ocpTT}}'s in the {{TT:Doc|trainPart}}, possibly with {{TT:Doc|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 {{TT:Doc|blockPart}} with an appropriate {{Attr|mission}} value.
 
To find out whether a train part is passenger or freight hauling, see [[TT:categoryUsage|Train types, categories, products, and passenger usage]].
 
|example =
==== Example 1 ====
Part of the City Night Line 242:
Part of the City Night Line 242:
 
<syntaxhighlight lang=xml>
  <rail:trainPart id="CNL_242_2" trainNumber="242" processStatus="actual"  
  <rail:trainPart id="CNL_242_2" trainNumber="242" processStatus="actual"  
   description="CNL 242" timetablePeriodRef="J08" categoryRef="cCNL">
   description="CNL 242" timetablePeriodRef="J08" categoryRef="cCNL">
Line 100: Line 97:
   </rail:ocpsTT>
   </rail:ocpsTT>
  </rail:trainPart>
  </rail:trainPart>
</syntaxhighlight><br>
===Usage of {{@|onRequest}}===
Demand trains are trains that are already planned in the timetable planning. This means that routes with corresponding travel times through the network are already planned, but with these trains it is clear from the outset that they will only be used after intervention by the scheduler. In fact, the importance of such on-demand trains is gradually diminishing as the systems involved improve, since planning a new train is always associated with less effort. Nevertheless, many railway companies still work with this concept.


==== Example 2: Meaning of train parts and usage of trainNumber, code, sequence, position, and name ====
In order to mark demand trains as such in {{rml}}2.5, the definition of the element {{tag|TT|trainPart}} has been extended by the Boolean attribute {{@|onRequest}}. Thus, in the case of a pure demand train, all trainParts of a <train> would be marked with {{@|onRequest}} = "true". Of course it is also possible to mark only parts of a train as "on demand", for example to let a train exceed the planned destination in case of high passenger volume or to let it start earlier.
The following “trains” may be assumed to be published:<br>
* 456 Praha – Amsterdam (branded “Phoenix”)<br>
* 458 Praha – Zürich (branded “Canopus”)<br>
* 60456 Praha – Berlin<br>
* 61458 Praha – Erfurt<br>
The “trains” run coupled between Praha and Dresden. In railML, they are entitled as commercial trains. (In the 2014 timetable there were more trains involved in reality. This has been simplified a little bit for the purposes of this example.)<br>
 
From the operational point of view, there are the following operational trains:<br>
* 456 Praha – Amsterdam<br>
* 458 Dresden – Zürich<br>
Please note that the numbers of the operational are identical with some numbers of commercial trains. But, this does by far not mean that these trains are identical! It is only that different objects have the same numbers (one could say: by coincidence).<br>
 
<trainParts> in railML:
 
<syntaxhighlight lang="xml">
<trainPart id='tp_1.1' name=’Phoenix’ code='456' trainNumber='456' … />
<trainPart id='tp_1.2' name=’Phoenix’ code='456' trainNumber='456' … />
<trainPart id='tp_2.1' name=’Canopus’ code='458' trainNumber='458' … />
<trainPart id='tp_2.2' name=’Canopus’ code='458' trainNumber='458' … />
<trainPart id='tp_3.1' code='60456' trainNumber='60456' … />
<trainPart id='tp_3.2' code='60456' trainNumber='60456' … />
<trainPart id='tp_4.1' code='61458' trainNumber='61458' … />
<trainPart id='tp_4.2' code='61458' trainNumber='61458' … />
</syntaxhighlight>
 
commercial trains:
 
<syntaxhighlight lang="xml">
<train id='trc_1' trainNumber='456' name=’Phoenix’ type='commercial'>
  <trainPartSequence sequence='1'> //section Praha - Dresden
    <trainPartRef ref='tp_1.1' position='1'/>
  </trainPartSequence>
  <trainPartSequence sequence='2'> //section Dresden - Amsterdam
    <trainPartRef ref='tp_1.2' position='1'/>
  </trainPartSequence>
</train>


<train id='trc_2' trainNumber='458' name=’Canopus’ type='commercial'>
{{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
  <trainPartSequence sequence='1'> //section Praha - Dresden
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>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. }}
    <trainPartRef ref='tp_2.1' position='3’/>
===Declaring vehicles as 'closed' (not accessable for public)===
  </trainPartSequence>
Declaring vehicles as 'closed' in {{rml|2}} only works at the level of the trainPart. If the use case requires a specific vehicle or group of vehicles of the trainPart to be declared as closed, a separate trainPart must be created for it.
  <trainPartSequence sequence='2'> //section Dresden - Zürich
    <trainPartRef ref='tp_2.2' position='1'/>
  </trainPartSequence>
</train>


<train id='trc_3' trainNumber='60456' type='commercial'>
There are two alternative approaches:
  <trainPartSequence sequence='1'> //section Praha - Dresden
# By assigning a {{tag|TT|category}} with the attribute {{@|deadrun}} set to true to the respective trainpart<syntaxhighlight lang=xml>
     <trainPartRef ref='tp_3.1' position='2'/>
<railml>
   </trainPartSequence>
  <timetable>
   <trainPartSequence sequence='2'> //section Dresden - Amsterdam
    <categories>
    <trainPartRef ref='tp_3.2' position='2'/>
      <category id="cat_1" code="Lt" name="Empty Run; No passengers" deadrun="true" />
  </trainPartSequence>
    </categories>
</train>
    <trainParts>
      <trainPart id="tp_1" categoryRef="cat_1">
        <ocpsTT>
        </ocpsTT>
      </trainPart>
     </trainParts>
   </timetable>
</railml>
</syntaxhighlight>
# By overwriting the capacity ({{tag|TT|places}}) and available {{tag|TT|service}}s provided by the vehicles with reduced values at the trainpart / {{tag|TT|formationTT}}<syntaxhighlight lang=xml>
<railml>
   <rollingstock>
    <vehicles>
      <vehicle id="veh_1" name="DMU642">
        <wagon>
          <places category="class1" count="12" />
          <places category="class2" count="109" />
        </wagon>
      </vehicle>
    </vehicles>
    <formations>


<train id='trc_4' trainNumber='61458' type='commercial'>
      <!-- formation is made up of 2 identical vehicles, they technically provide a total of 2x12=24 seats 1st class and 2x109=218 seats 2nd class -->
  <trainPartSequence sequence='1'> //section Praha - Dresden
      <formation id="frm_1" name="2xDMU642">
    <trainPartRef ref='tp_4.1' position='4'/>
        <trainOrder>
  </trainPartSequence> //section Dresden - Zürich
          <vehicleRef orderNumber="1" vehicleRef="veh_1" vehicleCount="2" />
  <trainPartSequence sequence='2'>
        </trainOrder>
    <trainPartRef ref='tp_4.2' position='2'/>
      </formation>
  </trainPartSequence>
</train>
</syntaxhighlight>  


operational trains:
    </formations>
  </rollingstock>
  <timetable>
    <trainParts>


<syntaxhighlight lang="xml">
      <!-- Example a): One of the two vehicles is closed for passengers -->
<train id='tro_1' type='operational' trainNumber='456'>
      <trainPart id="tp_1">
  <trainPartSequence sequence='1'> //section Praha - Dresden
        <formationTT formationRef="frm_1">
    <trainPartRef ref='tp_1.1' position='1'/>
          <!-- Number of places 1st/2nd class of the vehicles is overwritten by the actually available number of places -->
    <trainPartRef ref='tp_3.1' position='2'/>
          <passengerUsage>
    <trainPartRef ref='tp_2.1' position='3'/>
            <places category="class1" count="12" />
    <trainPartRef ref='tp_4.1' position='4'/>
            <places category="class2" count="109" />
  </trainPartSequence>
          </passengerUsage>
  <trainPartSequence sequence='2'> //section Dresden - Amsterdam
        <formationTT>
    <trainPartRef ref='tp_1.2' position='1'/>
        <ocpsTT>
    <trainPartRef ref='tp_3.2' position='2'/>
        </ocpsTT>
  </trainPartSequence>
      </trainPart>
</train>


<train id='tro_2' type='operational' trainNumber='458'>
      <!-- Example b): None of the vehicles is accessable for passengers -->
  <trainPartSequence sequence='1'> //section Dresden - Zürich
      <trainPart id="tp_2">
    <trainPartRef ref='tp_2.2' position='1'/>
        <formationTT formationRef="frm_1">
    <trainPartRef ref='tp_4.2' position='2'/>
          <!-- number of places 1st/2nd class is overwritten by zero -->
  </trainPartSequence>
          <passengerUsage>
</train>
            <places category="class1" count="0" />
</syntaxhighlight>  
            <places category="class2" count="0" />
          </passengerUsage>
        </formationTT>
      </trainPart>


    </trainParts>
  </timetable>
</railml>
</syntaxhighlight>This approach also allows to declare only parts of a vehicle (e.g. one train compartment) as closed.
=== How To Encode Bus Replacements ===
Compare [[Dev:How To Encode Bus Replacements]]
|backHome = TT:elements
|backHome = TT:elements
}}
}}

Latest revision as of 18:07, 10 December 2024


trainPart
 


Schema description / Schemenbeschreibung

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

Multiplicity / Anzahl

[1..∞]

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 des Zuges, zu dem dieser Zugteil gehört.
  • 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)
🗒️ The semantics of the attribute values for @processStatus have not been fully defined in the past. In general the attribute shall describe a state of the process supported by railML®. Therefore the precise semantics shall be clarified between data provider and the data consumer.
Examples:
If an updated version of a timetable is transferred, the @processStatus is used by some systems to indicate if a train was changed compared to the previous data transfer by providing @processStatus=changed.
For the use case slot ordering the attribute is used with the value planned by some systems to describe that a train has been planned in the scheduling tool, but hasn’t been taken into account for the slot ordering process.

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.
💡 Please take into account our references to human-intepretable data fields.

Bitte berücksichtigen Sie unsere Hinweise zu menschen-intepretierbaren Datenfeldern.

  • 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.
  • lineTTRef (introduced with version 2.5): This refers to the id attribute of the associated <lineTT> element.
  • lastModified (introduced with version 2.5): This allows specifying when the <trainPart> last was changed in the exporting system. May be used by importing systems to detect changed <trainPart>s.

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
💡 Please take into account our references to human-intepretable data fields.

Bitte berücksichtigen Sie unsere Hinweise zu menschen-intepretierbaren Datenfeldern.

Best practice & Examples / Empfohlene Anwendung & Beispiele

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

Demand trains are trains that are already planned in the timetable planning. This means that routes with corresponding travel times through the network are already planned, but with these trains it is clear from the outset that they will only be used after intervention by the scheduler. In fact, the importance of such on-demand trains is gradually diminishing as the systems involved improve, since planning a new train is always associated with less effort. Nevertheless, many railway companies still work with this concept.

In order to mark demand trains as such in railML®2.5, the definition of the element <trainPart> has been extended by the Boolean attribute @onRequest. Thus, in the case of a pure demand train, all trainParts of a <train> would be marked with @onRequest = "true". Of course it is also possible to mark only parts of a train as "on demand", for example to let a train exceed the planned destination in case of high passenger volume or to let it start earlier.

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.

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.

Declaring vehicles as 'closed' (not accessable for public)

Declaring vehicles as 'closed' in railML® 2 only works at the level of the trainPart. If the use case requires a specific vehicle or group of vehicles of the trainPart to be declared as closed, a separate trainPart must be created for it.

There are two alternative approaches:

  1. By assigning a <category> with the attribute @deadrun set to true to the respective trainpart
    <railml>
      <timetable>
        <categories>
          <category id="cat_1" code="Lt" name="Empty Run; No passengers" deadrun="true" />
        </categories>
        <trainParts>
          <trainPart id="tp_1" categoryRef="cat_1">
            <ocpsTT>
            </ocpsTT>
          </trainPart>
        </trainParts>
      </timetable>
    </railml>
  2. By overwriting the capacity (<places>) and available <service>s provided by the vehicles with reduced values at the trainpart / <formationTT>
    <railml>
      <rollingstock>
        <vehicles>
          <vehicle id="veh_1" name="DMU642">
            <wagon>
              <places category="class1" count="12" />
              <places category="class2" count="109" />
            </wagon>
          </vehicle>
        </vehicles>
        <formations>
    
          <!-- formation is made up of 2 identical vehicles, they technically provide a total of 2x12=24 seats 1st class and 2x109=218 seats 2nd class -->
          <formation id="frm_1" name="2xDMU642">
            <trainOrder>
              <vehicleRef orderNumber="1" vehicleRef="veh_1" vehicleCount="2" />
            </trainOrder>
          </formation>
    
        </formations>
      </rollingstock>
      <timetable>
        <trainParts>
    
          <!-- Example a): One of the two vehicles is closed for passengers -->
          <trainPart id="tp_1">
            <formationTT formationRef="frm_1">
              <!-- Number of places 1st/2nd class of the vehicles is overwritten by the actually available number of places -->
              <passengerUsage>
                <places category="class1" count="12" />
                <places category="class2" count="109" />
              </passengerUsage>
            <formationTT>
            <ocpsTT>
            </ocpsTT>
          </trainPart>
    
          <!-- Example b): None of the vehicles is accessable for passengers -->
          <trainPart id="tp_2">
            <formationTT formationRef="frm_1">
              <!-- number of places 1st/2nd class is overwritten by zero -->
              <passengerUsage>
                <places category="class1" count="0" />
                <places category="class2" count="0" />
              </passengerUsage>
            </formationTT>
          </trainPart>
    
        </trainParts>
      </timetable>
    </railml>
    This approach also allows to declare only parts of a vehicle (e.g. one train compartment) as closed.

How To Encode Bus Replacements

Compare Dev:How To Encode Bus Replacements

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.