Talk:IS:mileageChange

Remarks and open issues on mileage changes

There has been a constant discussion on whether there changes of mileage directions should be allowed in railML or not.

The current railML schemes allow only two kinds of inconsistences of absolute mileage: A „missing“ and an „overlapping“ section of absolute mileage, both without change of mileage direction. This comes from the German Fehlerstelle (=missing section) and Überlänge (=overlapping section). According to this philosophy, each railway line has a theoretical absolute mileage (kilometrage) which is homogenous except the two kinds of inconsistences.

Apart from other countries which may have different philosophies, even in Germany this concept is controversial:

• There are typical head-on junctions at the open line outside any station where two mileages (of different origin) come together - for historical reasons, in most cases. For instance the line from Dresden to Berlin changes kilometrage near the old border between Saxon and Prussian Railways (50.4 km from Dresden, 124.6 km from Berlin). ‘Purists’ will have the opinion that these are two lines meeting there. But even this is controversial since there is no station, no switch, no signal at the place of mileage change and it is not shown in public nor operational timetables. So the question is whether railML should enforce that this must be represented as two lines.

In Britain, the mileage change at the East Coast Main Line north of Berwick-upon-Tweed (54m50ch from Edinburgh Waverley = 69m67ch from Newcastle) is a similar case.

• There are many junctions (junction stations) where two lines diverge. For the sake of timetables, the two lines diverge at the middle of the station. Timetables run from station to station whereas ‘station’ means middle or nominal mileage of the station. Between the nominal mileage of a junction and the actual place of divergence of the lines there are two parallel mileages in theory but only one mileage in practice - that of the main line. In operational timetables - even in German ones - the break of mileage is shown at the actual place of divergence - not at the nominal mileage of the junction where the timetable starts.

While the first problem could theoretically be solved by splitting one line into two lines using a ‘head-on junction’, the second problem cannot be solved with the current railML model:

• Either railML contains the theoretical absolute mileage. Therefore it does not contain what is written in timetables with the consequence, that a timetable could not be fully described with railML - which would fail the aim of railML.
• Or railML contains the mileage as shown in practice and in timetables but then would need a chance to describe a break of mileage, too.

So far, this problem is unsatisfactorily unsolved in railML.

In further discussions, the problem has been generalised to:
In a future railML version, there may be three (or more) mileages per track:

1. The relative mileage as in railML 2.x with no discontinuities and totally theoretical.
2. The theoretical absolute mileage as in railML 2.x with the two discontinuities named above for matters of “permanent way engineering”. This may be used in plans and for engineering purposes but has less significance for operating purposes.
3. The practical absolute mileage as shown in practice (at mileage boards) and in operational timetables. This is the new one and the only one which can contain breaks of mileage including direction changes. The aim is for operational stuff to orientate at mileage boards without plans.
4. There may even be a fourth mileage to overcome the problem of the difference of the exact mileage of a track and the nominal mileage of a line: For a double-track line, both tracks share one nominal mileage but in curves, the outer track should be longer than the inner one which leads to a mileage difference. (Possibly this fourth aspect may rather be solved with optional position offsets at each element.)

It has also be agreed, that in a future railML the absolute mileage(s) shall be represented in one structure (element with sub-elements). The current railML (2.x) spreads the information over several elements: While the first (initial) mileage of a track is set in <trackBegin>, further mileages are set in <mileageChanges>. This shall be harmonised in one element with sub-elements.
--Dirk Bräuer (Diskussion) 17:14, 14. Aug. 2015 (CEST)

Example of controversal case: Change of mileage direction / Kilometrierungsrichtungswechsel

The mileage of the following track first falls from km 2.036 down to km 0.000 and from there on raises from km 14.436 up to km 24.670.

Die Kilometrierung des folgenden Gleises fällt zunächst von km 2,036 auf km 0,000 und beginnt ab dort, von km 14,436 auf km 24,670 zu steigen.

      <track id='…'>
        <trackTopology>
          <trackBegin id='…' pos='11478' absPos='2036'/>
          <trackEnd id='…' pos='25748' absPos='24670'/>
          <mileageChanges>
            <mileageChange id='…' pos='13514' absPosIn='0' absPos='14436' absDir='raising'/>
          </mileageChanges>
        </trackTopology>
      </track>

Notes on this example:

• With the current railML schema, one can only deduce from comparing <trackBegin>.absPos and <mileageChange>.absPosIn that the initial mileage direction is falling. It is intended to ease this (among others) from railML 3.0.
  
• Many users would probably say that in case of a mileage direction change (like this example) the track has to be split into two tracks. Each of the two tracks would have no mileage change. Both would be linked (by a <line>) at the place of the former mileage direction change. This is the case in many data models. It may also be the reason why there is no <mileageChange>.type enumeration value for this case. However, so far it is not 'forbidden' to have mileage direction changes in railML. It is to be clarified in future whether these cases have to be split or whether there will be a <mileageChange>.type for them.

Hinweise zu diesem Beispiel:

• Mit den derzeitigen railML-Schemen ist nur durch Auswerten von <trackBegin>.absPos und <mileageChange>.absPosIn möglich, herauszufinden, das die initiale Kilometrierung fällt. Dies soll (u. a.) ab railML 3.0 geändert werden.
  
• Viele Anwender würden vermutlich sagen, dass in einem solchen Falle eines (vermeintlichen) Kilometrierungsrichtungswechsels das Gleis in zwei Gleise aufzuteilen sei. Jedes der sich so ergebenden Gleise hätte keinen <mileageChange>. Beide würden an der stelle des vermeintlichen Kilometrierungsrichtungswechsels zusammengefügt werden (in railML etwa durch ein <line>-Element). So würde dieser Fall in vielen Datenmodellen behandelt; das mag auch der Grund dafür sein, warum es bisher keinen <mileageChange>.type-Aufzählungswert für diesen Fall gibt. Bisher ist es aber auch nicht ausdrücklich "verboten", Kilometrierungsrichtungswechsels in railML zu definieren. Die weitere Schemenentwicklung muss zeigen, ob solche Fälle ausdrücklich aufzuteilen sind oder ob sie durch einen <mileageChange>.type legalisiert werden.

--Dirk Bräuer (Diskussion) 11:51, 15. Dez. 2014 (CET)

Remarks from IS coordinator:

• The described example has been discussed and evaluated thoroughly. In the end, it has been agreed, that the situation is based on two lines being connected to each other. Therefore, the current mileageChange implementation is sufficient for the described problem as the mileage direction is not changing.
• In particular, at the East Coast Main Line north of Berwick-upon-Tweed the responsible infrastructure manager Network Rail refers to "national lines": "So for instance Berwick upon-tweed to the border is on ECM7 (the 7th section of the East Coast Mainline) and the border to Edinburgh is on the ECM8." (Network Rail, 18.09.2015)

Anmerkung vom IS Schemen-Koordinator

• Das beschriebene Beispiel wurde ausführlich diskutiert und gründlich bewertet. Im Ergebnis ist man überein gekommen, dass die Situation auf zwei Strecken beruht, die miteinander verbunden sind. Daher wird die gegenwärtige Implementierung der mileageChange-Elemente für ausreichend erachtet, da sich die Kilometrierungsrichtung entlang einer Strecke nicht ändert.
• Im speziellen Fall der East Coast Main Line nördlich von Berwick-upon-Tweed argumentiert der verantwortliche Infrastruktur-Manager, Network Rail, über sog. "nationale Strecken"}: "So for instance Berwick upon-tweed to the border is on ECM7 (the 7th section of the East Coast Mainline) and the border to Edinburgh is on the ECM8." (Network Rail, 18.09.2015)

--Christian.rahmig 13:33, 6. Nov. 2015 (CET)