Topological structure (network)

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.
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
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
As the core elements of the network have been defined, linear and nonlinear 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 macrolevel, 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) 