Differences between railML2 and railML3: Difference between revisions
| [checked revision] | [checked revision] |
m (moved comparison of implementation of LTCP in railML2 and railML3 to the common "comparison" page) |
m (moved comparison of implementation of switch in railML2 and railML3 to the common "comparison" page) |
||
| Line 42: | Line 42: | ||
* Better structured model for non-train run tasks (maintenance, cleaning, …) | * Better structured model for non-train run tasks (maintenance, cleaning, …) | ||
* Option to provide a trackref for non-train run tasks | * Option to provide a trackref for non-train run tasks | ||
==Switch== | |||
In {{rml|2}}, the railway switch is positioned at the track. The railway switch “must” have both branches because of the cardinality constraint of XSD. In {{rml|3}}, the railway switch is positioned at the net element. According to the schema, the railway switch “can” have both branches because of the cardinality constraint of XSD. However, both are necessary semantically. | |||
In {{rml|2}}, the construction of the railway switch is specified using attributes: | |||
‒ {{@|orientation|IS:connection_switch|wiki2}}: incoming, outgoing | |||
‒ {{@|course|IS:connection_switch|wiki2}}: left, right. | |||
See {{rml|2}} interpretation of cases of Table 2 in {{wiki2|Dev:Connection_between_tracks|Connection_between_tracks}}. | |||
The {{rml|2}} railway switches {{@|orientation|IS:connection_switch|wiki2}} is related to {{@|applicationDirection|RTM:spotLocation}} {{rml|3}}. The orientation of a switch in {{rml|2}} was always dependent on the direction of the track. In {{rml|3}} the directions specified for {{@|continueCourse|IS:switchIS}} and {{@|branchCourse|IS:switchIS}} can always be interpreted the same way, looking from the base of the switch. | |||
=== Scope === | |||
A switch is a unit of a railway track network used to direct vehicles from one track to another track. This means that in {{rml|3}} the "class" of railway switches also includes a switch crossing. Simple crossings do not allow the train to get from one track to another and are represented by the {{IS:Tag|crossing}} element. | |||
In {{rml|2}}, both switchable crossing and simple crossing are represented by the {{wiki2|IS:crossing|<crossing>}} element. | |||
=== Topology === | |||
The code shows that track 3 includes net element b03. The railway switch is at the end of track 3 and the end of net element b03. | |||
In {{rml|2}} it is possible to insert railway switches in the middle of a track. In {{rml|3}} this can also be done for tracks. Assuming the tracks 3 and 4 are merged into one let this new track be called 3X. Then, the new track 3X includes net elements b03 and b01 and a railway switch in the middle of the track. The main restriction of the {{rml|3}} model however is, that a railway switch is always at the end or the beginning of a net element. It cannot be defined in the middle of it. | |||
This is because the railway switch refers to {{IS:Tag|netRelation}}, which are always on the edge of net elements. This is implied by the fact that the {{@|positionOnA|IS:netRelation}} and {{@|positionOnB|IS:netRelation}} attributes of the netRelation can only accept the values 0 and 1. Thus, even though the attribute {{@|intrinsicCoord|RTM:spotLocation}} of the child element {{RTM:Tag|spotLocation}} of the railway switch is of “double” data type, meaning that one can set intrinsic coordination to something like 0.75 (comp. {{topo|Linear Positioning / referencing}} in the {{rtm}} wiki) or position not equal to the length, the railway switch must still be on the edge of the net element (lines 110-113 of the listing). | |||
Revision as of 08:45, 15 April 2025
Introduction
LTCP
Implementing UC:TT:LongTermCirculationPlanning using railML® 2 has shortcomings given below.
Referring to vehicles
In railML® 2 there is no direct way to reference a certain vehicle of a trainPart.
Provided by railML.org partner iRFP (link to the railML® website)
Indication of midnight overruns
In railML® 2 it is difficult to define whether a block connection (<circulation> in railML® 2) includes none, one or more than one midnight overruns when validities with more than one operating day are used.
Provided by railML.org partner iRFP (link to the railML® website)
Circulation element connects two blocks. Each connection is attributes with validity (Monday to Friday).
Interpretation a) assumes that block1 and block2 can be carried out on the same day, e.g. block1 in the morning and block2 in the afternoon.
Interpretation b) can assume that block1 and block2 happen at the same time i.e. block1 and block2 cannot happen on the same day with the same vehicle. If block1 happend on Monday , this vehicle can perform block2 on the next day.
Workaround (of railML® 2): Using one block connection for each single day (one for Monday, one for Tuesday and so on):
<circulation blockRef="blk_1" operatingPeriodRef="opp_Mon-Fri" nextBlockRef="blk_2" nextOperatingPeriodRef="opp_Mon-Fri"/>
Further changes to the schema of railML® 2
Changes:
- Reduction in the number of aggregation layers from 2 (<circulation>, <block> in railML® 2) to 1 (<blockConnection> in railML® 3)
- Optional grouping of block connections with references to the same initial block element
- New attribute ‘transitionTime’ on the <blockConnection> element: allows definition of minimal realisation time
- Better structured model for non-train run tasks (maintenance, cleaning, …)
- Option to provide a trackref for non-train run tasks
Switch
In railML® 2, the railway switch is positioned at the track. The railway switch “must” have both branches because of the cardinality constraint of XSD. In railML® 3, the railway switch is positioned at the net element. According to the schema, the railway switch “can” have both branches because of the cardinality constraint of XSD. However, both are necessary semantically.
In railML® 2, the construction of the railway switch is specified using attributes:
‒ @orientation: incoming, outgoing
‒ @course: left, right.
See railML® 2 interpretation of cases of Table 2 in Connection_between_tracks.
The railML® 2 railway switches @orientation is related to @applicationDirection railML® 3. The orientation of a switch in railML® 2 was always dependent on the direction of the track. In railML® 3 the directions specified for @continueCourse and @branchCourse can always be interpreted the same way, looking from the base of the switch.
Scope
A switch is a unit of a railway track network used to direct vehicles from one track to another track. This means that in railML® 3 the "class" of railway switches also includes a switch crossing. Simple crossings do not allow the train to get from one track to another and are represented by the <crossing> element.
In railML® 2, both switchable crossing and simple crossing are represented by the <crossing> element.
Topology
The code shows that track 3 includes net element b03. The railway switch is at the end of track 3 and the end of net element b03.
In railML® 2 it is possible to insert railway switches in the middle of a track. In railML® 3 this can also be done for tracks. Assuming the tracks 3 and 4 are merged into one let this new track be called 3X. Then, the new track 3X includes net elements b03 and b01 and a railway switch in the middle of the track. The main restriction of the railML® 3 model however is, that a railway switch is always at the end or the beginning of a net element. It cannot be defined in the middle of it.
This is because the railway switch refers to <netRelation>, which are always on the edge of net elements. This is implied by the fact that the @positionOnA and @positionOnB attributes of the netRelation can only accept the values 0 and 1. Thus, even though the attribute @intrinsicCoord of the child element <spotLocation> of the railway switch is of “double” data type, meaning that one can set intrinsic coordination to something like 0.75 (comp. Linear Positioning / referencing in the RailTopoModel® wiki) or position not equal to the length, the railway switch must still be on the edge of the net element (lines 110-113 of the listing).