View source for TT:trainPart

{{ElementDocu|
elementName = trainPart

|semantics =
The Element {{TT:Tag|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.

{{Deu|Das Element {{TT:Tag|trainPart}} beschreibt die kleinste Einheit eines Zuges. Innerhalb des Laufweges eines {{TT:Doc|trainPart}} sind daher keinerlei Wechsel der Zugkonfiguration oder der Verkehrsperiode möglich.}}

|parent = 
{{TT:Tag|trainParts}}

|childs = 
{{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 = 
{{InheritIdName
|id =
|code =
|name =
|description =
}}

|ownAttributes =
* {{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}}: Use {{Attr|line}} instead.

* {{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>
For more information on trains an train parts, see examples below and [[Dev:Train_Coupling_And_Sharing | Train Coupling And Sharing]].

* {{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
|selfLink = {{TT:Doc|trainPart}}
|processStatus =
|processStatus_de =
}}

* {{Attr|debitcode}}: This is a debitor code for financial considerations.

* {{Attr|remarks}}: This is a free remark for further description.{{human}}
{{InheritRef
|attributeName = timetablePeriodRef
|contextLink = {{TT:Tag|timetablePeriod}}
|notes_en =
}}

{{InheritRef
|attributeName = categoryRef
|contextLink = {{TT:Tag|category}}
|notes_en =
}}

* {{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 {{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 =
{{InheritIdNameConstraints}}

*{{Attr|line}} {{XsdType|string}}, optional

*{{Attr|trainLine}} {{XsdType|string}}, optional

*{{Attr|trainNumber}} {{XsdType|string}}, optional

*{{Attr|additionalTrainNumber}} {{XsdType|string}}, optional

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

*{{Attr|timetablePeriodRef}} {{RailMLType|tGenericRef}}, optional

*{{Attr|categoryRef}} {{RailMLType|tGenericRef}}, optional

*{{Attr|operator}} {{XsdType|string}}, 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 = 
===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.
;Example
Part of the City Night Line 242:
<syntaxhighlight lang=xml>
 <rail:trainPart id="CNL_242_2" trainNumber="242" processStatus="actual" 
  description="CNL 242" timetablePeriodRef="J08" categoryRef="cCNL">
  <rail:ocpsTT>
  ...
  </rail:ocpsTT>
 </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.

Up to and including version 2.4 of {{rml}}, it was not possible to represent demand trains in a standardized way. Often attempts were made to circumvent this shortcoming by means of a special train category, but this procedure always requires that at least the name of this special category is exchanged between the producer and the consumer. Another common solution was to use custom extensions of the standard, but this also required detailed coordination between producer and consumer. With {{rml|2.5}} it is now possible to mark a train as a demand train.

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.

{{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.<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 {{rml|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. }}
===Declaring vehicles as 'closed' (not accessable for public)===
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.

There are two alternative approaches:
# By assigning a {{tag|TT|category}} with the attribute {{@|deadrun}} set to true to the respective trainpart<syntaxhighlight lang=xml>
<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>
</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>

      <!-- 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>
</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
}}