View source for Differences between railML2 and railML3

==Introduction==

==LTCP==
Implementing [[UC:TT:LongTermCirculationPlanning]] using {{rml|2}} has shortcomings given below.
=== Referring to vehicles ===

In {{rml|2}} there is no direct way to reference a certain vehicle of a trainPart.

<gallery widths=700px heights=300px>
File:2024-11-06 iRFP referencingVehicles.svg|thumb|1000px|Provided by {{org}} partner {{site|1=https://www.railml.org/en/partners/irfp|2=iRFP}}
</gallery>

=== Indication of midnight overruns ===

In {{rml|2}} it is difficult to define whether a block connection ({{wiki2|TT:circulation|<circulation>}} in {{rml|2}}) includes none, one or more than one midnight overruns when validities with more than one operating day are used.

<gallery widths=700px heights=300px>
File:2024-11-06 iRFP midnightOverruns2.svg|thumb|1000px|Provided by {{org}} partner {{site|1=https://www.railml.org/en/partners/irfp|2=iRFP}}
</gallery>

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 {{rml|2}}): Using one block connection for each single day (one for Monday, one for Tuesday and so on):

<syntaxhighlight lang=xml>
<circulation 
	blockRef="blk_1" 
	operatingPeriodRef="opp_Mon-Fri" 
	nextBlockRef="blk_2" 
	nextOperatingPeriodRef="opp_Mon-Fri"/>
</syntaxhighlight>

=== Further changes to the schema of {{rml|2|R=no}} ===
Changes:
* Reduction in the number of aggregation layers from 2 (<circulation>, <block> in {{rml|2}}) to 1 (<blockConnection> in {{rml|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 {{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).

==Double switch and single switch crossing==

===As single element ===

According to <ref name=2connection /> in {{wiki2}}, there are three ways to describe a crossing: with 4, 3 or 2 tracks. In {{rml|3}} it is also possible to merge let's say the {{IS:Tag|netElement}} ne30 and ne3 into one {{IS:Tag|track}}. Yet the {{IS:Tag|topology}} layer remains the same. This is done by referencing both {{IS:Tag|netElement}} when defining the {{RTM:Tag|linearLocation}} of the {{IS:Tag|track}}.

According to <ref name=2connection /> in {{wiki2}}, the navigability of branches is described implicitly ({{@|passable|IS:connection_crossing|wiki2}}=” true” is not defined) with the combination of “incoming” and “outgoing” attributes. In {{rml|3}} navigability is defined explicitly by additional {{IS:Tag|netRelation}}.

==== Scope ====

In {{rml|2}} {{wiki2|IS:srossing|<crossing>}} is used to describe double, single switch crossings as well as simple crossings. 
In {{rml|3}} {{IS:Tag|switchIS}} is used to describe double, single switch crossings. {{IS:Tag|crossing}} element is only used for simple crossings. 

===As combination of crossing and switches ===

According to <ref name=2connection /> in {{wiki2}}, there are three ways to describe a crossing: with 4, 3 or 2 tracks. In {{rml|3}} it is also possible to merge let's say ne21 and ne94 into one track. Yet the topology layer remains the same.

Furthermore, in {{rml|2}} the crossing would belong to track 30 or there would be two crossings defined for track 30 and 27. In this example, the crossing is located at track 33. But it is also possible to locate the crossing at tracks 30 and 27 in {{rml|3}}.

According to <ref name=2connection /> in {{wiki2}}, the navigability of straight branches is described implicitly with the combination of “incoming” and “outgoing” attributes. In {{rml|3}} navigability is defined explicitly by a corresponding attribute.

==== Scope ====


In {{rml|2}} {{tag|is|crossing|wiki=2}} is used to describe double, single switch crossings as well as simple crossings. 

In {{rml|3}} {{tag|is|switchIS}} is used to describe double, single switch crossings. {{tag|is|crossing}} is only used for simple crossings.

==Simple crossing==

According to {{wiki2|Dev:Connection_between_tracks|Connection_between_tracks}} in {{rml|2}}, there are three ways to describe a crossing: with 4, 3 or 2 tracks. In {{rml|3}} it is also possible to merge let's say ne30 and ne94 into one track. Yet the topology layer remains the same.

According to {{wiki2|Dev:Connection_between_tracks|Connection_between_tracks}} in {{rml|2}}, the navigability of straight branches is described implicitly with the combination of “incoming” and “outgoing” attributes, i.e. @passable=“true” is not defined. In {{rml|3}} navigability is defined explicitly by a corresponding attribute.

=== Scope ===

In {{rml|2}} {{wiki2|IS:crossing|<crossing>}} is used to describe double, single switch crossings as well as simple crossings. 

In {{rml|3}} {{IS:Tag|switchIS}}  is used to describe double, single switch crossings. {{IS:Tag|crossing}} is only used for simple crossings.

==Track==

In contrast to railML 2, the <track> in railML 3 does not cover the navigation perspective, since this is completely defined in topology domain using <netElement> and <netRelation> elements <ref>https://www.railml.org/forum/index.php?t=msg&th=745&goto=2502&#msg_2502</ref>.

The definition of a track has been generalised: it is no longer only defined as a railway section between two switches / crossings / bufferStop. In the issue <ref>https://development.railml.org/railml/version3/-/issues/368</ref> <track> was defined as "a railway section that can be traversed by a train in a continuous motion", which allows for very short tracks as well as for very long tracks (that may pass several switches...).

In railML 2.x we have a concept of track definition direction (trackbegin to trackEnd) and attributes like track/mainDir that describes the preferred driving direction on that track. Possible values are "up", "down", "unknown" and "none" and they always refer to the track definition direction <ref>https://www.railml.org/forum/index.php?t=msg&goto=1721&&srch=trackbegin#msg_1721</ref>.

== References ==
<references>
<ref name=2connection>Article {{wiki2|Dev:Connection_between_tracks#Double_Switch_Crossing}} in the {{rml|2 Wiki}}</ref>
</references>