TT:ocpTT ocpsTT trainPart
ocpTT
Scheme description / Schemenbeschreibung
Position of ocpTT in the XML-Tree / Position von ocpTT im XML-Baum
- Parent: <ocpsTT>
- Children: <times>, <connections>, <statistics>, <sectionTT>, <alternativeSectionsTT> (introduced with version 2.5), <stopDescription>, <originalTrackInfo> (introduced with version 2.5), <xs:any>
Multiplicity / Anzahl
Semantics / Bedeutung
The element ocpTT describes a single point along the train path. Normally, an ocpTT belongs to a station with an arrivial and departure time. But an ocpTT could also be a blocking signal with or without passing time, or some control point on the train path. It is always referencing a certain ocp defined in the infrastructure part, providing some timetable related information for it. In the British railway timetabling system the ocpTT is called TIPLOC by Network Rail, which is a contraction of TIming Point LOCation.
Das Element ocpTT beschreibt den einzelnen Punkt im Zuglauf. Der ocpTT entspricht einem Fahrzeitmesspunkt. Ein Fahrzeitmesspunkt kann, muss aber keine Betriebsstelle sein. Meist ist ein ocpTT gleichzusetzen mit einen Bahnhof und der dortigen Ankunfts- und Abfahrtszeit. Es kann aber genauso gut ein Blocksignal mit oder ohne Durchfahrtszeit oder auch ein beliebiger Messpunkt auf der Strecke sein. Der jeweilige ocpTT verweist immer auf einen in der Infrastruktur definierten ocp und beschreibt dessen Verwendung im Fahrplan. Als Regel darf jeder ocpTT nur einmal innerhalb eines trainParts auftauchen.
Please, be aware of the semantic constraint(s)!
Attributes of ocpTT / Attribute von ocpTT
- ocpRef: This refers to the id attribute of the associated ocp element.
- trackRef: This refers to the id attribute of the associated track element.
- sequence: (introduced with version 2.2) This number defines the order of the ocpTT elements inside a trainPart which is supposed to be chronological.
- trackInfo: Textual description of station track for information purposes. The real track and platform information can and should be identified via the trackRef attribute.
- ocpType: This is a mixture of two informations describing the action of the train at this ocpTT. Possible values are:
- stop The train is stopping at this ocpTT.
- pass The train is not stopping at this ocpTT and will pass.
- begin (deprecated with version 2.2) If the trainPart begins at this ocpTT and is not part of a longer train path, this value is used. The start of a train path should be detected by parsing the trains.
- end (deprecated with version 2.2) If the trainPart ends at this ocpTT and is not part of a longer train path, this value is used. The end of a train path should be detected by parsing the trains.
- remarks: This is a free attribute for further descriptions.
|
- trainReverse: This is true if the train changes its direction of travel at this station which is sometimes shown by a sign "↔" in printouts for passengers. For indicating that the formation starts in reversed order, you will have to set the attribute orientationReversed in the formationTT. If the train reverses at an intermediate station and restarts in reversed order, you will have to build a new trainPart with
- trainReverse set at the last ocpTT of the previous trainPart and
- trainReverse set at the first ocpTT and the attribute orientationReversed set in the formationTT of the new trainPart.
- For more information, see Reversing trains and formations.
- alignment: This describes the alignment of the arriving train in relation to the place on a track referenced by ocpRef. Possible values are:
- head - The head of the train (front of first vehicle) is located at the <ocp> referenced by ocpRef, possibly shifted by offset metres.
- center - The centre of the train (mid point concerning the train length) is located at the <ocp> referenced by ocpRef, possibly shifted by offset metres.
- rear - The end of the train (back of last vehicle) is located at the <ocp> referenced by ocpRef, possibly shifted by offset metres.
- The default value for alignment is center if the attribute is not specified.
- offset: This describes the offset of the stopping point in relation to the place on a track referenced by ocpRef in metres. The default value is zero (no offset).
- shuntingTime: (deprecated with version 2.5) This is the shunting time used inside a station in case the train is shunted there.
- xs:anyAttribute: This provides an extension point for non-railML® attributes in a foreign namespace. How to use it?
Syntactic Constraints / Syntaktische Beschränkungen
- sequence: xs:positiveInteger, mandatory
- ocpRef: xs:IDREF, mandatory
- trackRef: xs:IDREF, optional
- trackInfo: xs:string, optional
- ocpType: restriction of xs:sting; stop, pass, begin (deprecated with version 2.2), end (deprecated with version 2.2)
Optional - remarks: xs:string, optional
- trainReverse: xs:boolean, optional
- alignment: restriction of xs:string; generic type for the alignment of a train relative to some objective in the used context (head, center, rear), optional
- offset: xs:decimal, 6 fraction digits, length value measured in meter, optional
- shuntingTime: xs:duration, optional (deprecated with version 2.5)
Semantic Constraints / Semantische Beschränkungen
|
Best practice & Examples / Empfohlene Anwendung & Beispiele
How to define track and platform usage in stations
The trackRef can reference either a microscopic <track> inside the <ocp> (containing a <crossSection>) or a macroscopic station track (one where <trackBegin> and <trackEnd> contain <macroscopicNode>s referencing the same <ocp>).
See How to define track usage of a train in stations for further information about the indication of station track usage.
Train reverses in a station
The train is stopping in Zurich (referenced ocp) on track 12 (no reference here). It is stopping with its head 10 meters before actually reaching the cross section of this ocp, which is assumed to be located at the buffer stop in the main hall of this station. Then the train is changing direction and leaving. In this example the train path is split into two subsequent trainParts because the position of the train (attributes alignment and offset) is different for arrival and departure.
<trainPart id="..."> <ocpsTT> ... <ocpTT sequence="35" ocpRef="_85ZUE" ocpType="stop" trackInfo="12" alignment="head" offset="-10"> <times scope="scheduled" arrival="10:56:00.0"/> </ocpTT> </ocpsTT> </trainPart> <trainPart id="..."> <ocpsTT> <ocpTT sequence="1" ocpRef="_85ZUE" ocpType="stop" trackInfo="12" alignment="rear" trainReverse="true" offset="10"> <times scope="scheduled" departure="11:04:00.0"/> </ocpTT> ... <ocpsTT> </trainPart>
On the difference between ocpTT/@trainReverse and formationTT/@orientationReversed, see Reversing trains and formations.
See also:
Depicting track changes
(introduced with version 2.5)To see how to handle the case when the actual track differs from the originally scheduled track, see the description of depicting track changes.
@ocpType at the first and last stop
Software that reads a railML® document should also be able to handle <trainPart>'s whose first and/or last <ocpTT> has the value @ocpType specified as pass. This situation can occur in different scenarios. If, for example, incoming or outgoing traffic is described in railML®, it is often the case that the first <ocp> does not represent a stop, but rather encodes the time at which a train enters or leaves the network. Another reason may be that data on the <trainPart> changes and this must therefore be broken. You should therefore generally not make the assumption that a train has a stop at the beginning or end of the <trainPart>.
According to the semantic constraint TT:014, no arrival time is specified in such a case, neither on the last <ocpTT> of the ending <trainPart> nor on the first <ocpTT> of the beginning <trainPart>. Make sure that the times do not contradict each other, i.e. ensure that also the semantic constraints TT:015 and TT:016 are taken into account.
Eine Software, die ein railML® Dokument liest, sollte auch mit <trainPart>'s umgehen können, deren erster und/oder letzter <ocpTT> als @ocpType den Wert pass angegeben hat. Diese Situation kann in unterschiedlichen Szenarien auftreten. Wenn beispielsweise einbrechende oder ausbrechende Verkehre in railML® beschrieben werden, kommt es häufig vor, dass der erste <ocp> keinen Halt darstellt, sondern vielmehr die Zeit kodiert zu der ein Zug in das Netz eintritt, oder dieses wieder verlässt. Ein anderer Grund kann sein, dass sich Daten am <trainPart> ändern, und dieser deswegen gebrochen werden muss. Man sollte also generell nicht die Annahme treffen, dass ein Zug am Anfang oder Ende es <trainPart> einen Halt hat.
Entsprechend des semantic constraints TT:014 wird in einem solchen Fall keine Ankunftszeit angegeben, weder am letzen <ocpTT> des endenden <trainPart> noch am ersten <ocpTT> des beginnenden <trainPart>. Es ist darauf zu achten, dass die Zeiten sich nicht widersprechen, die semantic constraints TT:015 und TT:016 sind also ebenso zu beachten.
Train(part)s with one <ocpTT> only
Normally, each <train> has at least one <trainPart> with at least two <ocpTT>s. However, it is allowed that a <trainPart> has only one <ocpTT>. In this special case, what is mentioned at TT:times concerning arrival at first and departure at last <ocpTT> applies at the same time: The train arrives from outside and immediately departs to outside the railML® file. In very rare cases, this is used, for instance, to express only an occupation of a station track by a train which is not considered further. You can imagine a whole railML® file which only expresses the station timetable of one station: All trains arrive from and depart to "nowhere". You should keep that special case in mind if you handle railML® files on import.
Specifying shunting times
As of version 2.5 the attribute @shuntingTime of the <ocpTT> was declared deprecated. In order to specify a shunting time at a stop please refer to the attribute @shuntingTime of <stopTimes>.
Notes / Anmerkungen
Not yet described. / Noch nicht beschrieben.
Open issues / Offene Punkte/Pendenzen
Not yet described. / Noch nicht beschrieben.