Levels of detail

From wiki.railtopomodel.org
Jump to: navigation, search
Overview
Lorem ipsum...


Nano

The Nano description level identifies what happens inside a switch or crossing. It is where the distinction may be made between different types of switches.
Typically, this level will be built starting from the micro level, by using “switch templates”.

Examples:

Micro

This level defines the network in the nearest way to the physical level as commonly viewed.
Its nonlinear elements are the switch points, the network borders, maybe some administrative points (ownership boundaries), buffer stops, while its linear elements are the tracks connecting those NonLinear Elements. The linear elements will be called ‘track edges’.

Examples:

Meso

The Meso level brings the description of the tracks between the operational points of the network into focus.
Its NonLinear Elements are the operational points (OP; e.g. stations, yards, boundaries) and its linear elements are the tracks connecting those elements, which will be called SectionOfTracks.

Examples:

Macro

The Macro level aims to describe the network at regional or national level, with the NonLinear elements being the boundaries and the major OP’s while the linear elements are the section of lines connecting those points.

Examples:

Navigability

The network carries the information on how the railway network behaves as a mathematical network allowing routing operations. Navigability views are required for every level used for routing calculations. Because higher levels view can be computed by aggregation, only the lowest level view has to be explicitly defined.
However, when transmitting routing data for a single level, the navigability view for this level has to be known by all participants of the transmission.

Other Levels

While four levels (nano, micro, meso, macro) are predefined, the model allows to build an infinite number of other levels, or an infinite number of paths to aggregate from one level to the other.

For example, the European high-speed lines form a network which can be aggregated from the macro network of the European countries.

However, while the four predefined levels are quite common among infrastructure managers (IM), it is still possible to start from other network definitions, using different segmentation conventions (for example, defining the most basic network with the signaling blocks, not the iron network). It is also possible to split from the main path by defining networks using different segmentations (for example, a grid/intergrid structure).

While these networks do not follow the predefined path, they still can be expressed as networks using the RailTopoModel® structure.

Flexible Change of Level of Detail (Vertical Browsing)

Fulfilling the requirements of the basic use case the definition of a complete network in only one description layer is not sufficient.
Those IT systems require several coherent view levels. Using the same logic while dealing with different description layers is also an important requirement.
To ensure the coherency between levels, every level is built relative to another level. The levels are built by aggregating (or dividing) elements of the base level.
In most cases this means that elements will be grouped to produce a simpler, more manageable network.

Sample network:

It is all well to calculate accurate paths. Looking at usecase of shareing timetables one notes that the public is not interested in all the possible different paths.
It will be communicated under the form

Station A, departure time, station B arrival.
Internally, the network management teams are also interested in intermediate levels, such as this one:

Each of those representations form their own network, and aggregation is the way to manage the links between those networks. To achieve this links are put between the higher level and the lower levels.

Each section of track encompassed in A must be earmarked as a part of this entity.

Obviously the definition of a complete network is not enough. There are required several view levels, and there must be coherence between them. Exactly the same logic (and thus the same model) has to be kept throughout the different levels.
To ensure the coherency between levels, every level is built relative to another level. The levels are built by aggregating (or dividing) elements of the base level.
From a practical point of view, it means that elements are being grouped to make a simpler, more manageable network.


Of course, information linked to lower level must also be transmitted to the higher levels. By aggregating details are lost, but it will be possible to calculate the aggregated values according to rules.
These may be simple rules, such as

  • Aggregated value = minimum of individual values
  • Aggregated values = sum of individual values

Examples for complex rules

  • Most permissive value on every possible individual paths between two elements linked to the considered element.

All those rules have to be defined once and for all, for any type of information or entity attached to the network.

It will be the job of all the relevant workgroup to define those rules, for the objects or entities they define.
The client receiving the information is expected to use it at the most relevant level. It is quite obvious that switch occupation conflicts cannot be computed at the level describing the European high speed network. This will be done at the most accurate level.
As already mentioned four predefined levels are proposed:

  • Nano (inside of switches and crossings, running track)
  • Micro (Track edges, switches, bufferstops)
  • Meso (Track edges, OPs)
  • Macro (Line sections, major OPs)

In addition to those levels, a routing view of the lowest level has to be given to describe the navigability on the network. Should no routability information be given, every movement will be considered possible (which may well be the case if only the macro level is described).

There is an infinite number of possible uses for the network definition. Thus the model allows for the creation of an arbitrary number of other levels, each one a network in itself.
As they all share the same model, there are no technical problems when defining them, but it is important to consider that:

  • the links between levels have to be laid and the aggregation rules have to be defined,
  • that it will become confusing to manage data attached to these levels and
  • that parallel lines of levels (levels derived/ aggregated from the same base level) may not be compatible.

So keeping it simple and sticking to a minimum number of levels seems to be a good strategy.

Dividing an element into smaller parts is also possible. Again, sets of rules must be identified to manage information that will be transmitted to the level below, such as:

  • Constant value
  • Value proportional to the length of the element part regarding the other element,









What you should have learned
Please, enter a summary!
Navigation
Home
Chapter RailTopoModel® Quick Start RailTopoModel® modelling concepts RailTopoModel® External References
Section Core elements Levels of detail Structure
Subection