Template:Table/Dev:Semantic Constraints: Difference between revisions

From railML 3 Wiki
Jump to navigation Jump to search
[unchecked revision][unchecked revision]
(paraphrased IS:010, deprecated IS:004)
(noted accept of IS001-003 by ETCS working group)
Line 60: Line 60:
|IS:001
|IS:001
|2024-01-15
|2024-01-15
|2024-02-26 ETCS WG
|
|
|
|Starting time stamp (e.g. "from") shall be lower or equal any ending time stamp (e.g. "to") if both are given. Must not overlap with other validity periods.
|
Starting time stamp (e.g. "from") shall be lower or equal any ending time stamp (e.g. "to") if both are given. Must not overlap with other validity periods.
|-
|-
|{{IS:Tag|trainProtectionElement|ex=1|wiki=3}}
|{{IS:Tag|trainProtectionElement|ex=1|wiki=3}}
|IS:002
|IS:002
|2021-02-26
|2021-02-26
|2024-02-26 ETCS WG
|
|
|
|{{IS:Tag|trainProtectionElement}} shall only be used for national and/or legacy train protection systems. ETCS-based systems must not be modeled using {{IS:Tag|trainProtectionElement}}.
|
{{IS:Tag|trainProtectionElement}} shall only be used for national and/or legacy train protection systems. ETCS-based systems must not be modeled using {{IS:Tag|trainProtectionElement}}.
|-
|-
|{{IS:Tag|levelCrossingIS|ex=1|wiki=3}}
|{{IS:Tag|levelCrossingIS|ex=1|wiki=3}}
|IS:003
|IS:003
|2023-10-23
|2023-10-23
|2024-02-26 ETCS WG
|
|
|
|{{IS:Tag|levelCrossingIS}} should not have a {{IS:Tag|crossesElement}} child of type railway. This case should be represented either by a {{IS:Tag|crossing}} in case of a simple crossing, or by a {{IS:Tag|switchIS}} of type doubleSwitchCrossing or singleSwitchCrossing.
|
{{IS:Tag|levelCrossingIS}} should not have a {{IS:Tag|crossesElement}} child of type railway. This case should be represented either by a {{IS:Tag|crossing}} in case of a simple crossing, or by a {{IS:Tag|switchIS}} of type doubleSwitchCrossing or singleSwitchCrossing.
|-
|-
|{{IS:Tag|underCrossing|ex=1|wiki=3}}, {{IS:Tag|overCrossing|ex=1|wiki=3}}
|{{IS:Tag|underCrossing|ex=1|wiki=3}}, {{IS:Tag|overCrossing|ex=1|wiki=3}}

Revision as of 14:58, 26 February 2024

Return to article

Element ID Proposal date Date of acception Date of deprecation Description
<TT:operationalTrainSectionPart> TT:001 2022-09-15 2022-10-13 There is always only a single successor and predecessor for an <operationalTrainSectionPart> in the chain of <operationalTrainSectionPart>s that are linked via the attribute @next.
<TT:operationalTrainVariant> TT:002 2023-01-12 2023-04-06 When calculating which <operationalTrainVariant> of an <operationalTrain> is valid on a particular day always a maximum of one active <operationalTrainVariant> shall be the result. If the result is more than one <operationalTrainVariant>, all except one shall be marked as <isCancelled> or <isOnRequest>.
<TT:commercialTrainVariant> TT:003 2023-01-12 2023-04-06 When calculating which <commercialTrainVariant> of an <commercialTrain> is valid on a particular day always a maximum of one active <commercialTrainVariant> shall be the result. If the result is more than one <commercialTrainVariant>, all except one shall be marked as <isCancelled> or <isOnRequest>.
<TT:operationalTrainSection> TT:004 2022-01-12 2023-03-09 The itinerary sections of an <operationalTrainVariant>, defined by the <operationalTrainSection>s and their respective <range>s, that are not <isCancelled> and not marked as <isOnRequest>, must be pairwise disjoint, except for their respective first and last <baseItineraryPoint>s.
<TT:operationalTrainSection> TT:005 2022-01-12 2023-03-09 The first(last) <baseItineraryPoint> of each <operationalTrainSection> within an <operationalTrainVariant> must either be the referenced <itinerary>'s first(last) <baseItineraryPoint>, or coincide with another section's last(first) <baseItineraryPoint>.
<TT:commercialTrainSection> TT:006 2022-01-12 2023-03-09 The itinerary sections of an <commercialTrainVariant>, defined by the <commercialTrainSection>s and their respective <range>s, that are not <isCancelled> and not marked as <isOnRequest>, must be pairwise disjoint, except for their respective first and last <baseItineraryPoint>s.
<TT:commercialTrainSection> TT:007 2022-01-12 2023-03-09 The first(last) <baseItineraryPoint> of each <commercialTrainSection> within an <commercialTrainVariant> must either be the referenced <itinerary>'s first(last) <baseItineraryPoint>, or coincide with another section's last(first) <baseItineraryPoint>.
<RTM:isValid>, <CO:validityTime:period> IS:001 2024-01-15 2024-02-26 ETCS WG Starting time stamp (e.g. "from") shall be lower or equal any ending time stamp (e.g. "to") if both are given. Must not overlap with other validity periods.
<IS:trainProtectionElement> IS:002 2021-02-26 2024-02-26 ETCS WG <trainProtectionElement> shall only be used for national and/or legacy train protection systems. ETCS-based systems must not be modeled using <trainProtectionElement>.
<IS:levelCrossingIS> IS:003 2023-10-23 2024-02-26 ETCS WG <levelCrossingIS> should not have a <crossesElement> child of type railway. This case should be represented either by a <crossing> in case of a simple crossing, or by a <switchIS> of type doubleSwitchCrossing or singleSwitchCrossing.
<IS:underCrossing>, <IS:overCrossing> IS:004 2023-10-23 was declined 2024-02-26 should only have a <crossesElement> child of type railway when railway crosses railway (not on the same level!).
<IS:signalConstruction> IS:005 2024-01-22

@height and @positionAtTrack should not be used with @type=virtual.

<IS:line> IS:006 2024-01-29

each line with own mileage should always be associated with its own <linearPositioningSystem>, i.e. Advanced example of railML has three lines with their own mileages, thus should have thee <linearPositioningSystem>s.

<IS:border> IS:007 2024-01-29

if @isOpenEnd="true" then statement @type="area" is true.

<IS:netElement> IS:008 2024-02-02

Aggregation of net elements should follow the tree data structure. See figure below. This means that no two (mesoscopic) net elements can aggregate same (microscopic) net element. In other words, (microscopic) net element can be aggregated by at most one (mesoscopic) net element.

<IS:netElement> IS:009 2024-02-02

Linear (geometric) coordinates (explicit or implicit, e.g. calculated as a sum of the coordinate of beginning and the length of the net element) of the same place represented at different levels of aggregation should have the same value. In the figure below (linear) coordinate the coordinate of e.g. end of ne1 should be same as one of ne1.2.

<IS:netElement> IS:010 2024-02-26

Difference of linear coordinates if the beginning and end of <netElement>, represented by <intrinsicCoordinate> / @intrinsicCoord = 0 and 1 correspondingly, should equal the the @length of <netElement> if all are present in the data. For each case when a difference of linear coordinates if the beginning and end of <netElement>, represented by <intrinsicCoordinate> / @intrinsicCoord = 0 and 1 correspondingly, does not equal the the @length of <netElement> if all are present in the data, a <mileageChange> of <anchor> should be present explaining anomaly