Topological structure (network): Difference between revisions

From railTOPOMODEL® Wiki
Jump to navigation Jump to search
[checked revision][checked revision]
mNo edit summary
(Änderung Navi)
(4 intermediate revisions by 2 users not shown)
Line 36: Line 36:


=== Navigability Information ===
=== Navigability Information ===
In the RailTopoModel the navigability information can be stored in an optimal way at the PositionedRelation between the edges of the respective level.<br />
In the {{rtm}} the navigability information can be stored in an optimal way at the PositionedRelation between the edges of the respective level.<br />
If there exists a connected dataset with the NetElements and Relations below the current description level, navigability can be deduced from this information. The micro level data without navigability information together with nano level data containing the topological structure of each switch, crossing, turntable or transfer table allow to transfer navigability information to the micro level. After removal of the superfluous nodes the resulting subset of micro level data consists only of trackEdges with the relevant navigability information which in turn is relevant to routing algorithms.<br />
If there exists a connected dataset with the NetElements and Relations below the current description level, navigability can be deduced from this information. The micro level data without navigability information together with nano level data containing the topological structure of each switch, crossing, turntable or transfer table allow to transfer navigability information to the micro level. After removal of the superfluous nodes the resulting subset of micro level data consists only of trackEdges with the relevant navigability information which in turn is relevant to routing algorithms.<br />
In case the detailed nano level information does not yet exist, it is also quite easy to add navigability information manually directly to the trackEdges.<br />
In case the detailed nano level information does not yet exist, it is also quite easy to add navigability information manually directly to the trackEdges.<br />
The RailTopoModel provides the necessary structures to produce a condensed relation matrix out of the detailed physical relations matrix. If there exists a detailed nano level description of each switch connected to the micro level – as is the case in some pilot projects of early adopters of the RailTopoModel – then full automation is achievable.<br />
The {{rtm}} provides the necessary structures to produce a condensed relation matrix out of the detailed physical relations matrix. If there exists a detailed nano level description of each switch connected to the micro level – as is the case in some pilot projects of early adopters of the {{rtm}} – then full automation is achievable.<br />
The same principle holds true between the macro and the micro level. This again is a direct consequence of the elegant recursive nature of the RailTopoModel.
The same principle holds true between the macro and the micro level. This again is a direct consequence of the elegant recursive nature of the {{rtm}}.


=== Condensed Relations Matrix ===
=== Condensed Relations Matrix ===
[[File:CondensedMatrix.png|thumbnail|Condensed Relations Matrix (© UIC RTM Expert Group)]]
[[File:CondensedMatrix.png|thumbnail|Condensed Relations Matrix (© UIC {{rtm}} Expert Group)]]


The matrix shown on the right is read like:
The matrix shown on the right is read like:
Line 52: Line 52:
This condensed description of the network contains only linear elements.<br />
This condensed description of the network contains only linear elements.<br />
While this routing view exists for all description levels, it only has to be described at the lowest level. The other routing views are a direct result of aggregation.<br />
While this routing view exists for all description levels, it only has to be described at the lowest level. The other routing views are a direct result of aggregation.<br />
Using RailTopoModel concepts a very concise network of connected elements was created. The achieved structure allows the application of graph theory algorithms as well as the location of arbitrary information objects.<br />
Using {{rtm}} concepts a very concise network of connected elements was created. The achieved structure allows the application of graph theory algorithms as well as the location of arbitrary information objects.<br />
So bridging the gap between the two worlds of “railway builders” and “railway operators” is possible and a secure and correct flow of information between all information systems becomes a reality.<br />
So bridging the gap between the two worlds of “railway builders” and “railway operators” is possible and a secure and correct flow of information between all information systems becomes a reality.<br />
As the relations are described through nodes, the nodes themselves will not be encompassed in this description, resulting in a network with only linear elements.<br />
As the relations are described through nodes, the nodes themselves will not be encompassed in this description, resulting in a network with only linear elements.<br />
Line 61: Line 61:


=== Finalisation of the Elements ===
=== Finalisation of the Elements ===
[[File:ModelPart5.png|thumbnail|250px|Model Part 5 (© railML)]]
[[File:ModelPart5.png|thumbnail|250px|Model Part 5 (© {{rml}})]]
As the core elements of the network have been defined, linear and non-linear elements can be distinguished which can be further extended to suit a particular level’s need.
As the core elements of the network have been defined, linear and non-linear elements can be distinguished which can be further extended to suit a particular level’s need.


Line 74: Line 74:
The sample network consists of four nodes and three edges and is shown in a classical physical representation (Fig.1).
The sample network consists of four nodes and three edges and is shown in a classical physical representation (Fig.1).


In RailTopoModel those three edges are represented as three “NetElement” instances shown in the “Network element view” (Fig.2).
In {{rtm}} those three edges are represented as three “NetElement” instances shown in the “Network element view” (Fig.2).


This pure “NetElement” view misses the topological relations of the original classical representation. Therefore “Relation” instances are added which represent the topological connections. Each “Relation” instance connects two “NetElement” instances (Fig.3).
This pure “NetElement” view misses the topological relations of the original classical representation. Therefore “Relation” instances are added which represent the topological connections. Each “Relation” instance connects two “NetElement” instances (Fig.3).
Line 90: Line 90:


<gallery>
<gallery>
File:ExamplePositionedRalation2.png|PositionedRelation Example (© InfraBel)
File:ExamplePositionedRalation2.png|PositionedRelation Example (© Sncf Réseau)
</gallery>
</gallery>


Line 104: Line 104:


<gallery>
<gallery>
File:NavigabilityInformationRel.png|Navigability information for relations (© InfraBel)
File:NavigabilityInformationRel2.png|Navigability information for relations (© Sncf Réseau)
</gallery>
</gallery>


Meaning :
Meaning :
* It is possible to go from A to 1 (and vice versa)
* It is possible to go from 1 to 2 (and vice versa)
* It is possible to go from 1 to B
* It is possible to go from 1 to 3 (and vice versa)
* It is possible to go from B to 3
* It is not possible to go from 2 to 3 (and vice versa), 2 and 3 are just "connected"
* It is possible to go from B to 2
* …
These relations are expressed more compactly using a matrix:
 
<gallery>
File:RelationsMatrix.png|Physical Relations Matrix (© UIC RTM Expert Group)
</gallery>


=== Functional Level ===
=== Functional Level ===
Line 130: Line 123:
</gallery>
</gallery>


 
{{navi
{| class="wikitable"
|chapter={{RTM}} modelling concepts
|-
|chapterlink=RTM modelling concepts
| '''What you should have learned'''<br />
|prev=Levels of detail
Lorem ipsum...
|next=Positioning
*
|pchapter={{rtm}} Quick Start
* Bulleted list item
|pchapterlink=RTM Quick Start
|}
|nchapter={{rtm}} External References
 
|nchapterlink=RTM External References
 
|section=[[structure]]
{| class="wikitable"
|subsection=Topological structure (network)
|-
|snext=Hierarchical structure (levels)
! Back To !! Previous Chapter !! Next Chapter
}}
|-
| [[Structure]] || - || [[Hierarchical structure (levels)]]
|}

Revision as of 13:55, 13 March 2017

Overview
Lorem ipsum...


Topological Structure (Language Unit)

The topological structure of the network describes the relations of the building blocks of the network in the context of a given description level.
The class “NetElement” depicts all building blocks of the topology. In a classical physical description it consists of what is commonly called “edges” (i.e. the iron). In the optimised description for fast operational computations the physical nodes are removed and only the edges remain. The properties of the physical nodes are the basis for the relations. A detailed description of the conversion from the classical description into the optimised connexity based description can be found below.
Therefore the class “PositionedRelation” which is inheriting the associations to “NetElement” contains attributes which describe navigabilty as well as hints for the position at the associated “PositioningNetElements”.
The classes “LinearElement” and “LinearElementPart” serve for anchoring localisations of “NetEntity” instances via “AssociatedNetElement”.
The classes “NonLinearElement” and “NonLinearElementPart” serve for anchoring localisations of “NetEntity” instances via “SpotLocation”.

Based on this structure of the topological network description the following diagrams show the interaction of the “NetElement” instances. That interaction provides the glue to use those components as a network.

Building the Structure

Many existing datasets covering the physical view contain information objects which are not essential for routing algorithms. These objects increase the address space as well as the runtime of algorithms. The table below shows the most common nodetypes of railway networks at the micro description level.

Micro level nodetypes Number of neighbours Type of neighbours
bufferstop 1 trackEdge
borderpoint 1 trackEdge
switch 3 trackEdge, adjacent switch or crossing
Double Diamond Crossing 4 trackEdge, adjacent switch or crossing
Single Diamond Crossing 4 trackEdge, adjacent switch or crossing
crossing 4 trackEdge, adjacent switch or crossing
turntable depending on construction trackEdge
Transfer table depending on construction trackEdge

All those elements above can be removed from the dataset provided that the linear elements (pieces of track between two nodes aka trackEdge) carry the necessary attributes for navigation.

Navigability Information

In the railTOPOMODEL® the navigability information can be stored in an optimal way at the PositionedRelation between the edges of the respective level.
If there exists a connected dataset with the NetElements and Relations below the current description level, navigability can be deduced from this information. The micro level data without navigability information together with nano level data containing the topological structure of each switch, crossing, turntable or transfer table allow to transfer navigability information to the micro level. After removal of the superfluous nodes the resulting subset of micro level data consists only of trackEdges with the relevant navigability information which in turn is relevant to routing algorithms.
In case the detailed nano level information does not yet exist, it is also quite easy to add navigability information manually directly to the trackEdges.
The railTOPOMODEL® provides the necessary structures to produce a condensed relation matrix out of the detailed physical relations matrix. If there exists a detailed nano level description of each switch connected to the micro level – as is the case in some pilot projects of early adopters of the railTOPOMODEL® – then full automation is achievable.
The same principle holds true between the macro and the micro level. This again is a direct consequence of the elegant recursive nature of the railTOPOMODEL®.

Condensed Relations Matrix

Condensed Relations Matrix (© UIC railTOPOMODEL® Expert Group)

The matrix shown on the right is read like:

  • 1 is related to 2, and this relation is navigable,
  • 1 is related to 3, and this relation is navigable,
  • 2 is related to 1, and this relation is navigable, - 2 is related to 3, and this relation is NOT navigable (-),

This condensed description of the network contains only linear elements.
While this routing view exists for all description levels, it only has to be described at the lowest level. The other routing views are a direct result of aggregation.
Using railTOPOMODEL® concepts a very concise network of connected elements was created. The achieved structure allows the application of graph theory algorithms as well as the location of arbitrary information objects.
So bridging the gap between the two worlds of “railway builders” and “railway operators” is possible and a secure and correct flow of information between all information systems becomes a reality.
As the relations are described through nodes, the nodes themselves will not be encompassed in this description, resulting in a network with only linear elements.
While this routing view exists for all detailed levels, it only has to be described at the lowest level, as the other routing views are a direct result of aggregation.
However, when transmitting data for only a specific level, both physical and routing views for this level have to be included. This completes a network of connected elements. It is modelled in a way where graph theory algorithms are applicable, and items can be located on it.
So bridging the gap between the two worlds of “railway builders” and “railway operators” is possible and a secure and correct flow of information between all information systems becomes a reality.

Finalisation of the Elements

Model Part 5 (© railML®)

As the core elements of the network have been defined, linear and non-linear elements can be distinguished which can be further extended to suit a particular level’s need.

There are four predefined levels, each containing its set of linear and nonlinear objects.
For example, at the macro-level, the linear objects will be the sections of lines, and the nonlinear elements will be the major operational points.



Network Example

The sample network consists of four nodes and three edges and is shown in a classical physical representation (Fig.1).

In railTOPOMODEL® those three edges are represented as three “NetElement” instances shown in the “Network element view” (Fig.2).

This pure “NetElement” view misses the topological relations of the original classical representation. Therefore “Relation” instances are added which represent the topological connections. Each “Relation” instance connects two “NetElement” instances (Fig.3).

The four nodes will be represented by net entity object.

Relations

An association between linear “NetElement” instances and a “Relation” instance requires the information at which end of the linear object the relation is valid. This information can be found in the specialised class “PositionedRelation”. The two attributes “positionOnA” and “positionOnB” contain location information using intrinsic coordinates. “0” means that the relation is located at the beginning of the “NetElement” instance, “1” means that the relation is located at the end of the “NetElement” instance.

The relation “R1” carries the following information:

  • ElementA : element named 1
  • PositionOnA : 1 (end of the element)
  • Element B : element named 2
  • PositionOnB : 0 (start of the element)

So far the graph expresses the connectedness of the elements.
The next step adds the routing information to produce the optimised connexity representation.
Considering the initial diagram and using the knowledge about the switch depicted as node B it possible to enrich the current diagram with explicit navigability information at the relations:

Meaning :

  • It is possible to go from 1 to 2 (and vice versa)
  • It is possible to go from 1 to 3 (and vice versa)
  • It is not possible to go from 2 to 3 (and vice versa), 2 and 3 are just "connected"

Functional Level

The physical view is not very well suited for a specific class of use cases like routing, timetabling or simulation.
With physical relations matrix alone, it is impossible to tell that, through B, it is not allowed to go from 3 to 2, as there is no direct relation between 3 and 2.
In fact, all the connections to and from a node are always navigable, as it means that a train can “enter” the node from there.
So the “Physical” level is complemented with a “Functional”, or routing level describing how the elements act together as a routable network.
To know the relations between the objects through one node, the interactions between the elements are described related to that node. So the relations between the following elements are shown:









What you should have learned
Please, enter a summary!
Navigation
Home
Chapter railTOPOMODEL® Quick Start railTOPOMODEL® modelling concepts railTOPOMODEL® External References
Section Levels of detail structure Positioning
Subection Topological structure (network) Hierarchical structure (levels)