Differences between railML2 and railML3

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).

Double switch and single switch crossing

As single element

According to in The railML^® 2 Wiki, there are three ways to describe a crossing: with 4, 3 or 2 tracks. In railML3 it is also possible to merge let's say the <netElement> ne30 and ne3 into one <track>. Yet the <topology> layer remains the same. This is done by referencing both <netElement> when defining the <linearLocation> of the <track>.

According to in The railML^® 2 Wiki, the navigability of branches is described implicitly (@passable=” true” is not defined) with the combination of “incoming” and “outgoing” attributes. In railML^® 3 navigability is defined explicitly by additional <netRelation>.

Scope

In railML^® 2 <crossing> is used to describe double, single switch crossings as well as simple crossings. In railML^® 3 <switchIS> is used to describe double, single switch crossings. <crossing> element is only used for simple crossings.

As combination of crossing and switches

According to in The railML^® 2 Wiki, there are three ways to describe a crossing: with 4, 3 or 2 tracks. In railML3 it is also possible to merge let's say ne21 and ne94 into one track. Yet the topology layer remains the same.

Furthermore, in railML^® 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 railML^® 3.

According to in The railML^® 2 Wiki, the navigability of straight branches is described implicitly with the combination of “incoming” and “outgoing” attributes. In railML3 navigability is defined explicitly by a corresponding attribute.

Scope

In railML^® 2 <crossing> is used to describe double, single switch crossings as well as simple crossings.

In railML^® 3 <switchIS> is used to describe double, single switch crossings. <crossing> is only used for simple crossings.

Simple crossing

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

According to Connection_between_tracks in railML^® 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 railML^® 3 navigability is defined explicitly by a corresponding attribute.

Scope

In railML^® 2 <crossing> is used to describe double, single switch crossings as well as simple crossings.

In railML^® 3 <switchIS> is used to describe double, single switch crossings. <crossing> is only used for simple crossings.