Dev:How To Reference Infrastructure

This article explains basic concepts of how to describe infrastructure and how to reference it from the timetable subschema

Dieser Artikel erklärt die Grundkonzepte für das Beschreiben von Infrastruktur und wie man auf diese auf dem Fahrplan-Subschema verweisen kann.

How to describe infrastructure / Beschreibung von Infrastruktur

In general we distinguish between the macroscopic and the microscopic approach of describing infrastructure. These are two ways of looking at the same set of tracks and stations a railway is made of.

Microscopic Infrastructure

The microscopic approach is focussed on providing a very detailed description. In a microscopic infrastructure description in railML^®, tracks usually are limited by switches, crossings, bufferstops and such. In railML^® that would mean that usually a <track>s <trackTopology> defines its <trackBegin> and <trackEnd> as either <connection> (<connection>), <bufferStop> or <openEnd>. Stations and stops aka <ocp> are positioned on a <track> via <crossSection>s.

Below is a minimalistic example of a microscopic infrastructure:

  <infrastructure id="is01">
    <tracks>
      <track id="tr01">
        <trackTopology>
          <trackBegin id="tb01" pos="0">
            <openEnd id="oe01"/>
          </trackBegin>
          <trackEnd id="te01" pos="1000">
            <connection id="tecx01" ref="tbcx02"/>
          </trackEnd>
          <connections>
            <switch id="sw01" pos="1000">
              <connection id="swcx01" ref="tbcx03" orientation="outgoing" course="left"/>
            </switch>
          </connections>
        </trackTopology>
      </track>
      <track id="tr02">
        <trackTopology>
          <trackBegin id="tb02" pos="0">
            <connection id="tbcx02" ref="tecx01"/>
          </trackBegin>
          <trackEnd id="te02" pos="500">
            <connection id="tecx02" ref="tbcx04"/>
          </trackEnd>
          <crossSections>
            <crossSection id="cxs02" pos="250" ocpRef="ocp01"/>
          </crossSections>
        </trackTopology>
      </track>
      <track id="tr03">
        <trackTopology>
          <trackBegin id="tb03" pos="0">
            <connection id="tbcx03" ref="swcx01"/>
          </trackBegin>
          <trackEnd id="te03" pos="500">
            <connection id="tecx03" ref="swcx04"/>
          </trackEnd>
          <crossSections>
            <crossSection id="cxs03" pos="250" ocpRef="ocp01"/>
          </crossSections>
        </trackTopology>
      </track>
      <track id="tr04">
        <trackTopology>
          <trackBegin id="tb04" pos="0">
            <connection id="tbcx04" ref="tecx02"/>
          </trackBegin>
          <trackEnd id="te04" pos="1000">
            <openEnd id="oe04"/>
          </trackEnd>
          <connections>
            <switch id="sw04" pos="0">
              <connection id="swcx04" ref="tecx03" orientation="outgoing" course="left"/>
            </switch>
          </connections>
        </trackTopology>
      </track>
    </tracks>
    <operationControlPoints>
      <ocp id="ocp01">
        ...
        <propEquipment>
           <trackRef ref="tr02"/>
           <trackRef ref="tr03"/>
        </propEquipment>
        ...
      </ocp>
    </operationControlPoints>
  </infrastructure>

The above infrastructure describes an <ocp> that has two <track>s ("tr02" and "tr03"). Below is a rough sketch of the described infrastructure.

The provided example is focused only on the track topology. Of course a real world example of a microscopic infrastructure would include a lot more details, however it demonstrates how the tracks are described in a way that is closely related to how the tracks are laid in reality. Please note that there is no need to cut the tracks like done in the example above. It would also be a correct modelling in railML^® to define the same infrastructure with only two <track>s, one spanning from open end to open end and containing two switches and one that connects to those two switches via its <trackBegin> and <trackEnd>. For more information on how to connect tracks with switches and crossings, please also refer to this page.

Macroscopic Infrastructure

In a macroscopic view, on the other hand, <track>s usually span between <ocp>s. That does not mean that in a macroscopic view a <track> can only connect two {IS:Tag|ocp}}s but usually <track>s are limited by {IS:Tag|ocp}}s. One <track> in a macroscopic description does not necessarily represent a single track in reality, it may also represent a number of physical tracks as well as switches between them. When descibing this in railML^®, it means that a <track>s <trackTopology> specifies <trackBegin> and <trackEnd> as mostly <macroscopicNode>. However, <crossSections> are also used in the macroscopic approach.

Below is an example of an infrastructure that follows the macroscopic approach:

  <infrastructure id="is01">
    <tracks>
      <track id="tr01">
        <trackTopology>
          <trackBegin id="tb01" pos="0">
            <macroscopicNode ocpRef="ocp01"/>
          </trackBegin>
          <trackEnd id="te01" pos="10000">
            <macroscopicNode ocpRef="ocp03"/>
          </trackEnd>
          <crossSections>
            <crossSection id="cxs01" pos="5000" ocpRef="ocp02"/>
          </crossSections>
        </trackTopology>
      </track>
      <track id="tr02">
        <trackTopology>
          <trackBegin id="tb02" pos="0">
            <macroscopicNode ocpRef="ocp03"/>
          </trackBegin>
          <trackEnd id="te02" pos="10000">
            <macroscopicNode ocpRef="ocp05"/>
          </trackEnd>
          <crossSections>
            <crossSection id="cxs02" pos="5000" ocpRef="ocp04"/>
          </crossSections>
        </trackTopology>
      </track>
      <track id="tr03">
        <trackTopology>
          <trackBegin id="tb03" pos="0">
           <macroscopicNode ocpRef="ocp01"/>
          </trackBegin>
          <trackEnd id="te03" pos="8000">
            <macroscopicNode ocpRef="ocp04"/>
          </trackEnd>
        </trackTopology>
      </track>
      <track id="ocp02tr01">
        <trackTopology>
          <trackBegin id="tbocp02tr01" pos="0">
            <macroscopicNode ocpRef="ocp02"/>
          </trackBegin>
          <trackEnd id="teocp02tr01" pos="450">
            <macroscopicNode ocpRef="ocp02"/>
          </trackEnd>
        </trackTopology>
      </track>
      <track id="ocp02tr02">
        <trackTopology>
          <trackBegin id="tbocp02tr02" pos="0">
            <macroscopicNode ocpRef="ocp02"/>
          </trackBegin>
          <trackEnd id="teocp02tr02" pos="450">
            <macroscopicNode ocpRef="ocp02"/>
          </trackEnd>
        </trackTopology>
      </track>
    </tracks>
    <operationControlPoints>
      <ocp id="ocp01"></ocp>
      <ocp id="ocp02">
        <propEquipment>
          <trackRef ref="ocp02tr01"/>
          <trackRef ref="ocp02tr02"/>
        </propEquipment>
      </ocp>
      <ocp id="ocp03"></ocp>
      <ocp id="ocp04"></ocp>
      <ocp id="ocp05"></ocp>
    </operationControlPoints>  
  </infrastructure>

The above railML^® code describes a macroscopic view of a railway network of 5 <ocp>s. The connections are displayed in the below sketch:

The above example also specifies two station tracks for the <ocp> with the id "ocp02". For more information on how to describe station tracks in a macroscopic view please also refer to this page or Dev:How to define track usage of a train in stations.

Referencing Infrastructure from Timetable

The minimum requirement for referencing infrastructure from timetable is a reference to an <ocp> for each <ocpTT>. The sequence of <ocpTT>s specifies where the train is going. Referencing an <ocp> is possible no matter which approach to describing infrastructure was chosen. Additionally several other infrastructure aspects can be referenced from timetable:

• follow-up track
• platform edge
• arrival/departure track
• scheduled arrival/departure track in case it was changed
• stop posts
• information areas for passenger information

Follow-up track

Using the element <sectionTT> it is possible to specify which <track> a train will take, going to the next station. It may be specified for an <ocpTT> and describes the <track> to the follow-up <ocpTT>. As for the reference to the <ocp> referencing a <track> is possible in a macroscopic as well as an in a microscopic view, however, it is optional to do so. Many programs that export timetable only include a rather minimalistic view on infrastructure that only includes the <ocp>s. Along with the actual reference to a <track> it is possible to provide additional information with the <sectionTT>, such as the <line> used or the scheduled <runTimes> to the next station. As of railML^® 2.5 it is also possible to specify alternative follow-up track along with a priority. The element used for this is <alternativeSectionTT>. This is useful when having to automatically select a detour to the next station. However, this usually requires specification of a microscopic infrastructure.

Arrival/Departure track

Typically the track a train arrives on or departs from is specified for each <ocpTT>. railML^® offers several ways of doing so. The first and probably easiest is by providing the attribute trackInfo for an <ocpTT>. The information provided thus is simply a string that can be used to inform passengers about which track a train is going to arrive or depart. As it is simply a string it is not recommended to evaluate its value in order to map it to business objects in the importing system. There is another way of specifying the arrival/departure <track> that is better suited for this, which is by use of the attribute trackRef which is also available for each <ocpTT>. This allows specifying an actual reference to a <track> specified in infrastructure. Usually the referenced track is listed under <ocp>/<propEquipment>/<trackRef>. This applies for both, macroscopic as well as microscopic representation of the infrastructure as demonstrated in the two examples above.
For more information on how to specify station tracks refer to Dev:How to define track usage of a train in stations of the documentation of <track>.

Platform Edge

For each <ocpTT> it is possible to specify which platform edge is being used at a stop. This can be achieved using the sub-element <platformEdgeRef> of the <ocpTT>. Multiple <platformEdge>'s can be referenced this way. Like this also multiple platform edge usage can be described in railML^®. This works the same for station tracks specified in a macroscopic view as in a microscopic view.

Scheduled Arrival/Departure track

As of version 2.5 of {{rml} it is possible to also describe the scheduled track information for a stop in case the used track was changed compared to the original planning. For this scenario the sub-element <originalTrackInfo> was introduced. As described in this guide all options for describing current track usage can also be used for originally scheduled tracks.

Stop posts

Another possible reference of infrastructure from the timetable sub-schema is available by referencing <stopPost>'s. By this an implicit reference to a <platformEdge> can also be given. For each <ocpTT> the reference to one <stopPost> may optionally be provided using the attribute stopPostRef of <stopDescription>. With this it can be specified where at the track exactly a train is expected to stop. Usually this information is specified if a microscopic infrastructure is provided, however there is nothing that would prevent a user to also specify this when using macroscopic infrastructure assuming that the <stopPost>'s are specified for the station tracks.

Information areas for passenger information

As of version 2.5 of railML^® it is possible to specify the rules for passenger information in a high level of detail. As a part of this it is possible to specify when a passenger info such as an <announcement> or a special text (<annotation>) should be triggered. There are several options available to describe a trigger like that. These can be specified for each <annotationRef> as an <activationTime> <startTime> as well as an <endTime>, both can be either an <eventTrigger>, an <ocpTrigger>, a <timingTrigger>, a <geoTrigger> or an <informationAreaTrigger>. For each <announcementRef> similar triggers can be specified. Of these <ocpTrigger> and <informationAreaTrigger> feature a reference to the infrastructure. As the name implies <ocpTrigger> allows referencing an <ocp> using its attribute ocpRef. <ocpTrigger> also allows specifying an optional offset which is used to express that the trigger is intended to apply a certain amount of meters apart from the center of the <ocp>. The other passenger information trigger that includes a reference to the infrastructure is <informationAreaTrigger>. With the attribute informationAreaRef it allows referencing a <genericArea>. Depending on the other attribute event the trigger applies when entering or leaving the area described in the infrastructures <genericArea>. Both these options to reference Infrastructure can be used in a macroscopic as well as a microscopic setting. <ocp>'s can be defined in both representations with as much detail as needed and {{IS:Tag|genericArea}'s also provide different ways of being positioned so that depending on the overall level of detail of the infrastructure a matching way of specification can be found. Please refer to the elements documentation for more details.