Dev:Railway station ownership: Difference between revisions
[checked revision] | [checked revision] |
m (formatting) |
m (fixed reference) |
||
(6 intermediate revisions by one other user not shown) | |||
Line 5: | Line 5: | ||
A real-world example of this concept can be found in the OpenRailwayPap defined for the Děčín–Dresden-Neustadt railway 6240 line. This line is operated by two railway operation managers Správa železnic of the Czech Republic and Deutsche Bahn Netz of Germany. Schöna is a German railway station and Dolní Žleb is a Czech one. This example is based on Schöna. | A real-world example of this concept can be found in the OpenRailwayPap defined for the Děčín–Dresden-Neustadt railway 6240 line. This line is operated by two railway operation managers Správa železnic of the Czech Republic and Deutsche Bahn Netz of Germany. Schöna is a German railway station and Dolní Žleb is a Czech one. This example is based on Schöna. | ||
In | In {{rml}}, countries are present in the infrastructure manages code list. The fact “railway station X is located in country Y” should be decomposed into the following ones: | ||
• railway station X has track Z | • railway station X has track Z | ||
Line 13: | Line 13: | ||
• infrastructure manager J is of country Y. | • infrastructure manager J is of country Y. | ||
The last fact is already present in the code list of | The last fact is already present in the code list of {{rml}}. The user should define the first two ones. | ||
The “railway station X has track Z” fact is represented by <propEquipment> child of an ocp. | The “railway station X has track Z” fact is represented by <propEquipment> child of an ocp. | ||
In | In {{rml}}, “track Z is managed by infrastructure manager J” fact is represented by the <ownerChange> element of infrastructure subschema referring to <infrastructureManager> ones of metadata. | ||
They affect the definition of the railway tracks. Every railway track should have an <ownerChange> at the beginning of the track positioned at zero coordinate. But also, the additional semantic constraints apply like for the <speedChange> | They affect the definition of the railway tracks. Every railway track should have an <ownerChange> at the beginning of the track positioned at zero coordinate. But also, the additional semantic constraints apply like for the <speedChange>:<ref name=rml>{{site|1=https://www.railml.org/forum/index.php?t=msg&th=905&start=0&|2=railML2 <speedChange> semantic constraints revision}}</ref> | ||
• Only applies if speedChanges (ownerChange) are exported at all [as they are not required by XSD (editor's comment)]. | • Only applies if speedChanges (ownerChange) are exported at all [as they are not required by XSD (editor's comment)]. | ||
• If both directions are accessible, then <ownerChange> should also be defined for the <trackEnd> | • If both directions are accessible, then <ownerChange> should also be defined for the <trackEnd> | ||
== References == | |||
<references> | |||
<!--<ref name=tap>TAP TSI and TAF TSI Sector Handbook for the Communication between Railway Undertakings and Infrastructure Managers (RU/IM Telematics Sector Handbook) Submitted on 20th October 2022</ref>--> | |||
</references> |
Latest revision as of 14:28, 20 February 2024
In this example, railML.org will consider a way to represent the fact “railway station X is located in country Y”
A real-world example of this concept can be found in the OpenRailwayPap defined for the Děčín–Dresden-Neustadt railway 6240 line. This line is operated by two railway operation managers Správa železnic of the Czech Republic and Deutsche Bahn Netz of Germany. Schöna is a German railway station and Dolní Žleb is a Czech one. This example is based on Schöna.
In railML®, countries are present in the infrastructure manages code list. The fact “railway station X is located in country Y” should be decomposed into the following ones:
• railway station X has track Z
• track Z is managed by infrastructure manager J
• infrastructure manager J is of country Y.
The last fact is already present in the code list of railML®. The user should define the first two ones.
The “railway station X has track Z” fact is represented by <propEquipment> child of an ocp.
In railML®, “track Z is managed by infrastructure manager J” fact is represented by the <ownerChange> element of infrastructure subschema referring to <infrastructureManager> ones of metadata.
They affect the definition of the railway tracks. Every railway track should have an <ownerChange> at the beginning of the track positioned at zero coordinate. But also, the additional semantic constraints apply like for the <speedChange>:[1]
• Only applies if speedChanges (ownerChange) are exported at all [as they are not required by XSD (editor's comment)].
• If both directions are accessible, then <ownerChange> should also be defined for the <trackEnd>
References
- ↑ railML2 <speedChange> semantic constraints revision (link to the railML® website)