http://wiki.rtm.uic.org/index.php?title=Topological_structure_(network)&feed=atom&action=history
Topological structure (network) - Revision history
2022-08-09T10:07:34Z
Revision history for this page on the wiki
MediaWiki 1.33.1
http://wiki.rtm.uic.org/index.php?title=Topological_structure_(network)&diff=31&oldid=prev
WikiSysop: 1 revision imported
2019-11-26T08:13:01Z
<p>1 revision imported</p>
<p><b>New page</b></p><div>{{Overview|text=Lorem ipsum...}}<br /><br />
<br />
[[File:TopologicalStructure_UL.png|thumbnail|250px|Topological Structure (Language Unit)]]<br />
The topological structure of the network describes the relations of the building blocks of the network in the context of a given description level.<br /><br />
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.<br /><br />
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”.<br /><br />
The classes “LinearElement” and “LinearElementPart” serve for anchoring localisations of “NetEntity” instances via “AssociatedNetElement”.<br /><br />
The classes “NonLinearElement” and “NonLinearElementPart” serve for anchoring localisations of “NetEntity” instances via “SpotLocation”.<br />
<br />
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.<br /><br />
<br />
== Building the Structure ==<br />
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.<br />
<br />
{| class="wikitable"<br />
|-<br />
! Micro level nodetypes !! Number of neighbours !! Type of neighbours<br />
|-<br />
| bufferstop || 1 || trackEdge<br />
|-<br />
| borderpoint || 1 || trackEdge<br />
|-<br />
| switch || 3 || trackEdge, adjacent switch or crossing<br />
|-<br />
| Double Diamond Crossing || 4 || trackEdge, adjacent switch or crossing<br />
|-<br />
| Single Diamond Crossing || 4 || trackEdge, adjacent switch or crossing<br />
|-<br />
| crossing || 4 || trackEdge, adjacent switch or crossing<br />
|-<br />
| turntable || depending on construction || trackEdge<br />
|-<br />
| Transfer table || depending on construction || trackEdge<br />
|}<br />
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.<br />
<br />
=== Navigability Information ===<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 /><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 /><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 /><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 /><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 {{rtm}}.<br />
<br />
=== Condensed Relations Matrix ===<br />
[[File:CondensedMatrix.png|thumbnail|Condensed Relations Matrix (© UIC {{rtm}} Expert Group)]]<br />
<br />
The matrix shown on the right is read like:<br />
* 1 is related to 2, and this relation is navigable,<br />
* 1 is related to 3, and this relation is navigable,<br />
* 2 is related to 1, and this relation is navigable, - 2 is related to 3, and this relation is NOT navigable (-),<br />
* …<br />
This condensed description of the network contains only linear elements.<br /><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 /><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 /><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 /><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 /><br />
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.<br /><br />
However, when transmitting data for only a specific level, both physical and routing views for this level have to be included.<br />
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.<br /><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 /><br />
<br />
=== Finalisation of the Elements ===<br />
[[File:ModelPart5.png|thumbnail|250px|Model Part 5 (© {{rml}})]]<br />
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.<br />
<br />
There are four predefined levels, each containing its set of linear and nonlinear objects.<br /><br />
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.<br />
<br /><br />
<br /><br />
<br /><br />
<br /><br />
<br />
== Network Example ==<br />
The sample network consists of four nodes and three edges and is shown in a classical physical representation (Fig.1).<br />
<br />
In {{rtm}} those three edges are represented as three “NetElement” instances shown in the “Network element view” (Fig.2).<br />
<br />
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).<br />
<br />
The four nodes will be represented by net entity object.<br />
<br />
<gallery><br />
File:Sample3EdgesNetwork2.png|Fig.1 Sample Network (© Sncf Réseau)<br />
File:PureNetElement3.png|Fig.2 Network as pure NetElement View (© Sncf Réseau)<br />
File:NetElementRelation2.png| Fig.3 Network with NetElement and Relation instances (© Sncf Réseau)<br />
</gallery><br />
<br />
=== Relations ===<br />
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.<br />
<br />
<gallery><br />
File:ExamplePositionedRalation2.png|PositionedRelation Example (© Sncf Réseau)<br />
</gallery><br />
<br />
The relation “R1” carries the following information:<br />
* ElementA : element named 1 <br />
* PositionOnA : 1 (end of the element) <br />
* Element B : element named 2 <br />
* PositionOnB : 0 (start of the element) <br />
<br />
So far the graph expresses the connectedness of the elements. <br /><br />
The next step adds the routing information to produce the optimised connexity representation. <br /><br />
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:<br />
<br />
<gallery><br />
File:NavigabilityInformationRel2.png|Navigability information for relations (© Sncf Réseau)<br />
</gallery><br />
<br />
Meaning :<br />
* It is possible to go from 1 to 2 (and vice versa)<br />
* It is possible to go from 1 to 3 (and vice versa)<br />
* It is not possible to go from 2 to 3 (and vice versa), 2 and 3 are just "connected"<br />
<br />
=== Functional Level ===<br />
The physical view is not very well suited for a specific class of use cases like routing, timetabling or simulation.<br /><br />
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.<br /><br />
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.<br /><br />
So the “Physical” level is complemented with a “Functional”, or routing level describing how the elements act together as a routable network.<br /><br />
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:<br />
<br />
<gallery><br />
File:Navigability.png|Navigability through elements (© InfraBel)<br />
</gallery><br />
<br />
{{navi<br />
|chapter={{RTM}} modelling concepts<br />
|chapterlink=RTM modelling concepts<br />
|prev=Levels of detail<br />
|next=Positioning<br />
|pchapter={{rtm}} Quick Start<br />
|pchapterlink=RTM Quick Start<br />
|nchapter={{rtm}} External References<br />
|nchapterlink=RTM External References<br />
|section=[[structure]]<br />
|subsection=Topological structure (network)<br />
|snext=Hierarchical structure (levels)<br />
}}</div>
WikiSysop