|
|
Line 14: |
Line 14: |
| =={{Additional Information}}== | | =={{Additional Information}}== |
| ==={{Notes}}=== | | ==={{Notes}}=== |
| An {{TT:Tag|operationalTrainVariant}} is specific for a certain day. It shall not be used to describe different alternative train paths of a microscopic infrastructure model a train may go on a certain day, e.g. use track A or B to get from OP 1 to OP 2. | | An {{TT:Tag|operationalTrainVariant}} is specific for a certain day. It shall not be used to describe different alternative train paths of a microscopic infrastructure model <ref>[[IS:topology]]</ref> a train may go on a certain day, e.g. use track A or B to get from OP 1 to OP 2. |
| ==={{Open issues}}=== | | ==={{Open issues}}=== |
Revision as of 11:32, 6 August 2024
Introduction
Documentation
Syntax
|
Documentation
|
An operational train variant is a specific variant of a train that is operated in this way on all operating days indicated by the provided validity. It is expected that the validities of all operational train variants within an operational train do not overlap. The difference between one variant and the next of an operational train is that the trains path may differ to some degree.
|
Subschema
|
timetable
|
Parents*
|
operationalTrain
|
Children
|
identifiers (0..1), isCancelled (0..1), isOnRequest (0..1), operationalTrainSection (1..*)
|
Attributes:
- itineraryRef: References the itinerary of the operational train variant. The operational train variant is expected to stop or passthrough all of the OPs specified by the base itinerary points that are referenced by this itinerary. (obligatory;
xs:IDREF ),
- offset: Allows to specify a temporal offset to the times provided with the itinerary.
This means that the resulting arrival and departure times of the individual base itinerary points are calculated by adding the offset of the itinerary AND the offset of the operational train variant to them. Of course the offset may also be negative. (optional; xs:duration ),
- validityRef: Reference to a validity. This validity specifies if the operational train variant is operated on a certain day, or if it is not. (obligatory;
xs:IDREF ),
- id: the identifier of the object; this can be either of type xs:ID or UUID (obligatory;
xs:ID ); compare: Dev:Identities
|
*Notice: Elements may have different parent elements. As a consequence they may be used in different contexts. Please, consider this as well as a user of this Wiki as when developing this documentation further. Aspects that are only relevant with respect to one of several parents should be explained exclusively in the documentation of the respective parent element.
|
|
Documentation
|
An operational train variant is a specific variant of a train that is operated in this way on all operating days indicated by the provided validity. It is expected that the validities of all operational train variants within an operational train do not overlap. The difference between one variant and the next of an operational train is that the trains path may differ to some degree.
|
Subschema
|
timetable
|
Parents*
|
operationalTrain
|
Children
|
identifiers (0..1), isCancelled (0..1), isOnRequest (0..1), operationalTrainSection (1..*)
|
Attributes:
- itineraryRef: References the itinerary of the operational train variant. The operational train variant is expected to stop or passthrough all of the OPs specified by the base itinerary points that are referenced by this itinerary. (obligatory;
xs:string ; patterns: (urn:uuid:)?[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12}|{[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12}}),
- offset: Allows to specify a temporal offset to the times provided with the itinerary.
This means that the resulting arrival and departure times of the individual base itinerary points are calculated by adding the offset of the itinerary AND the offset of the operational train variant to them. Of course the offset may also be negative. (optional; xs:duration ),
- validityRef: Reference to a validity. This validity specifies if the operational train variant is operated on a certain day, or if it is not. (obligatory;
xs:string ; patterns: (urn:uuid:)?[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12}|{[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12}}),
- id: unique identifier (obligatory;
xs:string ; patterns: (urn:uuid:)?[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12}|{[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12}}); compare: Dev:Identities
|
*Notice: Elements may have different parent elements. As a consequence they may be used in different contexts. Please, consider this as well as a user of this Wiki as when developing this documentation further. Aspects that are only relevant with respect to one of several parents should be explained exclusively in the documentation of the respective parent element.
|
This element does not appear in railML® 3.1 within the TT subschema. It is available only in railML® 3.2, 3.3. Do not hesitate to contact railML.org for further questions.
Changes 3.1→3.2
There exists an overview of all changes between railML® 3.1 and railML® 3.2 on page Dev:Changes/3.2.
Introduced with version 3.2.
Changes 3.2→3.3
There exists an overview of all changes between railML® 3.2 and railML® 3.3 on page Dev:Changes/3.3.
The parents have been changed.
The children have been changed.
The attributes have been changed.
Semantics
Best Practice / Examples
Additional Information
Notes
An <operationalTrainVariant> is specific for a certain day. It shall not be used to describe different alternative train paths of a microscopic infrastructure model [1] a train may go on a certain day, e.g. use track A or B to get from OP 1 to OP 2.
Open Issues