(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Introduction
Documentation
Syntax
|
Documentation
|
Commercial connections describe a unidirectional relationship between trains that can be used by passengers or goods to transfer from one train to another.
|
Subschema
|
timetable
|
Parents*
|
commercialConnections
|
Children
|
connector (1..1), feeder (1..1)
|
Attributes:
- maximalWaitingTime: Maximal acceptable departure delay of the connector to facilitate the connection. The connector may elide waiting for the feeder, if this would require its operational departure to be delayed w.r.t. the scheduled time by more than the specified waiting time.
Specifying a zero here means that the connector does not wait for the feeder. Specifying no maximalWaitingTime means that the source system of the railML does not have that information. (optional; xs:duration ),
- responsibleOrganizationalUnitRef: Organizational unit responsible for securing the connection. Needs to be specified if it is a managed connection.
If maxWaitingTime needs to be extended this Organization should be contacted. (optional; xs:IDREF ),
- minimalTransferTime: The minimalTransferTime is the time which is at least necessary for the passengers or freight that are transferred from the feeder to the connector to traverse the distance between the two trains.
If no minimalTransferTime is specified here the times defined in the connectionTransferTimes at the root level of the timetable subschema apply. (optional; xs:duration )
|
*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
|
Commercial connections describe a unidirectional relationship between trains that can be used by passengers or goods to transfer from one train to another.
|
Subschema
|
timetable
|
Parents*
|
commercialConnections
|
Children
|
connector (1..1), feeder (1..1)
|
Attributes:
- maximalWaitingTime: Maximal acceptable departure delay of the connector to facilitate the connection. The connector may elide waiting for the feeder, if this would require its operational departure to be delayed w.r.t. the scheduled time by more than the specified waiting time.
Specifying a zero here means that the connector does not wait for the feeder. Specifying no maximalWaitingTime means that the source system of the railML does not have that information. (optional; xs:duration ),
- responsibleOrganizationalUnitRef: Organizational unit responsible for securing the connection. Needs to be specified if it is a managed connection.
If maxWaitingTime needs to be extended this Organization should be contacted. (optional; 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}}),
- minimalTransferTime: The minimalTransferTime is the time which is at least necessary for the passengers or freight that are transferred from the feeder to the connector to traverse the distance between the two trains.
If no minimalTransferTime is specified here the times defined in the connectionTransferTimes at the root level of the timetable subschema apply. (optional; xs:duration )
|
*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. 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 children have been changed.
The attributes have been changed.
Semantics
Best Practice / Examples
Additional Information
Notes
Open Issues