Dev:Railway station ownership: Difference between revisions
| [checked revision] | [checked revision] |
(added text) |
m (formatting) |
||
| Line 2: | Line 2: | ||
In this example, railML.org will consider a way to represent the fact “railway station X is located in country Y” | 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. | 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: | 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 | • railway station X has track Z | ||
• track Z is managed by infrastructure manager J | • track Z is managed by infrastructure manager J | ||
• 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 railML. The user should define the first two ones. | |||
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. | The “railway station X has track Z” fact is represented by <propEquipment> child of an ocp. | ||
In railML the “track Z is managed by infrastructure manager J” fact is represented by the <ownerChange> element of infrastructure subschema referring to <infrastructureManager> ones of metadata. | In railML the “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> [2]: | 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> [2]: | ||
• 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> | ||
[1] 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 | [1] 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 | ||
[2] https://www.railml.org/forum/index.php?t=msg&th=905&start=0& | [2] https://www.railml.org/forum/index.php?t=msg&th=905&start=0& | ||
Revision as of 14:50, 26 September 2023
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 the “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> [2]:
• 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>
[1] 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
[2] https://www.railml.org/forum/index.php?t=msg&th=905&start=0&