User:RailML Coord Documentation/Spielwiese

|- |CO:phase |TT:001 |approved |2018-11-12 |2019-03-21 | |Any starting time stamp (as it may result e.g. from a combination of startDate and startTime) shall be lower or equal any ending time stamp (e.g. endDate) if both are given. Must not overlap with other validity periods.|- |Ferri Leberl/IS:tunnel |IS:014 |proposed |2022-03-14 |– | |Define the tunnel resistance factor <tt>@resistanceFactorPassenger</tt> resp. <tt>@resistanceFactorFreight</tt> only if <tt>@kind</tt> and <tt>@crossSection</tt> are not known.|- |Ferri Leberl/TT:ocpTT |TT:002 |approved |2018-10-25 |2019-06-20 | |The attribute sequence is shall be increasing according to the train path.<br/> <span style="color:#0000FF">Das Attribut sequence muss ansteigend entsprechend dem Zuglauf sein.</span>|- |Ferri Leberl/TT:stopDescription |TT:006 |approved |2018-09-03 |2019-06-20 | |The following table summarises the semantical constraints between the attributes <tt><ocpTT></tt>.<tt><span id=ocpType>ocpType</span></tt>, <tt><stopDescription></tt>.<tt><span id=guaranteedPass>guaranteedPass</span></tt>, .<tt><span id=commercial>commercial</span></tt>, .<tt><span id=onOff>onOff</span></tt>, .<tt><span id=stopOnRequest>stopOnRequest</span></tt> and .<tt><span id=operationalStopOrdered>operationalStopOrdered</span></tt>:<br> <br>

• Green cells are default values.
• <tt><span id=ocpType>ocpType</span></tt>='begin','end' are deprecated from railML 2.2.
• If no <tt><stopDescription></tt> is given, it is either a non-guaranteed pass (1.2) or a stop with undefined properties, depending on the attribute <tt><span id=ocpType>ocpType</span></tt>.
• The term "commercial" of the attribute in railML traditionally refers to the contractual relationship between RU and end-customer, not to the contractual relationship between IM and RU.
• The term "ordered" in the attribute <tt><span id=operationalStopOrdered>operationalStopOrdered</span></tt> refers to the contractual relationship between IM and RU.|-

|IS:003 |IS:003 |proposed |2019-06-17 |– | |*The value of <tt>@pos</tt> in <tt><trackBegin></tt> is always the lowest value of all specified <tt><trackElements></tt> and <tt><ocsElements></tt>. It is always lower than the value of <tt>@pos</tt> of <tt><trackEnd></tt>.

• The value of <tt>@pos</tt> in <tt><trackEnd></tt> is always the highest value of all specified <tt><trackElements></tt> and <tt><ocsElements></tt>. It is always higher than the value of <tt>@pos</tt> of <tt><trackBegin></tt>.
• Subtracting the value of <tt>@pos</tt> in <tt><trackBegin></tt> from the value of <tt>@pos</tt> in <tt><trackEnd></tt> will result in the length of the enclosing <tt><track></tt>.
• If two <tt><track></tt>s are connected, the <tt>@absPos</tt> values of the connected <tt><trackBegin></tt> and <tt><trackEnd></tt> must be identical if
  • both are provided and
  • no <tt><mileageChange></tt> is defined at this point and
  • both <tt><track></tt>s belong to the same mileage system.|-

|IS:mileageChange |IS:006 |proposed |2019-06-19 |– | |*Define attributes <tt>@absPosIn</tt> and <tt>@absPos</tt> for "real" mileage changes

• Define attribute <tt>@absPosIn</tt> alone in case of an ending mileage
• Define attribute <tt>@absPos</tt> alone in case of a starting mileage
• For starting mileages and "real" mileage changes, the <tt>@absDir</tt> has to be given to define the ongoing orientation of the mileage|-

|IS:speedProfile |IS:012 |proposed |2022-03-14 |– | |<tt>@basicSpeedProfile</tt> is always linked with <tt>@influence</tt>=<tt><span id=increasing>increasing</span></tt>|- |IS:speedProfile |IS:013 |proposed |2022-03-14 |– | |<br>

• <tt>@influence</tt>=<tt><span id=increasing>increasing</span></tt>: The <tt><speedProfile></tt> increases the permitted speed. If multiple "increasing" speed profiles are applicable, select the one with the highest <tt>@vMax</tt> value.
• <tt>@influence</tt>=<tt><span id=decreasing>decreasing</span></tt>: The <tt><speedProfile></tt> decreases the permitted speed. If multiple "decreasing" speed profiles are applicable, select the one with the lowest <tt>@vMax</tt> value. If this value is lower than the speed of an "increasing" speed profile, it overrides that speed.|-

|IS:uptime |IS:008 |proposed |2020-02-28 |– | |An <tt><ocp></tt> with <tt><propOperational>@operationalType</tt>=blockSignal shall not have <tt>@mode</tt>=manned (as a manned blockSignal shall be modelled in railML^{<small>®</small>} 2.x as a blockPost).|- |IS:uptime |IS:009 |proposed |2020-02-28 |– | |An <tt><ocp></tt> with attribute <tt><propOperational>@operationalType</tt>=stoppingPoint shall not have <tt>@mode</tt>=manned (as a stoppingPoint has no operational usage and therefore no operational staff by the IM).|- |IS:uptime |IS:010 |proposed |2020-02-28 |– | |An enumeration of several time periods by <tt>@from</tt> and <tt>@until</tt> for one <tt><ocp></tt> shall not overlap so that for every time there shall be a unique status of <tt><uptime></tt>.|- |LangSemcon |{{{id}}} |proposed |2019-07-09 |– | |The language identifier shall be used in combination with attributes <tt>@name</tt> and <tt>@description</tt>.|- |RS:operator |TT:001 |approved |2018-11-12 |2019-03-21 | |Any starting time stamp (as it may result e.g. from a combination of startDate and startTime) shall be lower or equal any ending time stamp (e.g. endDate) if both are given. Must not overlap with other validity periods.|- |RS:owner |TT:001 |approved |2018-11-12 |2019-03-21 | |Any starting time stamp (as it may result e.g. from a combination of startDate and startTime) shall be lower or equal any ending time stamp (e.g. endDate) if both are given. Must not overlap with other validity periods.|- |SemconProposal |{{{id}}} |proposed |2018-12-10 |– | |Never put off until tomorrow what you can do today.|- |TT:ocpTT ocpsTT patternTrainPart |TT:002 |approved |2018-10-25 |2019-06-20 | |The attribute sequence is shall be increasing according to the train path.<br/> <font color="#0000FF">Das Attribut sequence muss ansteigend entsprechend dem Zuglauf sein.</font>|- |TT:operatingDay |TT:001 |approved |2018-11-12 |2019-03-21 | |Any starting time stamp (as it may result e.g. from a combination of startDate and startTime) shall be lower or equal any ending time stamp (e.g. endDate) if both are given. Must not overlap with other validity periods.|- |TT:operatingPeriod |TT:001 |approved |2018-11-12 |2019-03-21 | |Any starting time stamp (as it may result e.g. from a combination of startDate and startTime) shall be lower or equal any ending time stamp (e.g. endDate) if both are given. Must not overlap with other validity periods.|- |TT:specialService operatingPeriodRef |TT:001 |approved |2018-11-12 |2019-03-21 | |Any starting time stamp (as it may result e.g. from a combination of startDate and startTime) shall be lower or equal any ending time stamp (e.g. endDate) if both are given. Must not overlap with other validity periods.|- |TT:stopDescription ocpTT ocpsTT patternTrainPart |TT:006 |approved |2018-09-03 |2019-06-20 | |The following table summarises the semantical constraints between the attributes <tt><ocpTT></tt>.<tt><span id=ocpType>ocpType</span></tt>, <tt><stopDescription></tt>.<tt><span id=guaranteedPass>guaranteedPass</span></tt>, .<tt><span id=commercial>commercial</span></tt>, .<tt><span id=onOff>onOff</span></tt>, .<tt><span id=stopOnRequest>stopOnRequest</span></tt> and .<tt><span id=operationalStopOrdered>operationalStopOrdered</span></tt>:<br> <br>

• Green cells are default values.
• <tt><span id=ocpType>ocpType</span></tt>='begin','end' are deprecated from railML 2.2.
• If no <tt><stopDescription></tt> is given, it is either a non-guaranteed pass (1.2) or a stop with undefined properties, depending on the attribute <tt><span id=ocpType>ocpType</span></tt>.
• The term "commercial" of the attribute in railML traditionally refers to the contractual relationship between RU and end-customer, not to the contractual relationship between IM and RU.
• The term "ordered" in the attribute <tt><span id=operationalStopOrdered>operationalStopOrdered</span></tt> refers to the contractual relationship between IM and RU.|-

|TT:stopDescription ocpTT ocpsTT trainPart |TT:006 |approved |2018-09-03 |2019-06-20 | |The following table summarises the semantical constraints between the attributes <tt><ocpTT></tt>.<tt><span id=ocpType>ocpType</span></tt>, <tt><stopDescription></tt>.<tt><span id=guaranteedPass>guaranteedPass</span></tt>, .<tt><span id=commercial>commercial</span></tt>, .<tt><span id=onOff>onOff</span></tt>, .<tt><span id=stopOnRequest>stopOnRequest</span></tt> and .<tt><span id=operationalStopOrdered>operationalStopOrdered</span></tt>:<br> <br>

• Green cells are default values.
• <tt><span id=ocpType>ocpType</span></tt>='begin','end' are deprecated from railML 2.2.
• If no <tt><stopDescription></tt> is given, it is either a non-guaranteed pass (1.2) or a stop with undefined properties, depending on the attribute <tt><span id=ocpType>ocpType</span></tt>.
• The term "commercial" of the attribute in railML traditionally refers to the contractual relationship between RU and end-customer, not to the contractual relationship between IM and RU.
• The term "ordered" in the attribute <tt><span id=operationalStopOrdered>operationalStopOrdered</span></tt> refers to the contractual relationship between IM and RU.|-

|TT:times ocpTT ocpsTT trainPart |TT:010 |approved |2019-06-19 |2020-10-15 | |<tt>@scope</tt>&#61;'earliest' and 'latest' are not intended to encode supplement times, as this is redundant to <ocpTT>.<sectionTT>.<runTimes>@operationalReserve, @additionalReserve, @minimalTime. <br/> <font color="#0000FF"><tt>@scope</tt>&#61;'earliest' und 'latest' sind nicht zur Abbildung von Fahrzeitzuschlägen zu verwenden, da dies redundant zu <ocpTT>.<sectionTT>.<runTimes>@operationalReserve, @additionalReserve, @minimalTime ist.</font>|- |TT:times ocpTT ocpsTT trainPart |TT:012 |approved |2019-06-19 |2022-06-02 | |When <tt>@scope</tt>&#61;'actual' is used, then the operating period and/or timetable period specified at the trainpart level shall refer to only one operating day. Like this the operating day to which the actual times refer is defined. <br/> <font color="#0000FF">Wenn <tt>@scope</tt>&#61; 'actual' verwendet wird, bezieht sich die operating period und/oder timetable period des train(part) auf nur einen einzelnen Betriebstag. Es muss so festgelegt werden, auf welchen Betriebstag sich die erfassten Ist-Zeiten beziehen.</font>|- |TT:times ocpTT ocpsTT trainPart |TT:014 |approved |2019-06-19 |2022-06-02 | |<tt>@arrival</tt> is not to be specified if the attribute <tt><span id=ocpType>ocpType</span></tt> of the parent <tt><ocpTT></tt> has the value pass - use <tt><span id=departure>departure</span></tt> for run-through (passing) times; This is in line with the definition of <tt>@arrival</tt> as the moment at which the train ends its movement and gets to a halt at the parent <tt><ocpTT></tt>.|- |TT:times ocpTT ocpsTT trainPart |TT:015 |approved |2019-06-19 |2022-06-02 | |At the first <tt><ocpTT></tt> of a <tt><trainPart></tt> that is not the first one of the <tt><trainPartSequence></tt>, the attribute <tt>@arrival</tt> is optional. If it is set anyway, then, for consistency reasons, the value of <tt>@arrival</tt> of the regarding <tt><ocpTT></tt> must be identical for both this <tt><trainPart></tt> and the preceding one.|- |TT:times ocpTT ocpsTT trainPart |TT:016 |approved |2020-10-09 |2022-06-02 | |At the last <tt><ocpTT></tt> of a <tt><trainPart></tt> that is not the last one of the <tt><trainPartSequence></tt>, the attribute <tt>@departure</tt> is optional. If it is set anyway, then, for consistency reasons, the value of <tt>@departure</tt> of the regarding <tt><ocpTT></tt> must be identical for both this <tt><trainPart></tt> and the subsequent one.