http://wiki.railtopomodel.org/api.php?action=feedcontributions&user=Ferri+Leberl&feedformat=atom
wiki.railtopomodel.org - User contributions [en]
2020-06-02T17:10:54Z
User contributions
MediaWiki 1.26.2
http://wiki.railtopomodel.org/index.php?title=Template:Scrollbox&diff=936
Template:Scrollbox
2018-01-24T11:22:56Z
<p>Ferri Leberl: Created page with "<includeonly><div style="height:{{{height|120px}}};width:{{{width|100%}}};border:1px solid #ccc;overflow:auto;"> {{{1|'''content missing'''}}} </div></includeonly><noinclude>..."</p>
<hr />
<div><includeonly><div style="height:{{{height|120px}}};width:{{{width|100%}}};border:1px solid #ccc;overflow:auto;"><br />
{{{1|'''content missing'''}}}<br />
</div></includeonly><noinclude><br />
==Usage==<br />
This template creates a box if defined width and height. If the content exceeds the space, the box will feature a vertical and/or a horicontal scrolling bar.<br />
==Arguments==<br />
*Obligatory<br />
**'''1''': The content of the box. Most to anything that you can use in mediawiki.<br />
*Optional<br />
**'''width''': The width of the box, e.g. 250px or 25%. Default: 100%<br />
**'''height''': The height of the box. Default: 250px. It is possible, but in most cases not meaningfull to use percentage values, as the height of the pages can usually be infinite.<br />
==Examples==<br />
An example without any bars:<br />
<pre>{{scrollbox|This text fits into the box without scrolling.}}</pre><br />
delivers<br />
{{scrollbox|This text fits into the box without scrolling.}}<br />
<br />
An example with a horizontal bar:<br />
<pre>{{scrollbox|Donaudampfschiffahrtsgesellschaftskapitänskajüte|width=100px}}</pre><br />
delivers<br />
{{scrollbox|Donaudampfschiffahrtsgesellschaftskapitänskajüte|width=100px}}<br />
<br />
An example with a vertical bar:<br />
<pre>{{scrollbox|Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Aenean commodo ligula eget dolor. Aenean massa. Cum sociis natoque penatibus et magnis dis parturient montes, nascetur ridiculus mus. Donec quam felis, ultricies nec, pellentesque eu, pretium quis, sem.<br />
<br />
Nulla consequat massa quis enim. Donec pede justo, fringilla vel, aliquet nec, vulputate eget, arcu. In enim justo, rhoncus ut, imperdiet a, venenatis vitae, justo. Nullam dictum felis eu pede mollis pretium. Integer tincidunt. Cras dapibus.<br />
<br />
Vivamus elementum semper nisi. Aenean vulputate eleifend tellus. Aenean leo ligula, porttitor eu, consequat vitae, eleifend ac, enim. Aliquam lorem ante, dapibus in, viverra quis, feugiat a, tellus. Phasellus viverra nulla ut metus varius laoreet. Quisque rutrum. Aenean imperdiet. Etiam ultricies nisi vel augue. Curabitur ullamcorper ultricies nisi. Nam eget dui. Etiam rhoncus. Maecenas tempus, tellus eget condimentum rhoncus, sem quam semper libero, sit amet adipiscing sem neque sed ipsum.}}</pre><br />
delivers<br />
{{scrollbox|Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Aenean commodo ligula eget dolor. Aenean massa. Cum sociis natoque penatibus et magnis dis parturient montes, nascetur ridiculus mus. Donec quam felis, ultricies nec, pellentesque eu, pretium quis, sem.<br />
<br />
Nulla consequat massa quis enim. Donec pede justo, fringilla vel, aliquet nec, vulputate eget, arcu. In enim justo, rhoncus ut, imperdiet a, venenatis vitae, justo. Nullam dictum felis eu pede mollis pretium. Integer tincidunt. Cras dapibus.<br />
<br />
Vivamus elementum semper nisi. Aenean vulputate eleifend tellus. Aenean leo ligula, porttitor eu, consequat vitae, eleifend ac, enim. Aliquam lorem ante, dapibus in, viverra quis, feugiat a, tellus. Phasellus viverra nulla ut metus varius laoreet. Quisque rutrum. Aenean imperdiet. Etiam ultricies nisi vel augue. Curabitur ullamcorper ultricies nisi. Nam eget dui. Etiam rhoncus. Maecenas tempus, tellus eget condimentum rhoncus, sem quam semper libero, sit amet adipiscing sem neque sed ipsum.}}<br />
<br />
[[category:template]]</noinclude></div>
Ferri Leberl
http://wiki.railtopomodel.org/index.php?title=Intrinsic_positioning_/_referencing&diff=934
Intrinsic positioning / referencing
2017-03-14T13:50:06Z
<p>Ferri Leberl: /* Intrinsic */</p>
<hr />
<div>{{Overview|text=Lorem ipsum...}}<br /><br />
<br />
The coordinate system associated with each element. In order to be the most generic possible the value 0 is assigned to the start and 1 to the end for a linear element on the network. Nonlinear elements don't need the notion of a number between 0 and 1 since all the segments correspond to the same place on the network: the nonlinear element itself (= 0).<br /><br />
<gallery><br />
File:IntrinsicScale.png|Intrinsic Scale (© RFF/SNCF Réseau)<br />
</gallery><br />
<br />
It could be read as “At coordinate X after the start of the element”.<br />
<br />
[[File:IntrinsicPositioningLU.png|thumbnail|Intrinsic Positioning (Language Unit)]]<br />
A major goal of the {{rtm}} is the precise localisation of all relevant information objects in reference to the network.<br />
The class “PositioningNetElement” describes those building blocks of a “Network” which will be used as an “element of reference” for intrinsic positioning.<br /><br />
Intrinsic positioning in its pure form defines an interval from 0 to 1 for each “PositioningNetElement”. The extent of a “PositioningNetElement” instance in the real world is defined by associated “AssociatedPositioningSystem” instances which define a set of “LinearPositioningSystem” instances used for traditional positioning.<br /><br />
An “AssociatedPositioningSystem” instance possesses a set of “IntrinsicCoordinate” instances. Each “IntrinsicCoordinate” in turn is associated to one or more “PositioningSystemCoordinate” instances.<br /><br />
Together this structure allows to define an ordered list of transformation parameters which can be used to transform traditional LRS location into intrinsic locations and vice versa.<br /><br />
The same principle holds true for traditional geometric locations. An intrinsic location can be geocoded into a geometric coordinate and a geometric coordinate can be reverse geocoded into an intrinisic coordinate.<br /><br />
In principle the intrinsic value range of a given “PositioningNetElement” instance could mimic real world mileages. Considering the possibility of mileage anomalies and changes of the associated “LinearPositioningSystem” somewhere in the middle of the “PositioningNetElement” it is strongly recommended to use the 0 to 1 interval as the value range.<br /><br />
The start of the “PositioningNetElement” is attributed the value “0” whereas the end of the “PositioningNetElement” is attributed the value “1”. Applying this convention each location in reference to PositioningNetElement is expressed as a percentage of the element length starting from the beginning of the element.<br /><br />
Another big advantage is that intrinsic positioning based on 0 to 1 intervals allows algorithms which operate without units.<br /><br />
<br />
Now that the elements have been listed, the next goal is to provide a way to place items on these elements: a referencing system.<br /><br />
As there are a great many referencing methods available, and as the model has to be able to cope with many sources that are using different types of units or reference point, the underlying structure of the model is a unitless and universal method. However, later on means are being added to use any other referencing method, as long as the reference system is described.<br /><br />
<br />
=== Application of intrinsic positioning ===<br />
For linear elements (which have a start, end and length) the position of an information object is expressed as the distance from the start to the application point. To avoid conflicts between different unit types, this distance will be expressed as a percentage of the length of the element. For example, something right in the middle of the element would receive a coordinate of 0.5.<br /><br />
For non-linear elements, all referring positions using intrinsic coordinates will always be at the “start” of the element (coordinate 0, as the element has no length).<br /><br />
<gallery><br />
File:LinearReferencingPrinciple.png|Linear referencing principle (© InfraBel)<br />
File:PositioningAtNode.png|Positioning at a node (© InfraBel)<br />
</gallery><br />
<br />
It implies that an item may be located anywhere “along” a linear element (coordinate ranging from 0 to 1) but only “at” a nonlinear element (coordinate ranging from 0 to 0… that is 0).<br /><br />
<br />
It implies that, in this model, an item may be located anywhere “along” a linear element (coordinate ranging from 0 to 1) but only “at” a nonlinear element (coordinate ranging from 0 to 0… that is 0).<br /><br />
As the applied reference system is universal, any object can be attached to the network with a coordinate “Element, Position”. However, if this reference system is univocal, it is unreadable by a human. A conversion to more widely used coordinate systems will be discussed in the annex to this document.<br /><br />
<br />
[[File:ModelPart2.png|thumbnail|150px|Model Part 2 (© {{rml}})]]<br />
In terms of class diagram, the Generic NetElement class is extended with a class in which the intrinsic coordinate system is defined. The only role of this class is to know that the NetElement is oriented (linear) or not (the role of the CompositionNetElement class will be discussed later on).<br /><br />
While universal and deterministic (no two different locations on the network can point to the same coordinate – no single location on the network can have two coordinates), this referencing system is strictly logical and not human-usable. The link to Geographical/Geometrical or the more widely used Mileage system is part of chapter 6.6 Aggregation. <br /><br />
<br />
One ravel in the environment of a topological change is caused by the intrinsic positioning method.<br /><br />
On events of physical movements of switch(es), buffer stop(s), curves, track geometry all locations on the affected trails (or SoL’s) have to be recalculated.<br /><br />
Even in some cases where the topology is unchanged, recalculations have to be performed for locations which are expressed by intrinsic positioning.<br /><br />
At a second thought, we see the next disadvantages of intrinsic positioning:<br />
* Doubtful accuracy, regardless how many digits behind the digital dot are applied<br />
* Problems with data collection in the above value chain (+ costs)<br />
* The same with data maintenance (+ costs)<br />
* Bad or even impossible use ability in real life (mechanicals/operators) in the field and maintenance of history (at least conversion tool required)<br />
* Permanent recalculation on event of any topological or geometrical or (some) technical changes (conversion tool required).<br />
* Laborious use ability in the flow of the whole value chain with respect to the topological life cycle.<br />
In summary: from 2e bullet to last one: is there any positive business case thinkable? Probably not.<br /><br />
Consequence: the modeling group has to reconsider the utilization of the intrinsic positioning method !!<br />
<br />
'''Reminder:'''<br /><br />
The main purpose of the Intrinsic positioning system is to provide an universal way to store/transmit the position of the '''INTERACTION''' between the network and objects/events. <br /><br />
'''It is thus not intended to manage the (position of the) network/objects themselves.''' <br /><br />
Its accuracy depends on the accuracy of measurement of both interacting elements : the network and the event. Its lack of accuracy is not inherent to the storage method, but more of the accuracy of the measurement methods of each elements. <br /><br />
It is only currently described as the only referencing method because, up to now, we did not describe the objects. When designing the object classes, other referencing methods may (and will) be used as primary system. <br /><br />
It is a calculated value, especially useful when computing. It is thus not intended to be “Read” or “Written” by an human being. It is also not intended to be used in the field by human beings, as most of the time they don’t need to know the interaction between the object and the network, but rather the position of the object itself.<br /><br />
As it is the interaction between two elements, it has indeed to be recalculated as any of those elements changes. And it cannot be otherwise, because if one of the two element changes, the interaction also changes. <br /><br />
However, it only need to be calculated '''when knowing the interaction''' between an object and the network '''is needed''' (or before the transmission of data).<br /><br />
Its advantages are multiple when computing or transmitting data: <br /><br />
* As it is unitless, it can be used to compare/combine data from different sources, only the “Length” property of the carrier object need to be translated, not every relationship.<br />
* It never has to deal with “mileage anomalies”, so designing algorithms is easier and faster.<br />
* The computation algorithms need only be designed one time (and not one for each referencing method / combination of referencing methods).<br />
* Easy validation check ( from 0 to 1, you do not have to check which units are used, you don’t need to convert between m/km, miles/m/yards/feet…).<br />
* No possible errors when positioning relations: it has to be either at 0 or 1 (avoiding possible digit number errors between the length and relation position).<br />
* You can describe a conversion between any system and the intrinsic. If you add a new system, adding a conversion to intrinsic allows the conversion from/to any other system already described.<br />
* The reference system is built independently of the elements, allowing to describe mileage anomalies once for all the elements concerned (as several parallel tracks may share the same reference system, or be valid for more than one level)<br />
=== Application to the model ===<br />
Considering the following elements:<br /><br />
<gallery><br />
File:LinearInstrinsic.png|<br />
</gallery><br />
<br />
We only take spot objects and assume there is no mileage anomaly, in order to keep it simple.<br /><br />
The model allows two possible approaches: <br /><br />
=== Intrinsic ===<br />
<br />
<gallery><br />
File:IntrinsicExample.png|<br />
</gallery><br />
<br />
We manage the intrinsic coordinate for each object: 0.19191919 <br /><br />
As the relation between the intrinsic and the linear reference systems is known, the translation may be done to the linear coordinate system if/when needed.<br /><br />
However, it is not a very user friendly way to manage data that has to be manually entered.<br /><br />
<br />
{{navi<br />
|chapter={{RTM}} modelling concepts<br />
|chapterlink=RTM modelling concepts<br />
|prev=Structure<br />
|next=Object positioning in the network<br />
|pchapter={{rtm}} Quick Start<br />
|pchapterlink=RTM Quick Start<br />
|nchapter={{rtm}} External References<br />
|nchapterlink=RTM External References<br />
|section=[[Positioning]]<br />
|sprev=Return to ''Positioning''<br />
|sprevlink=Positioning#RailTopoModel.C2.AE_structure<br />
|subsection=Intrinsic positioning / referencing<br />
|snext=Track-referred positioning<br />
}}</div>
Ferri Leberl
http://wiki.railtopomodel.org/index.php?title=Linear_Positioning_/_referencing&diff=933
Linear Positioning / referencing
2017-03-14T13:49:08Z
<p>Ferri Leberl: /* Hybrid expression */</p>
<hr />
<div>'''Linear Positioning / referencing'''<br />
<br />
Linear Referencing Systems (LRS) are widely used in the transportation world. They allow specifying positions along linear elements by using distances measured along the element (possibly with a lateral and horizontal offset), not by using classical 2D or 3D coordinating systems (CRS). <br /><br />
<br />
Locating an object with linear coordinates makes sense for various reasons. First of all, a large amount of information is stored in databases from legacy systems, anterior to geographical information systems which are specifically designed to deal with classical CRS. Knowing where an object is located along a route or a pipeline is sufficient to use the data from those databases, and can be seen as an integration mean for data coming from different sources. <br /><br />
<br />
It is even sometimes more interesting to have a linear position than a spatial position. Knowing that you have train stopped at about the kilometre 45 on the Line 36 Track A is better than having a potentially more accurate GPS position, which does neither tell without ambiguity on which line nor track it stands.<br />
<br />
=== Norms ===<br />
Linear Referencing is the object of the European Norm EN19148:2012. <br /><br />
<br />
The {{rtm}} follows the same principles, but uses a simplified version of the model as a lot of cases foreseen in the norm are not encountered in the railways world.<br />
<br /><br />
=== Axis ===<br />
A linear referencing system has an axis along which the measures are done. The axis can be any linear entity, a track segment or a whole line. It does not need to have geometry as knowing its length is enough to use an LRS.<br />
=== Referencing Methods===<br />
<br />
A Linear Referencing System may use several methods to describe a position along an axis: <br />
* '''Absolute''' : the position is specified by giving the distance starting at the beginning of the axis (with an eventual offset)<br />
<br />
[[File:ReferencingMethods Absolute.png|ReferencingMethodAbsolute]]<br />
<br />
Its main disadvantage is the fact that the whole length of the axis is taken into account when measuring. It means :<br />
# that the field workers always have to begin measurement at the start of the axis. It makes it unpractical for long axes,<br />
# that each change happening in the axis before the referenced object changes the coordinate of the measured point.<br />
It is thus only suitable for short axes, or axes which are very stable in the scope of the measurement. <br />
<br />
*'''Relative''' : The position is specified by giving the distance starting from an element (referent) whose position is known.<br />
<br />
[[File:ReferencingMethods Relative.png|ReferencingMethodRelative]]<br />
<br />
This is the most commonly used in railways, with mileposts as referents. Amongst its advantages is the stability of the coordinate which is now independent from works or axis changes happening before the referent, unless the change also affects the referent.<br /><br />
It is also more practical for the field workers as the measurement only has to start at the referent. <br /><br />
On the other hand, it forces to maintain a whole set of referents, ensuring they never move, and recalculating their position at each infrastructure change.<br /><br />
It makes it most suitable for long axes, such as lines, but poorly adapted to short segments (work reservations or sidings).<br /><br />
<br />
While it is possible to measure in both directions, (km x + y meters or km x+1 – z meters), the former method is the most widely used.<br /><br />
<br />
It is also the most suited to store long term information, because of the stability of the coordinates. However, it is very poorly suited to calculations as true distances are difficult to deduce from the coordinates.<br />
Both methods can include lateral or vertical offsets.<br /><br />
=== Expression of the distance ===<br />
The distance from the start of the measure (be it the start of the axis or the referent) can be expressed in several ways. <br />
*In metres (or miles, or any unit of choice)<br />
*Relative to the length of the element <br />
**As a percentage of the element (0…100 %)<br />
**Normalized (0…1). 75 % being expressed as 0.75<br />
* Hybrid : as a percentage of the length between two successive referents<br />
<br />
===== Hybrid expression =====<br />
The major problem with the relative method of linear referencing is the fact that it cannot be stored as a number when the system has mileage anomalies.<br /><br />
As the distance between two successive referents may be more than one kilometre (or 1000 units), the coordinate needs two fields to be stored. On top of that, not all reference points have a numeric name, a referent 12A might be inserted when lengthening the track between the mileposts 12 and 13.<br /><br />
<br />
The hybrid method aims to deal with this issue by assigning a fixed coordinate to each successive referent (usually a multiple of 1000) and adding the percentage of the distance between the two referents. <br /><br />
While it doesn’t allow true distance measurement, it keeps the sequence of the objects.<br /><br />
<br /><br />
<br />
For example, assuming the distance between the kilometre post 12 and 13 is 1200m and that the object needing to be located is at km 12 + 1050m, <br />
*Kilometre post 12 : coordinate 12000<br />
*Kilometre post 13 : coordinate 13000<br />
Object coordinate : coordinate of the referent (12000)+ percentage of the distance of the object regarding the distance between the referents (1050/1200) multiplied by the difference of coordinates between the two successive referents (1000)<br />
*Object coordinate : 12000 + (1050/1200)*1000 = 12875, which is a number that can be stored in one field and on which operations may be made.<br />
<br />
{{navi<br />
|lesson=<br><br />
* Coordinate reference systems are (besides intrinsic and conventional linear referencing) the third option to define positions/locations in the {{rtm}}.<br />
* All geodetic coordinate reference systems can be defined by a unique identifier: the EPSG code.<br />
* {{rtm}} implementation shall follow concepts of the existing international standard GML. <br />
* Coordinate reference systems can also be used to define schematic coordinates as they are used in terms of screen coordinates.<br />
|chapter={{RTM}} modelling concepts<br />
|chapterlink=RTM modelling concepts<br />
|prev=Structure<br />
|next=Object positioning in the network<br />
|pchapter={{rtm}} Quick Start<br />
|pchapterlink=RTM Quick Start<br />
|nchapter={{rtm}} External References<br />
|nchapterlink=RTM External References<br />
|sprev=Coordinate positioning<br />
|section=[[Positioning]]<br />
|subsection=Linear Positioning / referencing<br />
|snext=Return to ''Positioning''<br />
|snextlink=Positioning#RailTopoModel.C2.AE_structure<br />
}}</div>
Ferri Leberl
http://wiki.railtopomodel.org/index.php?title=Template:Navi&diff=932
Template:Navi
2017-03-14T13:46:38Z
<p>Ferri Leberl: /* Arguments */</p>
<hr />
<div><includeonly><br />
<br /><br />
<br /><br />
<br /><br />
<br /><br />
<br /><br />
<br /><br />
<br /><br />
{| class="wikitable"<br />
|-<br />
! colspan="4"| What you should have learned<br />
|-<br />
| colspan="4"|{{{lesson|Please, enter a summary!}}}<br />
|-<br />
! colspan="4"| Navigation<br />
|-<br />
|'''[[Main_Page|Home]]'''||''←''||''•''||''→''<br />
|-<br />
|''Chapter''||{{#if:{{{pchapter|}}}|[[{{#if:{{{pchapterlink|}}}|{{{pchapterlink}}}|{{{pchapter}}}}}|{{{pchapter}}}]]}}||[[{{#if:{{{chapterlink|}}}|{{{chapterlink}}}|{{{chapter}}}}}|{{{chapter}}}]]||{{#if:{{{nchapter|}}}|[[{{#if:{{{nchapterlink|}}}|{{{nchapterlink}}}|{{{nchapter}}}}}|{{{nchapter}}}]]}}<br />
|-<br />
|''Section''||{{#if:{{{prev|}}}|[[{{#if:{{{prevlink|}}}|{{{prevlink}}}|{{{prev}}}}}|{{{prev}}}]]}}||{{{section|[[{{PAGENAME}}]]}}}||{{#if:{{{next|}}}|[[{{#if:{{{nextlink|}}}|{{{nextlink}}}|{{{next}}}}}|{{{next}}}]]}}<br />
|-<br />
|''Subection''||{{#if:{{{sprev|}}}|[[{{#if:{{{sprevlink|}}}|{{{sprevlink}}}|{{{sprev}}}}}|{{{sprev}}}]]}}||{{#if:{{{subsection|}}}|[[{{#if:{{{subsectionlink|}}}|{{{subsectionlink}}}|{{{subsection}}}}}|{{{subsection}}}]]}}||{{#if:{{{snext|}}}|[[{{#if:{{{snextlink|}}}|{{{snextlink}}}|{{{snext}}}}}|{{{snext}}}]]}}<br />
|}</includeonly><noinclude><br />
==Usage==<br />
This template offers a standardized menu for the page foot. It offers a chapter ''What you have learned'' and a swift shift to the {{rtm}} home page, the chapter home page, the previous and the next section.<br />
===Arguments===<br />
The template has two obligatory and four optional arguments, all of which are named.<br />
*Obligatory<br />
**chapter: the chapter, which the page is assigned to<br />
**lesson: this argument bears the text of the symmary<br />
*Optional<br />
**prev: the name of the previous section. Usually it will be identical with the link to the previous section, so the latter can be left away. As there is not allways a previous section, also prev may be empty.<br />
**next: the name of the previous section. Usually it will be identical with the link to the next section, so the latter can be left away. As there is not allways a next section, also next may be empty.<br />
**prevlink: an argument for the link to the previous section, if it differs from ''prev''.<br />
**nextlink: an argument for the link to the next section, if it differs from ''next''.<br />
**nchapter: an argument for the next chapter<br />
**nchapterlink: an argument for link to the next chapter<br />
**pchapter: an argument for the previous chapter<br />
**pchapterlink: an argument for the previous chapter<br />
**section: An argument for the current section. It will be dispalyed as is, so make links explicit here. The default is a circle link to the respective page.<br />
**subsection: The current subsection<br />
**sprev: the previous subsection<br />
**sprevlink: the link to the previous subsection<br />
**snext: the next subsection<br />
**snextlink: the link to the next subsection<br />
<br />
==Examples==<br />
<pre>{{navi}}</pre><br />
delivers<br />
<br />
<br />
<br /><br />
<br /><br />
<br /><br />
<br /><br />
<br /><br />
<br /><br />
<br /><br />
{| class="wikitable"<br />
|-<br />
! colspan="4"| What you should have learned<br />
|-<br />
| colspan="4"|Please, enter a summary!<br />
|-<br />
! colspan="4"| Navigation<br />
|-<br />
|'''[[Main_Page|Home]]'''||''←''||''•''||''→''<br />
|-<br />
|''Chapter''||{{#if:|[[{{#if:|{{{pchapterlink}}}|{{{pchapter}}}}}|{{{pchapter}}}]]}}||[[{{#if:|{{{chapterlink}}}|{{{chapter}}}}}|{{{chapter}}}]]||{{#if:|[[{{#if:|{{{nchapterlink}}}|{{{nchapter}}}}}|{{{nchapter}}}]]}}<br />
|-<br />
|''Section''||{{#if:|[[{{#if:|{{{prevlink}}}|{{{prev}}}}}|{{{prev}}}]]}}||[[{{PAGENAME}}]]||{{#if:|[[{{#if:|{{{nextlink}}}|{{{next}}}}}|{{{next}}}]]}}<br />
|-<br />
|''Subection''||{{#if:|[[{{#if:|{{{sprevlink}}}|{{{sprev}}}}}|{{{sprev}}}]]}}||{{#if:|[[{{#if:|{{{subsectionlink}}}|{{{subsection}}}}}|{{{subsection}}}]]}}||{{#if:|[[{{#if:|{{{snextlink}}}|{{{snext}}}}}|{{{snext}}}]]}}<br />
|}<br />
<br />
<pre>{{navi<br />
|lesson=Seid wachsam!<br />
|chapter={{RTM}} modelling concepts<br />
|prev={{RTM}} Quick Start<br />
|next=Borders of {{RTM}}<br />
|chapterlink=RTM modelling concepts<br />
|prevlink=RTM Quick Start<br />
|nextlink=Borders of RTM<br />
|section=<br />
}}</pre><br />
delivers<br />
<br />
<br />
<br /><br />
<br /><br />
<br /><br />
<br /><br />
<br /><br />
<br /><br />
<br /><br />
{| class="wikitable"<br />
|-<br />
! colspan="4"| What you should have learned<br />
|-<br />
| colspan="4"|Seid wachsam!<br />
|-<br />
! colspan="4"| Navigation<br />
|-<br />
|'''[[Main_Page|Home]]'''||''←''||''•''||''→''<br />
|-<br />
|''Chapter''||{{#if:|[[{{#if:|{{{pchapterlink}}}|{{{pchapter}}}}}|{{{pchapter}}}]]}}||[[{{#if:RTM modelling concepts|RTM modelling concepts|{{RTM}} modelling concepts}}|{{RTM}} modelling concepts]]||{{#if:|[[{{#if:|{{{nchapterlink}}}|{{{nchapter}}}}}|{{{nchapter}}}]]}}<br />
|-<br />
|''Section''||{{#if:{{RTM}} Quick Start|[[{{#if:RTM Quick Start|RTM Quick Start|{{RTM}} Quick Start}}|{{RTM}} Quick Start]]}}||||{{#if:Borders of {{RTM}}|[[{{#if:Borders of RTM|Borders of RTM|Borders of {{RTM}}}}|Borders of {{RTM}}]]}}<br />
|-<br />
|''Subection''||{{#if:|[[{{#if:|{{{sprevlink}}}|{{{sprev}}}}}|{{{sprev}}}]]}}||{{#if:|[[{{#if:|{{{subsectionlink}}}|{{{subsection}}}}}|{{{subsection}}}]]}}||{{#if:|[[{{#if:|{{{snextlink}}}|{{{snext}}}}}|{{{snext}}}]]}}<br />
|}<br />
<br />
<pre>{{navi<br />
|lesson=<br />
|chapter={{RTM}} modelling concepts<br />
|chapterlink=RTM modelling concepts<br />
|next=Core elements<br />
|section=<br />
}}</pre><br />
delivers<br />
<br />
<br />
<br /><br />
<br /><br />
<br /><br />
<br /><br />
<br /><br />
<br /><br />
<br /><br />
{| class="wikitable"<br />
|-<br />
! colspan="4"| What you should have learned<br />
|-<br />
| colspan="4"|<br />
|-<br />
! colspan="4"| Navigation<br />
|-<br />
|'''[[Main_Page|Home]]'''||''←''||''•''||''→''<br />
|-<br />
|''Chapter''||{{#if:|[[{{#if:|{{{pchapterlink}}}|{{{pchapter}}}}}|{{{pchapter}}}]]}}||[[{{#if:RTM modelling concepts|RTM modelling concepts|{{RTM}} modelling concepts}}|{{RTM}} modelling concepts]]||{{#if:|[[{{#if:|{{{nchapterlink}}}|{{{nchapter}}}}}|{{{nchapter}}}]]}}<br />
|-<br />
|''Section''||{{#if:|[[{{#if:|{{{prevlink}}}|{{{prev}}}}}|{{{prev}}}]]}}||||{{#if:Core elements|[[{{#if:|{{{nextlink}}}|Core elements}}|Core elements]]}}<br />
|-<br />
|''Subection''||{{#if:|[[{{#if:|{{{sprevlink}}}|{{{sprev}}}}}|{{{sprev}}}]]}}||{{#if:|[[{{#if:|{{{subsectionlink}}}|{{{subsection}}}}}|{{{subsection}}}]]}}||{{#if:|[[{{#if:|{{{snextlink}}}|{{{snext}}}}}|{{{snext}}}]]}}<br />
|}<br />
[[category:contentTemplate]]<br />
</noinclude></div>
Ferri Leberl
http://wiki.railtopomodel.org/index.php?title=Template:Navi&diff=931
Template:Navi
2017-03-14T13:40:46Z
<p>Ferri Leberl: /* Examples */</p>
<hr />
<div><includeonly><br />
<br /><br />
<br /><br />
<br /><br />
<br /><br />
<br /><br />
<br /><br />
<br /><br />
{| class="wikitable"<br />
|-<br />
! colspan="4"| What you should have learned<br />
|-<br />
| colspan="4"|{{{lesson|Please, enter a summary!}}}<br />
|-<br />
! colspan="4"| Navigation<br />
|-<br />
|'''[[Main_Page|Home]]'''||''←''||''•''||''→''<br />
|-<br />
|''Chapter''||{{#if:{{{pchapter|}}}|[[{{#if:{{{pchapterlink|}}}|{{{pchapterlink}}}|{{{pchapter}}}}}|{{{pchapter}}}]]}}||[[{{#if:{{{chapterlink|}}}|{{{chapterlink}}}|{{{chapter}}}}}|{{{chapter}}}]]||{{#if:{{{nchapter|}}}|[[{{#if:{{{nchapterlink|}}}|{{{nchapterlink}}}|{{{nchapter}}}}}|{{{nchapter}}}]]}}<br />
|-<br />
|''Section''||{{#if:{{{prev|}}}|[[{{#if:{{{prevlink|}}}|{{{prevlink}}}|{{{prev}}}}}|{{{prev}}}]]}}||{{{section|[[{{PAGENAME}}]]}}}||{{#if:{{{next|}}}|[[{{#if:{{{nextlink|}}}|{{{nextlink}}}|{{{next}}}}}|{{{next}}}]]}}<br />
|-<br />
|''Subection''||{{#if:{{{sprev|}}}|[[{{#if:{{{sprevlink|}}}|{{{sprevlink}}}|{{{sprev}}}}}|{{{sprev}}}]]}}||{{#if:{{{subsection|}}}|[[{{#if:{{{subsectionlink|}}}|{{{subsectionlink}}}|{{{subsection}}}}}|{{{subsection}}}]]}}||{{#if:{{{snext|}}}|[[{{#if:{{{snextlink|}}}|{{{snextlink}}}|{{{snext}}}}}|{{{snext}}}]]}}<br />
|}</includeonly><noinclude><br />
==Usage==<br />
This template offers a standardized menu for the page foot. It offers a chapter ''What you have learned'' and a swift shift to the {{rtm}} home page, the chapter home page, the previous and the next section.<br />
===Arguments===<br />
The template has two obligatory and four optional arguments, all of which are named.<br />
*Obligatory<br />
**chapter: the chapter, which the page is assigned to<br />
**lesson: this argument bears the text of the symmary<br />
*Optional<br />
**prev: the name of the previous section. Usually it will be identical with the link to the previous section, so the latter can be left away. As there is not allways a previous section, also prev may be empty.<br />
**next: the name of the previous section. Usually it will be identical with the link to the next section, so the latter can be left away. As there is not allways a next section, also next may be empty.<br />
**prevlink: an argument for the link to the previous section, if it differs from ''prev''.<br />
**prevlink: an argument for the link to the next section, if it differs from ''next''.<br />
==Examples==<br />
<pre>{{navi}}</pre><br />
delivers<br />
<br />
<br />
<br /><br />
<br /><br />
<br /><br />
<br /><br />
<br /><br />
<br /><br />
<br /><br />
{| class="wikitable"<br />
|-<br />
! colspan="4"| What you should have learned<br />
|-<br />
| colspan="4"|Please, enter a summary!<br />
|-<br />
! colspan="4"| Navigation<br />
|-<br />
|'''[[Main_Page|Home]]'''||''←''||''•''||''→''<br />
|-<br />
|''Chapter''||{{#if:|[[{{#if:|{{{pchapterlink}}}|{{{pchapter}}}}}|{{{pchapter}}}]]}}||[[{{#if:|{{{chapterlink}}}|{{{chapter}}}}}|{{{chapter}}}]]||{{#if:|[[{{#if:|{{{nchapterlink}}}|{{{nchapter}}}}}|{{{nchapter}}}]]}}<br />
|-<br />
|''Section''||{{#if:|[[{{#if:|{{{prevlink}}}|{{{prev}}}}}|{{{prev}}}]]}}||[[{{PAGENAME}}]]||{{#if:|[[{{#if:|{{{nextlink}}}|{{{next}}}}}|{{{next}}}]]}}<br />
|-<br />
|''Subection''||{{#if:|[[{{#if:|{{{sprevlink}}}|{{{sprev}}}}}|{{{sprev}}}]]}}||{{#if:|[[{{#if:|{{{subsectionlink}}}|{{{subsection}}}}}|{{{subsection}}}]]}}||{{#if:|[[{{#if:|{{{snextlink}}}|{{{snext}}}}}|{{{snext}}}]]}}<br />
|}<br />
<br />
<pre>{{navi<br />
|lesson=Seid wachsam!<br />
|chapter={{RTM}} modelling concepts<br />
|prev={{RTM}} Quick Start<br />
|next=Borders of {{RTM}}<br />
|chapterlink=RTM modelling concepts<br />
|prevlink=RTM Quick Start<br />
|nextlink=Borders of RTM<br />
|section=<br />
}}</pre><br />
delivers<br />
<br />
<br />
<br /><br />
<br /><br />
<br /><br />
<br /><br />
<br /><br />
<br /><br />
<br /><br />
{| class="wikitable"<br />
|-<br />
! colspan="4"| What you should have learned<br />
|-<br />
| colspan="4"|Seid wachsam!<br />
|-<br />
! colspan="4"| Navigation<br />
|-<br />
|'''[[Main_Page|Home]]'''||''←''||''•''||''→''<br />
|-<br />
|''Chapter''||{{#if:|[[{{#if:|{{{pchapterlink}}}|{{{pchapter}}}}}|{{{pchapter}}}]]}}||[[{{#if:RTM modelling concepts|RTM modelling concepts|{{RTM}} modelling concepts}}|{{RTM}} modelling concepts]]||{{#if:|[[{{#if:|{{{nchapterlink}}}|{{{nchapter}}}}}|{{{nchapter}}}]]}}<br />
|-<br />
|''Section''||{{#if:{{RTM}} Quick Start|[[{{#if:RTM Quick Start|RTM Quick Start|{{RTM}} Quick Start}}|{{RTM}} Quick Start]]}}||||{{#if:Borders of {{RTM}}|[[{{#if:Borders of RTM|Borders of RTM|Borders of {{RTM}}}}|Borders of {{RTM}}]]}}<br />
|-<br />
|''Subection''||{{#if:|[[{{#if:|{{{sprevlink}}}|{{{sprev}}}}}|{{{sprev}}}]]}}||{{#if:|[[{{#if:|{{{subsectionlink}}}|{{{subsection}}}}}|{{{subsection}}}]]}}||{{#if:|[[{{#if:|{{{snextlink}}}|{{{snext}}}}}|{{{snext}}}]]}}<br />
|}<br />
<br />
<pre>{{navi<br />
|lesson=<br />
|chapter={{RTM}} modelling concepts<br />
|chapterlink=RTM modelling concepts<br />
|next=Core elements<br />
|section=<br />
}}</pre><br />
delivers<br />
<br />
<br />
<br /><br />
<br /><br />
<br /><br />
<br /><br />
<br /><br />
<br /><br />
<br /><br />
{| class="wikitable"<br />
|-<br />
! colspan="4"| What you should have learned<br />
|-<br />
| colspan="4"|<br />
|-<br />
! colspan="4"| Navigation<br />
|-<br />
|'''[[Main_Page|Home]]'''||''←''||''•''||''→''<br />
|-<br />
|''Chapter''||{{#if:|[[{{#if:|{{{pchapterlink}}}|{{{pchapter}}}}}|{{{pchapter}}}]]}}||[[{{#if:RTM modelling concepts|RTM modelling concepts|{{RTM}} modelling concepts}}|{{RTM}} modelling concepts]]||{{#if:|[[{{#if:|{{{nchapterlink}}}|{{{nchapter}}}}}|{{{nchapter}}}]]}}<br />
|-<br />
|''Section''||{{#if:|[[{{#if:|{{{prevlink}}}|{{{prev}}}}}|{{{prev}}}]]}}||||{{#if:Core elements|[[{{#if:|{{{nextlink}}}|Core elements}}|Core elements]]}}<br />
|-<br />
|''Subection''||{{#if:|[[{{#if:|{{{sprevlink}}}|{{{sprev}}}}}|{{{sprev}}}]]}}||{{#if:|[[{{#if:|{{{subsectionlink}}}|{{{subsection}}}}}|{{{subsection}}}]]}}||{{#if:|[[{{#if:|{{{snextlink}}}|{{{snext}}}}}|{{{snext}}}]]}}<br />
|}<br />
[[category:contentTemplate]]<br />
</noinclude></div>
Ferri Leberl
http://wiki.railtopomodel.org/index.php?title=Track-referred_positioning&diff=930
Track-referred positioning
2017-03-13T15:43:44Z
<p>Ferri Leberl: Änderung Navi</p>
<hr />
<div>{{Overview|text=Lorem ipsum...}}<br /><br />
<br />
== Traditional Positioning ==<br />
Localization expressed in a linear reference system, generally a coordinate along a predefined axis.<br />
<br />
<gallery><br />
File:AxisLPS.png|Axis for an LPS<br />
</gallery><br />
It could be read as “at coordinate X on the line Y” (being aware that the line Y is composed of many elements).<br /><br />
<br />
In the context of the {{rtm}} traditional positioning systems are either LRS based or based on geometric coordinate systems in their broadest meaning.<br /><br />
LRS based positioning systems are defined by the LinearReferencingMethod, the start measure, the end measure und the units of the measurement.<br /><br />
To describe local anomalies the class “LinearAnchorPoint” is provided. The attribute “measureToNext” allows to modify the basis for the interpolation of location in the interval towards the next “LinearAnchorPoint” instance.<br /><br />
“GeometricPositioningSystem” instances are defined using their Coordinate Reference System definition.<br /><br />
To locate “NetEntity” instances the class “PositioningSystemCoordinate” and the two derived classes “LinearCoordinate” and “GeometricCoordinate” are provided for traditional positioning.<br /><br />
A “LinearCoordinate” instance is defined by the measure, the lateral offset and the vertical offset. The attribute “measure” defines the position at the “line of reference” (possibly adjusted to local anomalies using “LinearAnchorPosition”).<br /><br />
In case the location is not precisely at the “line of reference” the attribute “LateralOffset” allows to define the perpendicular distance to the “line of reference”. Likewise the attribute “verticalOffset” is provided to define heights using the “line of reference” as baseline.<br />
<gallery><br />
File:PositioningSystemsLU.png|Positioning Systems (Language Unit)<br />
File:PositioningSystemsCoordinatesLU.png|Positioning Systems Coordinates (Lamguage Unit) <br />
</gallery><br />
<br />
== Other system ==<br />
<gallery><br />
File:IntrinsicExample2.png|Linear Approach<br />
</gallery><br />
In this case we manage the position of the object with another reference system (linear for instance)<br />
As the relation between the intrinsic and the linear positioning system is known, the translation to intrinsic is computable when (and if) needed.<br /><br />
'''Conclusion'''<br /><br />
In both case the coordinate is known (or computable) either in linear and intrinsic coordinate system. <br /><br />
The second case will be '''preferred''' (but not mandatory) for manually entered data (we manage the object for itself), the first case will be '''preferred''' (but not mandatory) in calculation/calculated data or data transmission (we compute the interactions).<br /><br />
In both case a relation has to be laid between the element (trail in this case) and the positioning system (else you cannot relate objects on this element), but this would be the case whatever the storage method.<br /><br />
<br />
{{navi<br />
|chapter={{RTM}} modelling concepts<br />
|chapterlink=RTM modelling concepts<br />
|prev=Structure<br />
|next=Object positioning in the network<br />
|pchapter={{rtm}} Quick Start<br />
|pchapterlink=RTM Quick Start<br />
|nchapter={{rtm}} External References<br />
|nchapterlink=RTM External References<br />
|section=[[Positioning]]<br />
|subsection=Track-referred positioning<br />
|sprev=Intrinsic positioning / referencing<br />
}}</div>
Ferri Leberl
http://wiki.railtopomodel.org/index.php?title=Intrinsic_positioning_/_referencing&diff=929
Intrinsic positioning / referencing
2017-03-13T15:42:35Z
<p>Ferri Leberl: Änderung Navi</p>
<hr />
<div>{{Overview|text=Lorem ipsum...}}<br /><br />
<br />
The coordinate system associated with each element. In order to be the most generic possible the value 0 is assigned to the start and 1 to the end for a linear element on the network. Nonlinear elements don't need the notion of a number between 0 and 1 since all the segments correspond to the same place on the network: the nonlinear element itself (= 0).<br /><br />
<gallery><br />
File:IntrinsicScale.png|Intrinsic Scale (© RFF/SNCF Réseau)<br />
</gallery><br />
<br />
It could be read as “At coordinate X after the start of the element”.<br />
<br />
[[File:IntrinsicPositioningLU.png|thumbnail|Intrinsic Positioning (Language Unit)]]<br />
A major goal of the {{rtm}} is the precise localisation of all relevant information objects in reference to the network.<br />
The class “PositioningNetElement” describes those building blocks of a “Network” which will be used as an “element of reference” for intrinsic positioning.<br /><br />
Intrinsic positioning in its pure form defines an interval from 0 to 1 for each “PositioningNetElement”. The extent of a “PositioningNetElement” instance in the real world is defined by associated “AssociatedPositioningSystem” instances which define a set of “LinearPositioningSystem” instances used for traditional positioning.<br /><br />
An “AssociatedPositioningSystem” instance possesses a set of “IntrinsicCoordinate” instances. Each “IntrinsicCoordinate” in turn is associated to one or more “PositioningSystemCoordinate” instances.<br /><br />
Together this structure allows to define an ordered list of transformation parameters which can be used to transform traditional LRS location into intrinsic locations and vice versa.<br /><br />
The same principle holds true for traditional geometric locations. An intrinsic location can be geocoded into a geometric coordinate and a geometric coordinate can be reverse geocoded into an intrinisic coordinate.<br /><br />
In principle the intrinsic value range of a given “PositioningNetElement” instance could mimic real world mileages. Considering the possibility of mileage anomalies and changes of the associated “LinearPositioningSystem” somewhere in the middle of the “PositioningNetElement” it is strongly recommended to use the 0 to 1 interval as the value range.<br /><br />
The start of the “PositioningNetElement” is attributed the value “0” whereas the end of the “PositioningNetElement” is attributed the value “1”. Applying this convention each location in reference to PositioningNetElement is expressed as a percentage of the element length starting from the beginning of the element.<br /><br />
Another big advantage is that intrinsic positioning based on 0 to 1 intervals allows algorithms which operate without units.<br /><br />
<br />
Now that the elements have been listed, the next goal is to provide a way to place items on these elements: a referencing system.<br /><br />
As there are a great many referencing methods available, and as the model has to be able to cope with many sources that are using different types of units or reference point, the underlying structure of the model is a unitless and universal method. However, later on means are being added to use any other referencing method, as long as the reference system is described.<br /><br />
<br />
=== Application of intrinsic positioning ===<br />
For linear elements (which have a start, end and length) the position of an information object is expressed as the distance from the start to the application point. To avoid conflicts between different unit types, this distance will be expressed as a percentage of the length of the element. For example, something right in the middle of the element would receive a coordinate of 0.5.<br /><br />
For non-linear elements, all referring positions using intrinsic coordinates will always be at the “start” of the element (coordinate 0, as the element has no length).<br /><br />
<gallery><br />
File:LinearReferencingPrinciple.png|Linear referencing principle (© InfraBel)<br />
File:PositioningAtNode.png|Positioning at a node (© InfraBel)<br />
</gallery><br />
<br />
It implies that an item may be located anywhere “along” a linear element (coordinate ranging from 0 to 1) but only “at” a nonlinear element (coordinate ranging from 0 to 0… that is 0).<br /><br />
<br />
It implies that, in this model, an item may be located anywhere “along” a linear element (coordinate ranging from 0 to 1) but only “at” a nonlinear element (coordinate ranging from 0 to 0… that is 0).<br /><br />
As the applied reference system is universal, any object can be attached to the network with a coordinate “Element, Position”. However, if this reference system is univocal, it is unreadable by a human. A conversion to more widely used coordinate systems will be discussed in the annex to this document.<br /><br />
<br />
[[File:ModelPart2.png|thumbnail|150px|Model Part 2 (© {{rml}})]]<br />
In terms of class diagram, the Generic NetElement class is extended with a class in which the intrinsic coordinate system is defined. The only role of this class is to know that the NetElement is oriented (linear) or not (the role of the CompositionNetElement class will be discussed later on).<br /><br />
While universal and deterministic (no two different locations on the network can point to the same coordinate – no single location on the network can have two coordinates), this referencing system is strictly logical and not human-usable. The link to Geographical/Geometrical or the more widely used Mileage system is part of chapter 6.6 Aggregation. <br /><br />
<br />
One ravel in the environment of a topological change is caused by the intrinsic positioning method.<br /><br />
On events of physical movements of switch(es), buffer stop(s), curves, track geometry all locations on the affected trails (or SoL’s) have to be recalculated.<br /><br />
Even in some cases where the topology is unchanged, recalculations have to be performed for locations which are expressed by intrinsic positioning.<br /><br />
At a second thought, we see the next disadvantages of intrinsic positioning:<br />
* Doubtful accuracy, regardless how many digits behind the digital dot are applied<br />
* Problems with data collection in the above value chain (+ costs)<br />
* The same with data maintenance (+ costs)<br />
* Bad or even impossible use ability in real life (mechanicals/operators) in the field and maintenance of history (at least conversion tool required)<br />
* Permanent recalculation on event of any topological or geometrical or (some) technical changes (conversion tool required).<br />
* Laborious use ability in the flow of the whole value chain with respect to the topological life cycle.<br />
In summary: from 2e bullet to last one: is there any positive business case thinkable? Probably not.<br /><br />
Consequence: the modeling group has to reconsider the utilization of the intrinsic positioning method !!<br />
<br />
'''Reminder:'''<br /><br />
The main purpose of the Intrinsic positioning system is to provide an universal way to store/transmit the position of the '''INTERACTION''' between the network and objects/events. <br /><br />
'''It is thus not intended to manage the (position of the) network/objects themselves.''' <br /><br />
Its accuracy depends on the accuracy of measurement of both interacting elements : the network and the event. Its lack of accuracy is not inherent to the storage method, but more of the accuracy of the measurement methods of each elements. <br /><br />
It is only currently described as the only referencing method because, up to now, we did not describe the objects. When designing the object classes, other referencing methods may (and will) be used as primary system. <br /><br />
It is a calculated value, especially useful when computing. It is thus not intended to be “Read” or “Written” by an human being. It is also not intended to be used in the field by human beings, as most of the time they don’t need to know the interaction between the object and the network, but rather the position of the object itself.<br /><br />
As it is the interaction between two elements, it has indeed to be recalculated as any of those elements changes. And it cannot be otherwise, because if one of the two element changes, the interaction also changes. <br /><br />
However, it only need to be calculated '''when knowing the interaction''' between an object and the network '''is needed''' (or before the transmission of data).<br /><br />
Its advantages are multiple when computing or transmitting data: <br /><br />
* As it is unitless, it can be used to compare/combine data from different sources, only the “Length” property of the carrier object need to be translated, not every relationship.<br />
* It never has to deal with “mileage anomalies”, so designing algorithms is easier and faster.<br />
* The computation algorithms need only be designed one time (and not one for each referencing method / combination of referencing methods).<br />
* Easy validation check ( from 0 to 1, you do not have to check which units are used, you don’t need to convert between m/km, miles/m/yards/feet…).<br />
* No possible errors when positioning relations: it has to be either at 0 or 1 (avoiding possible digit number errors between the length and relation position).<br />
* You can describe a conversion between any system and the intrinsic. If you add a new system, adding a conversion to intrinsic allows the conversion from/to any other system already described.<br />
* The reference system is built independently of the elements, allowing to describe mileage anomalies once for all the elements concerned (as several parallel tracks may share the same reference system, or be valid for more than one level)<br />
=== Application to the model ===<br />
Considering the following elements:<br /><br />
<gallery><br />
File:LinearInstrinsic.png|<br />
</gallery><br />
<br />
We only take spot objects and assume there is no mileage anomaly, in order to keep it simple.<br /><br />
The model allows two possible approaches: <br /><br />
=== Intrinsic ===<br />
<br />
<gallery><br />
File:IntrinsicExample.png|<br />
</gallery><br />
<br />
We manage the intrinsic coordinate for each object: 0.19191919 <br /><br />
As the relation between the intrinsic and the linear reference systems is known, the translation may be done to the linear coordinate system if/when needed.<br /><br />
However, it is not a very user friendly way to manage data that has to be manually entered.<br /><br />
<br />
{{navi<br />
|chapter={{RTM}} modelling concepts<br />
|chapterlink=RTM modelling concepts<br />
|prev=Structure<br />
|next=Object positioning in the network<br />
|pchapter={{rtm}} Quick Start<br />
|pchapterlink=RTM Quick Start<br />
|nchapter={{rtm}} External References<br />
|nchapterlink=RTM External References<br />
|section=[[Positioning]]<br />
|sprev=Return to ''Positioning''<br />
|sprevlink=Positioning<br />
|subsection=Intrinsic positioning / referencing<br />
|snext=Track-referred positioning<br />
}}</div>
Ferri Leberl
http://wiki.railtopomodel.org/index.php?title=Linear_Positioning_/_referencing&diff=928
Linear Positioning / referencing
2017-03-13T15:38:01Z
<p>Ferri Leberl: Änderung Navi</p>
<hr />
<div>'''Linear Positioning / referencing'''<br />
<br />
Linear Referencing Systems (LRS) are widely used in the transportation world. They allow specifying positions along linear elements by using distances measured along the element (possibly with a lateral and horizontal offset), not by using classical 2D or 3D coordinating systems (CRS). <br /><br />
<br />
Locating an object with linear coordinates makes sense for various reasons. First of all, a large amount of information is stored in databases from legacy systems, anterior to geographical information systems which are specifically designed to deal with classical CRS. Knowing where an object is located along a route or a pipeline is sufficient to use the data from those databases, and can be seen as an integration mean for data coming from different sources. <br /><br />
<br />
It is even sometimes more interesting to have a linear position than a spatial position. Knowing that you have train stopped at about the kilometre 45 on the Line 36 Track A is better than having a potentially more accurate GPS position, which does neither tell without ambiguity on which line nor track it stands.<br />
<br />
=== Norms ===<br />
Linear Referencing is the object of the European Norm EN19148:2012. <br /><br />
<br />
The {{rtm}} follows the same principles, but uses a simplified version of the model as a lot of cases foreseen in the norm are not encountered in the railways world.<br />
<br /><br />
=== Axis ===<br />
A linear referencing system has an axis along which the measures are done. The axis can be any linear entity, a track segment or a whole line. It does not need to have geometry as knowing its length is enough to use an LRS.<br />
=== Referencing Methods===<br />
<br />
A Linear Referencing System may use several methods to describe a position along an axis: <br />
* '''Absolute''' : the position is specified by giving the distance starting at the beginning of the axis (with an eventual offset)<br />
<br />
[[File:ReferencingMethods Absolute.png|ReferencingMethodAbsolute]]<br />
<br />
Its main disadvantage is the fact that the whole length of the axis is taken into account when measuring. It means :<br />
# that the field workers always have to begin measurement at the start of the axis. It makes it unpractical for long axes,<br />
# that each change happening in the axis before the referenced object changes the coordinate of the measured point.<br />
It is thus only suitable for short axes, or axes which are very stable in the scope of the measurement. <br />
<br />
*'''Relative''' : The position is specified by giving the distance starting from an element (referent) whose position is known.<br />
<br />
[[File:ReferencingMethods Relative.png|ReferencingMethodRelative]]<br />
<br />
This is the most commonly used in railways, with mileposts as referents. Amongst its advantages is the stability of the coordinate which is now independent from works or axis changes happening before the referent, unless the change also affects the referent.<br /><br />
It is also more practical for the field workers as the measurement only has to start at the referent. <br /><br />
On the other hand, it forces to maintain a whole set of referents, ensuring they never move, and recalculating their position at each infrastructure change.<br /><br />
It makes it most suitable for long axes, such as lines, but poorly adapted to short segments (work reservations or sidings).<br /><br />
<br />
While it is possible to measure in both directions, (km x + y meters or km x+1 – z meters), the former method is the most widely used.<br /><br />
<br />
It is also the most suited to store long term information, because of the stability of the coordinates. However, it is very poorly suited to calculations as true distances are difficult to deduce from the coordinates.<br />
Both methods can include lateral or vertical offsets.<br /><br />
=== Expression of the distance ===<br />
The distance from the start of the measure (be it the start of the axis or the referent) can be expressed in several ways. <br />
*In metres (or miles, or any unit of choice)<br />
*Relative to the length of the element <br />
**As a percentage of the element (0…100 %)<br />
**Normalized (0…1). 75 % being expressed as 0.75<br />
* Hybrid : as a percentage of the length between two successive referents<br />
<br />
===== Hybrid expression =====<br />
The major problem with the relative method of linear referencing is the fact that it cannot be stored as a number when the system has mileage anomalies.<br /><br />
As the distance between two successive referents may be more than one kilometre (or 1000 units), the coordinate needs two fields to be stored. On top of that, not all reference points have a numeric name, a referent 12A might be inserted when lengthening the track between the mileposts 12 and 13.<br /><br />
<br />
The hybrid method aims to deal with this issue by assigning a fixed coordinate to each successive referent (usually a multiple of 1000) and adding the percentage of the distance between the two referents. <br /><br />
While it doesn’t allow true distance measurement, it keeps the sequence of the objects.<br /><br />
<br /><br />
<br />
For example, assuming the distance between the kilometre post 12 and 13 is 1200m and that the object needing to be located is at km 12 + 1050m, <br />
*Kilometre post 12 : coordinate 12000<br />
*Kilometre post 13 : coordinate 13000<br />
Object coordinate : coordinate of the referent (12000)+ percentage of the distance of the object regarding the distance between the referents (1050/1200) multiplied by the difference of coordinates between the two successive referents (1000)<br />
*Object coordinate : 12000 + (1050/1200)*1000 = 12875, which is a number that can be stored in one field and on which operations may be made.<br />
<br />
{{navi<br />
|lesson=<br><br />
* Coordinate reference systems are (besides intrinsic and conventional linear referencing) the third option to define positions/locations in the {{rtm}}.<br />
* All geodetic coordinate reference systems can be defined by a unique identifier: the EPSG code.<br />
* {{rtm}} implementation shall follow concepts of the existing international standard GML. <br />
* Coordinate reference systems can also be used to define schematic coordinates as they are used in terms of screen coordinates.<br />
|chapter={{RTM}} modelling concepts<br />
|chapterlink=RTM modelling concepts<br />
|prev=Structure<br />
|next=Object positioning in the network<br />
|pchapter={{rtm}} Quick Start<br />
|pchapterlink=RTM Quick Start<br />
|nchapter={{rtm}} External References<br />
|nchapterlink=RTM External References<br />
|sprev=Coordinate positioning<br />
|section=[[Positioning]]<br />
|subsection=Linear Positioning / referencing<br />
|snext=Return to ''Positioning''<br />
|snextlink=positioning<br />
}}</div>
Ferri Leberl
http://wiki.railtopomodel.org/index.php?title=Linear_Positioning_/_referencing&diff=927
Linear Positioning / referencing
2017-03-13T15:33:15Z
<p>Ferri Leberl: Änderung Navi</p>
<hr />
<div>'''Linear Positioning / referencing'''<br />
<br />
Linear Referencing Systems (LRS) are widely used in the transportation world. They allow specifying positions along linear elements by using distances measured along the element (possibly with a lateral and horizontal offset), not by using classical 2D or 3D coordinating systems (CRS). <br /><br />
<br />
Locating an object with linear coordinates makes sense for various reasons. First of all, a large amount of information is stored in databases from legacy systems, anterior to geographical information systems which are specifically designed to deal with classical CRS. Knowing where an object is located along a route or a pipeline is sufficient to use the data from those databases, and can be seen as an integration mean for data coming from different sources. <br /><br />
<br />
It is even sometimes more interesting to have a linear position than a spatial position. Knowing that you have train stopped at about the kilometre 45 on the Line 36 Track A is better than having a potentially more accurate GPS position, which does neither tell without ambiguity on which line nor track it stands.<br />
<br />
=== Norms ===<br />
Linear Referencing is the object of the European Norm EN19148:2012. <br /><br />
<br />
The {{rtm}} follows the same principles, but uses a simplified version of the model as a lot of cases foreseen in the norm are not encountered in the railways world.<br />
<br /><br />
=== Axis ===<br />
A linear referencing system has an axis along which the measures are done. The axis can be any linear entity, a track segment or a whole line. It does not need to have geometry as knowing its length is enough to use an LRS.<br />
=== Referencing Methods===<br />
<br />
A Linear Referencing System may use several methods to describe a position along an axis: <br />
* '''Absolute''' : the position is specified by giving the distance starting at the beginning of the axis (with an eventual offset)<br />
<br />
[[File:ReferencingMethods Absolute.png|ReferencingMethodAbsolute]]<br />
<br />
Its main disadvantage is the fact that the whole length of the axis is taken into account when measuring. It means :<br />
# that the field workers always have to begin measurement at the start of the axis. It makes it unpractical for long axes,<br />
# that each change happening in the axis before the referenced object changes the coordinate of the measured point.<br />
It is thus only suitable for short axes, or axes which are very stable in the scope of the measurement. <br />
<br />
*'''Relative''' : The position is specified by giving the distance starting from an element (referent) whose position is known.<br />
<br />
[[File:ReferencingMethods Relative.png|ReferencingMethodRelative]]<br />
<br />
This is the most commonly used in railways, with mileposts as referents. Amongst its advantages is the stability of the coordinate which is now independent from works or axis changes happening before the referent, unless the change also affects the referent.<br /><br />
It is also more practical for the field workers as the measurement only has to start at the referent. <br /><br />
On the other hand, it forces to maintain a whole set of referents, ensuring they never move, and recalculating their position at each infrastructure change.<br /><br />
It makes it most suitable for long axes, such as lines, but poorly adapted to short segments (work reservations or sidings).<br /><br />
<br />
While it is possible to measure in both directions, (km x + y meters or km x+1 – z meters), the former method is the most widely used.<br /><br />
<br />
It is also the most suited to store long term information, because of the stability of the coordinates. However, it is very poorly suited to calculations as true distances are difficult to deduce from the coordinates.<br />
Both methods can include lateral or vertical offsets.<br /><br />
=== Expression of the distance ===<br />
The distance from the start of the measure (be it the start of the axis or the referent) can be expressed in several ways. <br />
*In metres (or miles, or any unit of choice)<br />
*Relative to the length of the element <br />
**As a percentage of the element (0…100 %)<br />
**Normalized (0…1). 75 % being expressed as 0.75<br />
* Hybrid : as a percentage of the length between two successive referents<br />
<br />
===== Hybrid expression =====<br />
The major problem with the relative method of linear referencing is the fact that it cannot be stored as a number when the system has mileage anomalies.<br /><br />
As the distance between two successive referents may be more than one kilometre (or 1000 units), the coordinate needs two fields to be stored. On top of that, not all reference points have a numeric name, a referent 12A might be inserted when lengthening the track between the mileposts 12 and 13.<br /><br />
<br />
The hybrid method aims to deal with this issue by assigning a fixed coordinate to each successive referent (usually a multiple of 1000) and adding the percentage of the distance between the two referents. <br /><br />
While it doesn’t allow true distance measurement, it keeps the sequence of the objects.<br /><br />
<br /><br />
<br />
For example, assuming the distance between the kilometre post 12 and 13 is 1200m and that the object needing to be located is at km 12 + 1050m, <br />
*Kilometre post 12 : coordinate 12000<br />
*Kilometre post 13 : coordinate 13000<br />
Object coordinate : coordinate of the referent (12000)+ percentage of the distance of the object regarding the distance between the referents (1050/1200) multiplied by the difference of coordinates between the two successive referents (1000)<br />
*Object coordinate : 12000 + (1050/1200)*1000 = 12875, which is a number that can be stored in one field and on which operations may be made.<br />
<br />
{{navi<br />
|lesson=<br><br />
* Coordinate reference systems are (besides intrinsic and conventional linear referencing) the third option to define positions/locations in the {{rtm}}.<br />
* All geodetic coordinate reference systems can be defined by a unique identifier: the EPSG code.<br />
* {{rtm}} implementation shall follow concepts of the existing international standard GML. <br />
* Coordinate reference systems can also be used to define schematic coordinates as they are used in terms of screen coordinates.<br />
|chapter={{RTM}} modelling concepts<br />
|chapterlink=RTM modelling concepts<br />
|prev=Structure<br />
<!--|next=Object positioning in the network--><br />
|pchapter={{rtm}} Quick Start<br />
|pchapterlink=RTM Quick Start<br />
<!--|nchapter={{rtm}} External References--><br />
|nchapterlink=RTM External References<br />
|sprev=Coordinate positioning<br />
|section=[[Positioning]]<br />
|subsection=Linear Positioning / referencing<br />
}}</div>
Ferri Leberl
http://wiki.railtopomodel.org/index.php?title=Linear_Positioning_/_referencing&diff=926
Linear Positioning / referencing
2017-03-13T15:31:16Z
<p>Ferri Leberl: navi</p>
<hr />
<div>'''Linear Positioning / referencing'''<br />
<br />
Linear Referencing Systems (LRS) are widely used in the transportation world. They allow specifying positions along linear elements by using distances measured along the element (possibly with a lateral and horizontal offset), not by using classical 2D or 3D coordinating systems (CRS). <br /><br />
<br />
Locating an object with linear coordinates makes sense for various reasons. First of all, a large amount of information is stored in databases from legacy systems, anterior to geographical information systems which are specifically designed to deal with classical CRS. Knowing where an object is located along a route or a pipeline is sufficient to use the data from those databases, and can be seen as an integration mean for data coming from different sources. <br /><br />
<br />
It is even sometimes more interesting to have a linear position than a spatial position. Knowing that you have train stopped at about the kilometre 45 on the Line 36 Track A is better than having a potentially more accurate GPS position, which does neither tell without ambiguity on which line nor track it stands.<br />
<br />
=== Norms ===<br />
Linear Referencing is the object of the European Norm EN19148:2012. <br /><br />
<br />
The {{rtm}} follows the same principles, but uses a simplified version of the model as a lot of cases foreseen in the norm are not encountered in the railways world.<br />
<br /><br />
=== Axis ===<br />
A linear referencing system has an axis along which the measures are done. The axis can be any linear entity, a track segment or a whole line. It does not need to have geometry as knowing its length is enough to use an LRS.<br />
=== Referencing Methods===<br />
<br />
A Linear Referencing System may use several methods to describe a position along an axis: <br />
* '''Absolute''' : the position is specified by giving the distance starting at the beginning of the axis (with an eventual offset)<br />
<br />
[[File:ReferencingMethods Absolute.png|ReferencingMethodAbsolute]]<br />
<br />
Its main disadvantage is the fact that the whole length of the axis is taken into account when measuring. It means :<br />
# that the field workers always have to begin measurement at the start of the axis. It makes it unpractical for long axes,<br />
# that each change happening in the axis before the referenced object changes the coordinate of the measured point.<br />
It is thus only suitable for short axes, or axes which are very stable in the scope of the measurement. <br />
<br />
*'''Relative''' : The position is specified by giving the distance starting from an element (referent) whose position is known.<br />
<br />
[[File:ReferencingMethods Relative.png|ReferencingMethodRelative]]<br />
<br />
This is the most commonly used in railways, with mileposts as referents. Amongst its advantages is the stability of the coordinate which is now independent from works or axis changes happening before the referent, unless the change also affects the referent.<br /><br />
It is also more practical for the field workers as the measurement only has to start at the referent. <br /><br />
On the other hand, it forces to maintain a whole set of referents, ensuring they never move, and recalculating their position at each infrastructure change.<br /><br />
It makes it most suitable for long axes, such as lines, but poorly adapted to short segments (work reservations or sidings).<br /><br />
<br />
While it is possible to measure in both directions, (km x + y meters or km x+1 – z meters), the former method is the most widely used.<br /><br />
<br />
It is also the most suited to store long term information, because of the stability of the coordinates. However, it is very poorly suited to calculations as true distances are difficult to deduce from the coordinates.<br />
Both methods can include lateral or vertical offsets.<br /><br />
=== Expression of the distance ===<br />
The distance from the start of the measure (be it the start of the axis or the referent) can be expressed in several ways. <br />
*In metres (or miles, or any unit of choice)<br />
*Relative to the length of the element <br />
**As a percentage of the element (0…100 %)<br />
**Normalized (0…1). 75 % being expressed as 0.75<br />
* Hybrid : as a percentage of the length between two successive referents<br />
<br />
===== Hybrid expression =====<br />
The major problem with the relative method of linear referencing is the fact that it cannot be stored as a number when the system has mileage anomalies.<br /><br />
As the distance between two successive referents may be more than one kilometre (or 1000 units), the coordinate needs two fields to be stored. On top of that, not all reference points have a numeric name, a referent 12A might be inserted when lengthening the track between the mileposts 12 and 13.<br /><br />
<br />
The hybrid method aims to deal with this issue by assigning a fixed coordinate to each successive referent (usually a multiple of 1000) and adding the percentage of the distance between the two referents. <br /><br />
While it doesn’t allow true distance measurement, it keeps the sequence of the objects.<br /><br />
<br /><br />
<br />
For example, assuming the distance between the kilometre post 12 and 13 is 1200m and that the object needing to be located is at km 12 + 1050m, <br />
*Kilometre post 12 : coordinate 12000<br />
*Kilometre post 13 : coordinate 13000<br />
Object coordinate : coordinate of the referent (12000)+ percentage of the distance of the object regarding the distance between the referents (1050/1200) multiplied by the difference of coordinates between the two successive referents (1000)<br />
*Object coordinate : 12000 + (1050/1200)*1000 = 12875, which is a number that can be stored in one field and on which operations may be made.<br />
<br />
{{navi<br />
|lesson=<br><br />
* Coordinate reference systems are (besides intrinsic and conventional linear referencing) the third option to define positions/locations in the {{rtm}}.<br />
* All geodetic coordinate reference systems can be defined by a unique identifier: the EPSG code.<br />
* {{rtm}} implementation shall follow concepts of the existing international standard GML. <br />
* Coordinate reference systems can also be used to define schematic coordinates as they are used in terms of screen coordinates.<br />
|chapter={{RTM}} modelling concepts<br />
|chapterlink=RTM modelling concepts<br />
|prev=Structure<br />
|next=Object positioning in the network<br />
|pchapter={{rtm}} Quick Start<br />
|pchapterlink=RTM Quick Start<br />
|nchapter={{rtm}} External References<br />
|nchapterlink=RTM External References<br />
|sprev=Coordinate positioning<br />
|section=[[Positioning]]<br />
|subsection=Linear Positioning / referencing<br />
}}</div>
Ferri Leberl
http://wiki.railtopomodel.org/index.php?title=Coordinate_positioning&diff=925
Coordinate positioning
2017-03-13T15:30:12Z
<p>Ferri Leberl: /* Relevant classes in the {{rtm}} */</p>
<hr />
<div>{{Overview|text=This chapter introduces the concept of locating railway infrastructure elements by using coordinate reference systems.}}<br /><br />
<br />
Besides the intrinsic and the conventional linear track-referenced coordinate system, the {{rtm}} also allows to locate railway infrastructure elements using geodetic and geometric coordinate systems. The most known example in this case is the [https://en.wikipedia.org/wiki/World_Geodetic_System World Geodetic System WGS84] that is also used by the Global Navigation Satellite Systems like GPS or GALILEO. However, there is more than one geodetic coordinate system. Thus, the same infrastructure elements can be located with multiple coordinate systems, their correspondence being established in the model.<br /><br />
<gallery><br />
File:GeometricCoordinates.png|Geometric Coordinates (© RFF/SNCF Réseau)<br />
</gallery><br />
<br />
= General =<br />
== Geometric coordinates ==<br />
A geometric coordinate system can either be a projected X, Y, Z coordinate system, or a λ, ϕ, h geodetic coordinate system, or even an X, Y(, Z) schematic plan coordinate system.<br /><br />
It could be read as "at coordinate X, Y, Z in the system [EPSG:xxxxx] [01/06/2014]". More information about the EPSG code as catalogue of geodetic positioning sytems is provided in the next main chapter.<br /><br />
<br />
Geometric coordinates are quite familiar in other models and data exchange formats, too. For implementation, {{rtm}} includes basic concepts for positioning defined within the [https://en.wikipedia.org/wiki/Geography_Markup_Language Geography Markup Language GML].<br />
<br />
== Linear coordinates ==<br />
The model integrates a link between the linear positioning system and the intrinsic positioning system. It supports the "conversion" of an element position associated with a number between 0 and 1 to a kilometric point on its reference system. In the shown example the middle of the track / linear NetElement is referenced with the mileage value of 122 kilometers.<br /><br />
<br />
<gallery><br />
File:ConversionBoard.png|Conversion Board (© RFF/SNCF Réseau)<br />
</gallery><br />
<br />
= EPSG Code =<br />
As there are a number of different coordinate reference systems with different parameter sets available, it is important to identify the coordinate system without ambiguity. The International Association of Oil & Gas Producers set up the EPSG (European Petroleum Survey Group) Geodetic Parameter Registry, which provides a unique code for every coordinate system. The websites http://spatialreference.org/ and http://www.epsg-registry.org/ can be used to obtain an overview about different coordinate systems by their EPSG code.<br />
<br />
== Examples ==<br />
* EPSG code for World Geodetic System WGS84: urn:ogc:def:crs:EPSG::4326<br />
* EPSG code for ETRS89 / ETRS-TM32: urn:ogc:def:crs:EPSG::3044<br />
* EPSG code for the height coordinate system DHHN92: urn:ogc:def:crs:EPSG::5783<br />
<br />
= Relevant classes in the {{rtm}} =<br />
The classes, used to define the location and positioning systems and their coordinates, are:<br />
* '''PositioningSystem''': This class defines the general concept of a Coordinate Reference System used for positioning.<br />
* '''LinearPositioningSystem''': This class defines a Linear Referencing System. It defines a start and an end coordinate.<br />
* '''LinearAnchorPoints''': this class describes the reference points within the linear reference system (Milestones, anomaly points like gaps and overlaps...) and their characteristics.<br />
* '''LinearCoordinate''': This class is used for providing a location expressed in a Linear Reference System (LRS).<br />
* '''GeometricPositioningSystem''': This class defines a Geometrical Reference System, so it allows to locate a resource with its geometrical coordinates (x, y, z or λ, ϕ, h). The class provides the parameter ''crsDefinition'' to define the Coordinate Reference System. This parameter shall be used to name the EPSG code and thus define all the relevant parameters of the coordinate system.<br />
* '''GeometricCoordinate''': This class defines the localization expressed in a geometrical (or geographical) Reference System, so it defines the coordinates (x, y, z or λ, ϕ, h).<br />
* '''PositioningSystemCoordinate''': This class represents a coordinate in either a geometric or linear reference system.<br />
* '''IntrinsicCoordinate''': This class allows associating an intrinsic coordinate coming from the topology network to another coordinate, either geographic or linear.<br />
* '''AssociatedPositioningSystem''': This class allows to group couples of coordinates to define the translation parameters between an external (geometric or linear) coordinate system and the element’s intrinsic coordinate system.<br />
<br />
{{navi<br />
|lesson=<br><br />
* Coordinate reference systems are (besides intrinsic and conventional linear referencing) the third option to define positions/locations in the {{rtm}}.<br />
* All geodetic coordinate reference systems can be defined by a unique identifier: the EPSG code.<br />
* {{rtm}} implementation shall follow concepts of the existing international standard GML. <br />
* Coordinate reference systems can also be used to define schematic coordinates as they are used in terms of screen coordinates.<br />
|chapter={{RTM}} modelling concepts<br />
|chapterlink=RTM modelling concepts<br />
|prev=Structure<br />
|next=Object positioning in the network<br />
|pchapter={{rtm}} Quick Start<br />
|pchapterlink=RTM Quick Start<br />
|nchapter={{rtm}} External References<br />
|nchapterlink=RTM External References<br />
|subsection=Coordinate positioning<br />
|section=[[Positioning]]<br />
|snext=Linear Positioning / referencing<br />
}}</div>
Ferri Leberl
http://wiki.railtopomodel.org/index.php?title=Linear_Positioning_/_referencing&diff=924
Linear Positioning / referencing
2017-03-13T15:28:16Z
<p>Ferri Leberl: typo</p>
<hr />
<div>'''Linear Positioning / referencing'''<br />
<br />
Linear Referencing Systems (LRS) are widely used in the transportation world. They allow specifying positions along linear elements by using distances measured along the element (possibly with a lateral and horizontal offset), not by using classical 2D or 3D coordinating systems (CRS). <br /><br />
<br />
Locating an object with linear coordinates makes sense for various reasons. First of all, a large amount of information is stored in databases from legacy systems, anterior to geographical information systems which are specifically designed to deal with classical CRS. Knowing where an object is located along a route or a pipeline is sufficient to use the data from those databases, and can be seen as an integration mean for data coming from different sources. <br /><br />
<br />
It is even sometimes more interesting to have a linear position than a spatial position. Knowing that you have train stopped at about the kilometre 45 on the Line 36 Track A is better than having a potentially more accurate GPS position, which does neither tell without ambiguity on which line nor track it stands.<br />
<br />
=== Norms ===<br />
Linear Referencing is the object of the European Norm EN19148:2012. <br /><br />
<br />
The {{rtm}} follows the same principles, but uses a simplified version of the model as a lot of cases foreseen in the norm are not encountered in the railways world.<br />
<br /><br />
=== Axis ===<br />
A linear referencing system has an axis along which the measures are done. The axis can be any linear entity, a track segment or a whole line. It does not need to have geometry as knowing its length is enough to use an LRS.<br />
=== Referencing Methods===<br />
<br />
A Linear Referencing System may use several methods to describe a position along an axis: <br />
* '''Absolute''' : the position is specified by giving the distance starting at the beginning of the axis (with an eventual offset)<br />
<br />
[[File:ReferencingMethods Absolute.png|ReferencingMethodAbsolute]]<br />
<br />
Its main disadvantage is the fact that the whole length of the axis is taken into account when measuring. It means :<br />
# that the field workers always have to begin measurement at the start of the axis. It makes it unpractical for long axes,<br />
# that each change happening in the axis before the referenced object changes the coordinate of the measured point.<br />
It is thus only suitable for short axes, or axes which are very stable in the scope of the measurement. <br />
<br />
*'''Relative''' : The position is specified by giving the distance starting from an element (referent) whose position is known.<br />
<br />
[[File:ReferencingMethods Relative.png|ReferencingMethodRelative]]<br />
<br />
This is the most commonly used in railways, with mileposts as referents. Amongst its advantages is the stability of the coordinate which is now independent from works or axis changes happening before the referent, unless the change also affects the referent.<br /><br />
It is also more practical for the field workers as the measurement only has to start at the referent. <br /><br />
On the other hand, it forces to maintain a whole set of referents, ensuring they never move, and recalculating their position at each infrastructure change.<br /><br />
It makes it most suitable for long axes, such as lines, but poorly adapted to short segments (work reservations or sidings).<br /><br />
<br />
While it is possible to measure in both directions, (km x + y meters or km x+1 – z meters), the former method is the most widely used.<br /><br />
<br />
It is also the most suited to store long term information, because of the stability of the coordinates. However, it is very poorly suited to calculations as true distances are difficult to deduce from the coordinates.<br />
Both methods can include lateral or vertical offsets.<br /><br />
=== Expression of the distance ===<br />
The distance from the start of the measure (be it the start of the axis or the referent) can be expressed in several ways. <br />
*In metres (or miles, or any unit of choice)<br />
*Relative to the length of the element <br />
**As a percentage of the element (0…100 %)<br />
**Normalized (0…1). 75 % being expressed as 0.75<br />
* Hybrid : as a percentage of the length between two successive referents<br />
<br />
===== Hybrid expression =====<br />
The major problem with the relative method of linear referencing is the fact that it cannot be stored as a number when the system has mileage anomalies.<br /><br />
As the distance between two successive referents may be more than one kilometre (or 1000 units), the coordinate needs two fields to be stored. On top of that, not all reference points have a numeric name, a referent 12A might be inserted when lengthening the track between the mileposts 12 and 13.<br /><br />
<br />
The hybrid method aims to deal with this issue by assigning a fixed coordinate to each successive referent (usually a multiple of 1000) and adding the percentage of the distance between the two referents. <br /><br />
While it doesn’t allow true distance measurement, it keeps the sequence of the objects.<br /><br />
<br /><br />
<br />
For example, assuming the distance between the kilometre post 12 and 13 is 1200m and that the object needing to be located is at km 12 + 1050m, <br />
*Kilometre post 12 : coordinate 12000<br />
*Kilometre post 13 : coordinate 13000<br />
Object coordinate : coordinate of the referent (12000)+ percentage of the distance of the object regarding the distance between the referents (1050/1200) multiplied by the difference of coordinates between the two successive referents (1000)<br />
*Object coordinate : 12000 + (1050/1200)*1000 = 12875, which is a number that can be stored in one field and on which operations may be made.</div>
Ferri Leberl
http://wiki.railtopomodel.org/index.php?title=Linear_Positioning_/_referencing&diff=923
Linear Positioning / referencing
2017-03-13T15:27:54Z
<p>Ferri Leberl: title</p>
<hr />
<div>'''Linear Positioning / referencing''<br />
<br />
Linear Referencing Systems (LRS) are widely used in the transportation world. They allow specifying positions along linear elements by using distances measured along the element (possibly with a lateral and horizontal offset), not by using classical 2D or 3D coordinating systems (CRS). <br /><br />
<br />
Locating an object with linear coordinates makes sense for various reasons. First of all, a large amount of information is stored in databases from legacy systems, anterior to geographical information systems which are specifically designed to deal with classical CRS. Knowing where an object is located along a route or a pipeline is sufficient to use the data from those databases, and can be seen as an integration mean for data coming from different sources. <br /><br />
<br />
It is even sometimes more interesting to have a linear position than a spatial position. Knowing that you have train stopped at about the kilometre 45 on the Line 36 Track A is better than having a potentially more accurate GPS position, which does neither tell without ambiguity on which line nor track it stands.<br />
<br />
=== Norms ===<br />
Linear Referencing is the object of the European Norm EN19148:2012. <br /><br />
<br />
The {{rtm}} follows the same principles, but uses a simplified version of the model as a lot of cases foreseen in the norm are not encountered in the railways world.<br />
<br /><br />
=== Axis ===<br />
A linear referencing system has an axis along which the measures are done. The axis can be any linear entity, a track segment or a whole line. It does not need to have geometry as knowing its length is enough to use an LRS.<br />
=== Referencing Methods===<br />
<br />
A Linear Referencing System may use several methods to describe a position along an axis: <br />
* '''Absolute''' : the position is specified by giving the distance starting at the beginning of the axis (with an eventual offset)<br />
<br />
[[File:ReferencingMethods Absolute.png|ReferencingMethodAbsolute]]<br />
<br />
Its main disadvantage is the fact that the whole length of the axis is taken into account when measuring. It means :<br />
# that the field workers always have to begin measurement at the start of the axis. It makes it unpractical for long axes,<br />
# that each change happening in the axis before the referenced object changes the coordinate of the measured point.<br />
It is thus only suitable for short axes, or axes which are very stable in the scope of the measurement. <br />
<br />
*'''Relative''' : The position is specified by giving the distance starting from an element (referent) whose position is known.<br />
<br />
[[File:ReferencingMethods Relative.png|ReferencingMethodRelative]]<br />
<br />
This is the most commonly used in railways, with mileposts as referents. Amongst its advantages is the stability of the coordinate which is now independent from works or axis changes happening before the referent, unless the change also affects the referent.<br /><br />
It is also more practical for the field workers as the measurement only has to start at the referent. <br /><br />
On the other hand, it forces to maintain a whole set of referents, ensuring they never move, and recalculating their position at each infrastructure change.<br /><br />
It makes it most suitable for long axes, such as lines, but poorly adapted to short segments (work reservations or sidings).<br /><br />
<br />
While it is possible to measure in both directions, (km x + y meters or km x+1 – z meters), the former method is the most widely used.<br /><br />
<br />
It is also the most suited to store long term information, because of the stability of the coordinates. However, it is very poorly suited to calculations as true distances are difficult to deduce from the coordinates.<br />
Both methods can include lateral or vertical offsets.<br /><br />
=== Expression of the distance ===<br />
The distance from the start of the measure (be it the start of the axis or the referent) can be expressed in several ways. <br />
*In metres (or miles, or any unit of choice)<br />
*Relative to the length of the element <br />
**As a percentage of the element (0…100 %)<br />
**Normalized (0…1). 75 % being expressed as 0.75<br />
* Hybrid : as a percentage of the length between two successive referents<br />
<br />
===== Hybrid expression =====<br />
The major problem with the relative method of linear referencing is the fact that it cannot be stored as a number when the system has mileage anomalies.<br /><br />
As the distance between two successive referents may be more than one kilometre (or 1000 units), the coordinate needs two fields to be stored. On top of that, not all reference points have a numeric name, a referent 12A might be inserted when lengthening the track between the mileposts 12 and 13.<br /><br />
<br />
The hybrid method aims to deal with this issue by assigning a fixed coordinate to each successive referent (usually a multiple of 1000) and adding the percentage of the distance between the two referents. <br /><br />
While it doesn’t allow true distance measurement, it keeps the sequence of the objects.<br /><br />
<br /><br />
<br />
For example, assuming the distance between the kilometre post 12 and 13 is 1200m and that the object needing to be located is at km 12 + 1050m, <br />
*Kilometre post 12 : coordinate 12000<br />
*Kilometre post 13 : coordinate 13000<br />
Object coordinate : coordinate of the referent (12000)+ percentage of the distance of the object regarding the distance between the referents (1050/1200) multiplied by the difference of coordinates between the two successive referents (1000)<br />
*Object coordinate : 12000 + (1050/1200)*1000 = 12875, which is a number that can be stored in one field and on which operations may be made.</div>
Ferri Leberl
http://wiki.railtopomodel.org/index.php?title=Linear_Positioning_/_referencing&diff=922
Linear Positioning / referencing
2017-03-13T15:27:01Z
<p>Ferri Leberl: Auslagerung</p>
<hr />
<div>Linear Referencing Systems (LRS) are widely used in the transportation world. They allow specifying positions along linear elements by using distances measured along the element (possibly with a lateral and horizontal offset), not by using classical 2D or 3D coordinating systems (CRS). <br /><br />
<br />
Locating an object with linear coordinates makes sense for various reasons. First of all, a large amount of information is stored in databases from legacy systems, anterior to geographical information systems which are specifically designed to deal with classical CRS. Knowing where an object is located along a route or a pipeline is sufficient to use the data from those databases, and can be seen as an integration mean for data coming from different sources. <br /><br />
<br />
It is even sometimes more interesting to have a linear position than a spatial position. Knowing that you have train stopped at about the kilometre 45 on the Line 36 Track A is better than having a potentially more accurate GPS position, which does neither tell without ambiguity on which line nor track it stands.<br />
<br />
=== Norms ===<br />
Linear Referencing is the object of the European Norm EN19148:2012. <br /><br />
<br />
The {{rtm}} follows the same principles, but uses a simplified version of the model as a lot of cases foreseen in the norm are not encountered in the railways world.<br />
<br /><br />
=== Axis ===<br />
A linear referencing system has an axis along which the measures are done. The axis can be any linear entity, a track segment or a whole line. It does not need to have geometry as knowing its length is enough to use an LRS.<br />
=== Referencing Methods===<br />
<br />
A Linear Referencing System may use several methods to describe a position along an axis: <br />
* '''Absolute''' : the position is specified by giving the distance starting at the beginning of the axis (with an eventual offset)<br />
<br />
[[File:ReferencingMethods Absolute.png|ReferencingMethodAbsolute]]<br />
<br />
Its main disadvantage is the fact that the whole length of the axis is taken into account when measuring. It means :<br />
# that the field workers always have to begin measurement at the start of the axis. It makes it unpractical for long axes,<br />
# that each change happening in the axis before the referenced object changes the coordinate of the measured point.<br />
It is thus only suitable for short axes, or axes which are very stable in the scope of the measurement. <br />
<br />
*'''Relative''' : The position is specified by giving the distance starting from an element (referent) whose position is known.<br />
<br />
[[File:ReferencingMethods Relative.png|ReferencingMethodRelative]]<br />
<br />
This is the most commonly used in railways, with mileposts as referents. Amongst its advantages is the stability of the coordinate which is now independent from works or axis changes happening before the referent, unless the change also affects the referent.<br /><br />
It is also more practical for the field workers as the measurement only has to start at the referent. <br /><br />
On the other hand, it forces to maintain a whole set of referents, ensuring they never move, and recalculating their position at each infrastructure change.<br /><br />
It makes it most suitable for long axes, such as lines, but poorly adapted to short segments (work reservations or sidings).<br /><br />
<br />
While it is possible to measure in both directions, (km x + y meters or km x+1 – z meters), the former method is the most widely used.<br /><br />
<br />
It is also the most suited to store long term information, because of the stability of the coordinates. However, it is very poorly suited to calculations as true distances are difficult to deduce from the coordinates.<br />
Both methods can include lateral or vertical offsets.<br /><br />
=== Expression of the distance ===<br />
The distance from the start of the measure (be it the start of the axis or the referent) can be expressed in several ways. <br />
*In metres (or miles, or any unit of choice)<br />
*Relative to the length of the element <br />
**As a percentage of the element (0…100 %)<br />
**Normalized (0…1). 75 % being expressed as 0.75<br />
* Hybrid : as a percentage of the length between two successive referents<br />
<br />
===== Hybrid expression =====<br />
The major problem with the relative method of linear referencing is the fact that it cannot be stored as a number when the system has mileage anomalies.<br /><br />
As the distance between two successive referents may be more than one kilometre (or 1000 units), the coordinate needs two fields to be stored. On top of that, not all reference points have a numeric name, a referent 12A might be inserted when lengthening the track between the mileposts 12 and 13.<br /><br />
<br />
The hybrid method aims to deal with this issue by assigning a fixed coordinate to each successive referent (usually a multiple of 1000) and adding the percentage of the distance between the two referents. <br /><br />
While it doesn’t allow true distance measurement, it keeps the sequence of the objects.<br /><br />
<br /><br />
<br />
For example, assuming the distance between the kilometre post 12 and 13 is 1200m and that the object needing to be located is at km 12 + 1050m, <br />
*Kilometre post 12 : coordinate 12000<br />
*Kilometre post 13 : coordinate 13000<br />
Object coordinate : coordinate of the referent (12000)+ percentage of the distance of the object regarding the distance between the referents (1050/1200) multiplied by the difference of coordinates between the two successive referents (1000)<br />
*Object coordinate : 12000 + (1050/1200)*1000 = 12875, which is a number that can be stored in one field and on which operations may be made.</div>
Ferri Leberl
http://wiki.railtopomodel.org/index.php?title=Positioning&diff=921
Positioning
2017-03-13T15:26:34Z
<p>Ferri Leberl: /* Linear Positioning / referencing */</p>
<hr />
<div>== Coordinate positioning ==<br />
{{main|Coordinate positioning}}<br />
<br />
== Linear Positioning / referencing ==<br />
{{main|Linear Positioning / referencing}}<br />
<br />
= {{rtm}} structure=<br />
As the railways world uses the most suited LR method according to the case, and that the aim of {{rtm}} is to design a universal way of describing railways, it was chosen to split the reference system into two kinds:<br />
*The NetElement’s internal way of measuring is a normalized absolute LRS. The NetElement with its own internal LRS (which we called “Intrinsic Positioning System” as it is proper to the NetElement, created and destroyed with it) becomes a “PositioningNetElement”<br />
*External linear referencing systems (such as the line/milepost) may be attached to the PositioningNetElement by linking a set of external LRS coordinates to the corresponding intrinsic coordinates.<br />
Choosing a universal LRS allows designing location algorithms independently from the field situation which would decide the most practical LR method for a specific segment.<br />
== Intrinsic positioning / referencing ==<br />
{{main|Intrinsic positioning / referencing}}<br />
As said above, each NetElement forming the network has its own linear referencing system, which is created at the same time as the NetElement and destroyed with it. <br />
The purpose of this referencing system is double: <br />
*It ensures that every NetElement has a reference system allowing to locate events on it; small track elements (e.g. work reservations or side tracks) are often not linked to any “major” linear systems such as lines)<br />
*It ensures that every NetElement has an orientation and a length. This allows to locate other NetElements relatively to it (e.g. this switch is at the beginning of this track element)<br />
<br />
The reason why it was decided to use a normalized absolute LRS is that the normalized expression allows designing algorithms which are disconnected from the unit system. Some distances may be expressed in kilometres, miles, centimetres or feet. The normalized notation (0…1) allows to deal separately with the unit conversions.<br /><br />
Also, as it is applied to the smallest element of the network (at a given level), it can be used for locating objects in any path drawn on the network topology, whatever its length or its links with external referencing systems are (path crossing two lines).<br /><br />
Although very difficult to interpret in human interaction, it is perfectly adapted for computer calculations.<br />
<br />
== Track-referred positioning ==<br />
{{main|Track-referred positioning}}<br />
As the intrinsic coordinate system is difficult to use in human exchanges, field workers often use the classical linear referencing with line number, kilometre reference and distance from the post when dealing with long axis or metres from the start when dealing with short axis. <br /><br />
Those referencing systems can be linked with any relevant PositioningNetElement, ensuring the ability to translate the coordinates into an intrinsic coordinate and back. Any number of external reference systems can be linked to an element and an external reference system may of course be linked with several elements.<br />
<br />
{{navi<br />
|chapter={{RTM}} modelling concepts<br />
|chapterlink=RTM modelling concepts<br />
|prev=Structure<br />
|next=Object positioning in the network<br />
|pchapter={{rtm}} Quick Start<br />
|pchapterlink=RTM Quick Start<br />
|nchapter={{rtm}} External References<br />
|nchapterlink=RTM External References<br />
|snext=Coordinate positioning<br />
}}</div>
Ferri Leberl
http://wiki.railtopomodel.org/index.php?title=Talk:Main_Page&diff=920
Talk:Main Page
2017-03-13T15:14:47Z
<p>Ferri Leberl: Missing contents actualized</p>
<hr />
<div>==State as of March 13 2017==<br />
===incomplete===<br />
* [[Connexity graph]]<br />
===empty===<br />
* [[Netherlands: ProRail data base]]<br />
===discarded?===<br />
* [[How To Read]]<br />
* [[Transport mode borders]]<br />
* [[Geographical borders]]<br />
* [[Meta Data / Quality data]]<br />
* [[Inner track geometry (track alignment)]]<br />
* [[ETCS]]<br />
* [[RTM Model Extensions]]<br />
==State as of April 14 2016==<br />
Pages with missing content:<br />
* [[How To Read]]<br />
* [[Connexity graph]]<br />
* [[Transport mode borders]]<br />
* [[Geographical borders]]<br />
* [[Netherlands: ProRail data base]]<br />
* [[Meta Data / Quality data]]<br />
* [[Inner track geometry (track alignment)]]<br />
* [[ETCS]]<br />
<br />
Every "Overview" page needs a rough summary to show what the linked pages are about.</div>
Ferri Leberl
http://wiki.railtopomodel.org/index.php?title=Positioning&diff=919
Positioning
2017-03-13T15:07:33Z
<p>Ferri Leberl: /* Intrinsic positioning / referencing */ {{main</p>
<hr />
<div>== Coordinate positioning ==<br />
{{main|Coordinate positioning}}<br />
<br />
== Linear Positioning / referencing ==<br />
Linear Referencing Systems (LRS) are widely used in the transportation world. They allow specifying positions along linear elements by using distances measured along the element (possibly with a lateral and horizontal offset), not by using classical 2D or 3D coordinating systems (CRS). <br /><br />
<br />
Locating an object with linear coordinates makes sense for various reasons. First of all, a large amount of information is stored in databases from legacy systems, anterior to geographical information systems which are specifically designed to deal with classical CRS. Knowing where an object is located along a route or a pipeline is sufficient to use the data from those databases, and can be seen as an integration mean for data coming from different sources. <br /><br />
<br />
It is even sometimes more interesting to have a linear position than a spatial position. Knowing that you have train stopped at about the kilometre 45 on the Line 36 Track A is better than having a potentially more accurate GPS position, which does neither tell without ambiguity on which line nor track it stands.<br />
<br />
=== Norms ===<br />
Linear Referencing is the object of the European Norm EN19148:2012. <br /><br />
<br />
The {{rtm}} follows the same principles, but uses a simplified version of the model as a lot of cases foreseen in the norm are not encountered in the railways world.<br />
<br /><br />
=== Axis ===<br />
A linear referencing system has an axis along which the measures are done. The axis can be any linear entity, a track segment or a whole line. It does not need to have geometry as knowing its length is enough to use an LRS.<br />
=== Referencing Methods===<br />
<br />
A Linear Referencing System may use several methods to describe a position along an axis: <br />
* '''Absolute''' : the position is specified by giving the distance starting at the beginning of the axis (with an eventual offset)<br />
<br />
[[File:ReferencingMethods Absolute.png|ReferencingMethodAbsolute]]<br />
<br />
Its main disadvantage is the fact that the whole length of the axis is taken into account when measuring. It means :<br />
# that the field workers always have to begin measurement at the start of the axis. It makes it unpractical for long axes,<br />
# that each change happening in the axis before the referenced object changes the coordinate of the measured point.<br />
It is thus only suitable for short axes, or axes which are very stable in the scope of the measurement. <br />
<br />
*'''Relative''' : The position is specified by giving the distance starting from an element (referent) whose position is known.<br />
<br />
[[File:ReferencingMethods Relative.png|ReferencingMethodRelative]]<br />
<br />
This is the most commonly used in railways, with mileposts as referents. Amongst its advantages is the stability of the coordinate which is now independent from works or axis changes happening before the referent, unless the change also affects the referent.<br /><br />
It is also more practical for the field workers as the measurement only has to start at the referent. <br /><br />
On the other hand, it forces to maintain a whole set of referents, ensuring they never move, and recalculating their position at each infrastructure change.<br /><br />
It makes it most suitable for long axes, such as lines, but poorly adapted to short segments (work reservations or sidings).<br /><br />
<br />
While it is possible to measure in both directions, (km x + y meters or km x+1 – z meters), the former method is the most widely used.<br /><br />
<br />
It is also the most suited to store long term information, because of the stability of the coordinates. However, it is very poorly suited to calculations as true distances are difficult to deduce from the coordinates.<br />
Both methods can include lateral or vertical offsets.<br /><br />
=== Expression of the distance ===<br />
The distance from the start of the measure (be it the start of the axis or the referent) can be expressed in several ways. <br />
*In metres (or miles, or any unit of choice)<br />
*Relative to the length of the element <br />
**As a percentage of the element (0…100 %)<br />
**Normalized (0…1). 75 % being expressed as 0.75<br />
* Hybrid : as a percentage of the length between two successive referents<br />
<br />
===== Hybrid expression =====<br />
The major problem with the relative method of linear referencing is the fact that it cannot be stored as a number when the system has mileage anomalies.<br /><br />
As the distance between two successive referents may be more than one kilometre (or 1000 units), the coordinate needs two fields to be stored. On top of that, not all reference points have a numeric name, a referent 12A might be inserted when lengthening the track between the mileposts 12 and 13.<br /><br />
<br />
The hybrid method aims to deal with this issue by assigning a fixed coordinate to each successive referent (usually a multiple of 1000) and adding the percentage of the distance between the two referents. <br /><br />
While it doesn’t allow true distance measurement, it keeps the sequence of the objects.<br /><br />
<br /><br />
<br />
For example, assuming the distance between the kilometre post 12 and 13 is 1200m and that the object needing to be located is at km 12 + 1050m, <br />
*Kilometre post 12 : coordinate 12000<br />
*Kilometre post 13 : coordinate 13000<br />
Object coordinate : coordinate of the referent (12000)+ percentage of the distance of the object regarding the distance between the referents (1050/1200) multiplied by the difference of coordinates between the two successive referents (1000)<br />
*Object coordinate : 12000 + (1050/1200)*1000 = 12875, which is a number that can be stored in one field and on which operations may be made. <br />
<br />
= {{rtm}} structure=<br />
As the railways world uses the most suited LR method according to the case, and that the aim of {{rtm}} is to design a universal way of describing railways, it was chosen to split the reference system into two kinds:<br />
*The NetElement’s internal way of measuring is a normalized absolute LRS. The NetElement with its own internal LRS (which we called “Intrinsic Positioning System” as it is proper to the NetElement, created and destroyed with it) becomes a “PositioningNetElement”<br />
*External linear referencing systems (such as the line/milepost) may be attached to the PositioningNetElement by linking a set of external LRS coordinates to the corresponding intrinsic coordinates.<br />
Choosing a universal LRS allows designing location algorithms independently from the field situation which would decide the most practical LR method for a specific segment.<br />
== Intrinsic positioning / referencing ==<br />
{{main|Intrinsic positioning / referencing}}<br />
As said above, each NetElement forming the network has its own linear referencing system, which is created at the same time as the NetElement and destroyed with it. <br />
The purpose of this referencing system is double: <br />
*It ensures that every NetElement has a reference system allowing to locate events on it; small track elements (e.g. work reservations or side tracks) are often not linked to any “major” linear systems such as lines)<br />
*It ensures that every NetElement has an orientation and a length. This allows to locate other NetElements relatively to it (e.g. this switch is at the beginning of this track element)<br />
<br />
The reason why it was decided to use a normalized absolute LRS is that the normalized expression allows designing algorithms which are disconnected from the unit system. Some distances may be expressed in kilometres, miles, centimetres or feet. The normalized notation (0…1) allows to deal separately with the unit conversions.<br /><br />
Also, as it is applied to the smallest element of the network (at a given level), it can be used for locating objects in any path drawn on the network topology, whatever its length or its links with external referencing systems are (path crossing two lines).<br /><br />
Although very difficult to interpret in human interaction, it is perfectly adapted for computer calculations.<br />
<br />
== Track-referred positioning ==<br />
{{main|Track-referred positioning}}<br />
As the intrinsic coordinate system is difficult to use in human exchanges, field workers often use the classical linear referencing with line number, kilometre reference and distance from the post when dealing with long axis or metres from the start when dealing with short axis. <br /><br />
Those referencing systems can be linked with any relevant PositioningNetElement, ensuring the ability to translate the coordinates into an intrinsic coordinate and back. Any number of external reference systems can be linked to an element and an external reference system may of course be linked with several elements.<br />
<br />
{{navi<br />
|chapter={{RTM}} modelling concepts<br />
|chapterlink=RTM modelling concepts<br />
|prev=Structure<br />
|next=Object positioning in the network<br />
|pchapter={{rtm}} Quick Start<br />
|pchapterlink=RTM Quick Start<br />
|nchapter={{rtm}} External References<br />
|nchapterlink=RTM External References<br />
|snext=Coordinate positioning<br />
}}</div>
Ferri Leberl
http://wiki.railtopomodel.org/index.php?title=Intrinsic_positioning_/_referencing&diff=918
Intrinsic positioning / referencing
2017-03-13T15:06:27Z
<p>Ferri Leberl: </p>
<hr />
<div>{{Overview|text=Lorem ipsum...}}<br /><br />
<br />
The coordinate system associated with each element. In order to be the most generic possible the value 0 is assigned to the start and 1 to the end for a linear element on the network. Nonlinear elements don't need the notion of a number between 0 and 1 since all the segments correspond to the same place on the network: the nonlinear element itself (= 0).<br /><br />
<gallery><br />
File:IntrinsicScale.png|Intrinsic Scale (© RFF/SNCF Réseau)<br />
</gallery><br />
<br />
It could be read as “At coordinate X after the start of the element”.<br />
<br />
[[File:IntrinsicPositioningLU.png|thumbnail|Intrinsic Positioning (Language Unit)]]<br />
A major goal of the {{rtm}} is the precise localisation of all relevant information objects in reference to the network.<br />
The class “PositioningNetElement” describes those building blocks of a “Network” which will be used as an “element of reference” for intrinsic positioning.<br /><br />
Intrinsic positioning in its pure form defines an interval from 0 to 1 for each “PositioningNetElement”. The extent of a “PositioningNetElement” instance in the real world is defined by associated “AssociatedPositioningSystem” instances which define a set of “LinearPositioningSystem” instances used for traditional positioning.<br /><br />
An “AssociatedPositioningSystem” instance possesses a set of “IntrinsicCoordinate” instances. Each “IntrinsicCoordinate” in turn is associated to one or more “PositioningSystemCoordinate” instances.<br /><br />
Together this structure allows to define an ordered list of transformation parameters which can be used to transform traditional LRS location into intrinsic locations and vice versa.<br /><br />
The same principle holds true for traditional geometric locations. An intrinsic location can be geocoded into a geometric coordinate and a geometric coordinate can be reverse geocoded into an intrinisic coordinate.<br /><br />
In principle the intrinsic value range of a given “PositioningNetElement” instance could mimic real world mileages. Considering the possibility of mileage anomalies and changes of the associated “LinearPositioningSystem” somewhere in the middle of the “PositioningNetElement” it is strongly recommended to use the 0 to 1 interval as the value range.<br /><br />
The start of the “PositioningNetElement” is attributed the value “0” whereas the end of the “PositioningNetElement” is attributed the value “1”. Applying this convention each location in reference to PositioningNetElement is expressed as a percentage of the element length starting from the beginning of the element.<br /><br />
Another big advantage is that intrinsic positioning based on 0 to 1 intervals allows algorithms which operate without units.<br /><br />
<br />
Now that the elements have been listed, the next goal is to provide a way to place items on these elements: a referencing system.<br /><br />
As there are a great many referencing methods available, and as the model has to be able to cope with many sources that are using different types of units or reference point, the underlying structure of the model is a unitless and universal method. However, later on means are being added to use any other referencing method, as long as the reference system is described.<br /><br />
<br />
=== Application of intrinsic positioning ===<br />
For linear elements (which have a start, end and length) the position of an information object is expressed as the distance from the start to the application point. To avoid conflicts between different unit types, this distance will be expressed as a percentage of the length of the element. For example, something right in the middle of the element would receive a coordinate of 0.5.<br /><br />
For non-linear elements, all referring positions using intrinsic coordinates will always be at the “start” of the element (coordinate 0, as the element has no length).<br /><br />
<gallery><br />
File:LinearReferencingPrinciple.png|Linear referencing principle (© InfraBel)<br />
File:PositioningAtNode.png|Positioning at a node (© InfraBel)<br />
</gallery><br />
<br />
It implies that an item may be located anywhere “along” a linear element (coordinate ranging from 0 to 1) but only “at” a nonlinear element (coordinate ranging from 0 to 0… that is 0).<br /><br />
<br />
It implies that, in this model, an item may be located anywhere “along” a linear element (coordinate ranging from 0 to 1) but only “at” a nonlinear element (coordinate ranging from 0 to 0… that is 0).<br /><br />
As the applied reference system is universal, any object can be attached to the network with a coordinate “Element, Position”. However, if this reference system is univocal, it is unreadable by a human. A conversion to more widely used coordinate systems will be discussed in the annex to this document.<br /><br />
<br />
[[File:ModelPart2.png|thumbnail|150px|Model Part 2 (© {{rml}})]]<br />
In terms of class diagram, the Generic NetElement class is extended with a class in which the intrinsic coordinate system is defined. The only role of this class is to know that the NetElement is oriented (linear) or not (the role of the CompositionNetElement class will be discussed later on).<br /><br />
While universal and deterministic (no two different locations on the network can point to the same coordinate – no single location on the network can have two coordinates), this referencing system is strictly logical and not human-usable. The link to Geographical/Geometrical or the more widely used Mileage system is part of chapter 6.6 Aggregation. <br /><br />
<br />
One ravel in the environment of a topological change is caused by the intrinsic positioning method.<br /><br />
On events of physical movements of switch(es), buffer stop(s), curves, track geometry all locations on the affected trails (or SoL’s) have to be recalculated.<br /><br />
Even in some cases where the topology is unchanged, recalculations have to be performed for locations which are expressed by intrinsic positioning.<br /><br />
At a second thought, we see the next disadvantages of intrinsic positioning:<br />
* Doubtful accuracy, regardless how many digits behind the digital dot are applied<br />
* Problems with data collection in the above value chain (+ costs)<br />
* The same with data maintenance (+ costs)<br />
* Bad or even impossible use ability in real life (mechanicals/operators) in the field and maintenance of history (at least conversion tool required)<br />
* Permanent recalculation on event of any topological or geometrical or (some) technical changes (conversion tool required).<br />
* Laborious use ability in the flow of the whole value chain with respect to the topological life cycle.<br />
In summary: from 2e bullet to last one: is there any positive business case thinkable? Probably not.<br /><br />
Consequence: the modeling group has to reconsider the utilization of the intrinsic positioning method !!<br />
<br />
'''Reminder:'''<br /><br />
The main purpose of the Intrinsic positioning system is to provide an universal way to store/transmit the position of the '''INTERACTION''' between the network and objects/events. <br /><br />
'''It is thus not intended to manage the (position of the) network/objects themselves.''' <br /><br />
Its accuracy depends on the accuracy of measurement of both interacting elements : the network and the event. Its lack of accuracy is not inherent to the storage method, but more of the accuracy of the measurement methods of each elements. <br /><br />
It is only currently described as the only referencing method because, up to now, we did not describe the objects. When designing the object classes, other referencing methods may (and will) be used as primary system. <br /><br />
It is a calculated value, especially useful when computing. It is thus not intended to be “Read” or “Written” by an human being. It is also not intended to be used in the field by human beings, as most of the time they don’t need to know the interaction between the object and the network, but rather the position of the object itself.<br /><br />
As it is the interaction between two elements, it has indeed to be recalculated as any of those elements changes. And it cannot be otherwise, because if one of the two element changes, the interaction also changes. <br /><br />
However, it only need to be calculated '''when knowing the interaction''' between an object and the network '''is needed''' (or before the transmission of data).<br /><br />
Its advantages are multiple when computing or transmitting data: <br /><br />
* As it is unitless, it can be used to compare/combine data from different sources, only the “Length” property of the carrier object need to be translated, not every relationship.<br />
* It never has to deal with “mileage anomalies”, so designing algorithms is easier and faster.<br />
* The computation algorithms need only be designed one time (and not one for each referencing method / combination of referencing methods).<br />
* Easy validation check ( from 0 to 1, you do not have to check which units are used, you don’t need to convert between m/km, miles/m/yards/feet…).<br />
* No possible errors when positioning relations: it has to be either at 0 or 1 (avoiding possible digit number errors between the length and relation position).<br />
* You can describe a conversion between any system and the intrinsic. If you add a new system, adding a conversion to intrinsic allows the conversion from/to any other system already described.<br />
* The reference system is built independently of the elements, allowing to describe mileage anomalies once for all the elements concerned (as several parallel tracks may share the same reference system, or be valid for more than one level)<br />
=== Application to the model ===<br />
Considering the following elements:<br /><br />
<gallery><br />
File:LinearInstrinsic.png|<br />
</gallery><br />
<br />
We only take spot objects and assume there is no mileage anomaly, in order to keep it simple.<br /><br />
The model allows two possible approaches: <br /><br />
=== Intrinsic ===<br />
<br />
<gallery><br />
File:IntrinsicExample.png|<br />
</gallery><br />
<br />
We manage the intrinsic coordinate for each object: 0.19191919 <br /><br />
As the relation between the intrinsic and the linear reference systems is known, the translation may be done to the linear coordinate system if/when needed.<br /><br />
However, it is not a very user friendly way to manage data that has to be manually entered.<br /><br />
<br />
<br />
{| class="wikitable"<br />
|-<br />
| '''What you should have learned'''<br /><br />
Lorem ipsum...<br />
* <br />
* Bulleted list item<br />
|}<br />
<br />
<br />
{| class="wikitable"<br />
|-<br />
! Back To !! Previous Chapter !! Next Chapter<br />
|-<br />
| [[Positioning]] || [[Track-referred positioning]] || -<br />
|}<br />
<br />
{{navi<br />
|chapter={{RTM}} modelling concepts<br />
|chapterlink=RTM modelling concepts<br />
|prev=Structure<br />
|next=Object positioning in the network<br />
|pchapter={{rtm}} Quick Start<br />
|pchapterlink=RTM Quick Start<br />
|nchapter={{rtm}} External References<br />
|nchapterlink=RTM External References<br />
|section=[[Positioning]]<br />
|sprev=Track-referred positioning<br />
|subsection=Intrinsic positioning / referencing<br />
}}</div>
Ferri Leberl
http://wiki.railtopomodel.org/index.php?title=Positioning&diff=917
Positioning
2017-03-13T15:06:14Z
<p>Ferri Leberl: /* Track-referred positioning */ {{main</p>
<hr />
<div>== Coordinate positioning ==<br />
{{main|Coordinate positioning}}<br />
<br />
== Linear Positioning / referencing ==<br />
Linear Referencing Systems (LRS) are widely used in the transportation world. They allow specifying positions along linear elements by using distances measured along the element (possibly with a lateral and horizontal offset), not by using classical 2D or 3D coordinating systems (CRS). <br /><br />
<br />
Locating an object with linear coordinates makes sense for various reasons. First of all, a large amount of information is stored in databases from legacy systems, anterior to geographical information systems which are specifically designed to deal with classical CRS. Knowing where an object is located along a route or a pipeline is sufficient to use the data from those databases, and can be seen as an integration mean for data coming from different sources. <br /><br />
<br />
It is even sometimes more interesting to have a linear position than a spatial position. Knowing that you have train stopped at about the kilometre 45 on the Line 36 Track A is better than having a potentially more accurate GPS position, which does neither tell without ambiguity on which line nor track it stands.<br />
<br />
=== Norms ===<br />
Linear Referencing is the object of the European Norm EN19148:2012. <br /><br />
<br />
The {{rtm}} follows the same principles, but uses a simplified version of the model as a lot of cases foreseen in the norm are not encountered in the railways world.<br />
<br /><br />
=== Axis ===<br />
A linear referencing system has an axis along which the measures are done. The axis can be any linear entity, a track segment or a whole line. It does not need to have geometry as knowing its length is enough to use an LRS.<br />
=== Referencing Methods===<br />
<br />
A Linear Referencing System may use several methods to describe a position along an axis: <br />
* '''Absolute''' : the position is specified by giving the distance starting at the beginning of the axis (with an eventual offset)<br />
<br />
[[File:ReferencingMethods Absolute.png|ReferencingMethodAbsolute]]<br />
<br />
Its main disadvantage is the fact that the whole length of the axis is taken into account when measuring. It means :<br />
# that the field workers always have to begin measurement at the start of the axis. It makes it unpractical for long axes,<br />
# that each change happening in the axis before the referenced object changes the coordinate of the measured point.<br />
It is thus only suitable for short axes, or axes which are very stable in the scope of the measurement. <br />
<br />
*'''Relative''' : The position is specified by giving the distance starting from an element (referent) whose position is known.<br />
<br />
[[File:ReferencingMethods Relative.png|ReferencingMethodRelative]]<br />
<br />
This is the most commonly used in railways, with mileposts as referents. Amongst its advantages is the stability of the coordinate which is now independent from works or axis changes happening before the referent, unless the change also affects the referent.<br /><br />
It is also more practical for the field workers as the measurement only has to start at the referent. <br /><br />
On the other hand, it forces to maintain a whole set of referents, ensuring they never move, and recalculating their position at each infrastructure change.<br /><br />
It makes it most suitable for long axes, such as lines, but poorly adapted to short segments (work reservations or sidings).<br /><br />
<br />
While it is possible to measure in both directions, (km x + y meters or km x+1 – z meters), the former method is the most widely used.<br /><br />
<br />
It is also the most suited to store long term information, because of the stability of the coordinates. However, it is very poorly suited to calculations as true distances are difficult to deduce from the coordinates.<br />
Both methods can include lateral or vertical offsets.<br /><br />
=== Expression of the distance ===<br />
The distance from the start of the measure (be it the start of the axis or the referent) can be expressed in several ways. <br />
*In metres (or miles, or any unit of choice)<br />
*Relative to the length of the element <br />
**As a percentage of the element (0…100 %)<br />
**Normalized (0…1). 75 % being expressed as 0.75<br />
* Hybrid : as a percentage of the length between two successive referents<br />
<br />
===== Hybrid expression =====<br />
The major problem with the relative method of linear referencing is the fact that it cannot be stored as a number when the system has mileage anomalies.<br /><br />
As the distance between two successive referents may be more than one kilometre (or 1000 units), the coordinate needs two fields to be stored. On top of that, not all reference points have a numeric name, a referent 12A might be inserted when lengthening the track between the mileposts 12 and 13.<br /><br />
<br />
The hybrid method aims to deal with this issue by assigning a fixed coordinate to each successive referent (usually a multiple of 1000) and adding the percentage of the distance between the two referents. <br /><br />
While it doesn’t allow true distance measurement, it keeps the sequence of the objects.<br /><br />
<br /><br />
<br />
For example, assuming the distance between the kilometre post 12 and 13 is 1200m and that the object needing to be located is at km 12 + 1050m, <br />
*Kilometre post 12 : coordinate 12000<br />
*Kilometre post 13 : coordinate 13000<br />
Object coordinate : coordinate of the referent (12000)+ percentage of the distance of the object regarding the distance between the referents (1050/1200) multiplied by the difference of coordinates between the two successive referents (1000)<br />
*Object coordinate : 12000 + (1050/1200)*1000 = 12875, which is a number that can be stored in one field and on which operations may be made. <br />
<br />
= {{rtm}} structure=<br />
As the railways world uses the most suited LR method according to the case, and that the aim of {{rtm}} is to design a universal way of describing railways, it was chosen to split the reference system into two kinds:<br />
*The NetElement’s internal way of measuring is a normalized absolute LRS. The NetElement with its own internal LRS (which we called “Intrinsic Positioning System” as it is proper to the NetElement, created and destroyed with it) becomes a “PositioningNetElement”<br />
*External linear referencing systems (such as the line/milepost) may be attached to the PositioningNetElement by linking a set of external LRS coordinates to the corresponding intrinsic coordinates.<br />
Choosing a universal LRS allows designing location algorithms independently from the field situation which would decide the most practical LR method for a specific segment.<br />
== Intrinsic positioning / referencing ==<br />
As said above, each NetElement forming the network has its own linear referencing system, which is created at the same time as the NetElement and destroyed with it. <br />
The purpose of this referencing system is double: <br />
*It ensures that every NetElement has a reference system allowing to locate events on it; small track elements (e.g. work reservations or side tracks) are often not linked to any “major” linear systems such as lines)<br />
*It ensures that every NetElement has an orientation and a length. This allows to locate other NetElements relatively to it (e.g. this switch is at the beginning of this track element)<br />
<br />
The reason why it was decided to use a normalized absolute LRS is that the normalized expression allows designing algorithms which are disconnected from the unit system. Some distances may be expressed in kilometres, miles, centimetres or feet. The normalized notation (0…1) allows to deal separately with the unit conversions.<br /><br />
Also, as it is applied to the smallest element of the network (at a given level), it can be used for locating objects in any path drawn on the network topology, whatever its length or its links with external referencing systems are (path crossing two lines).<br /><br />
Although very difficult to interpret in human interaction, it is perfectly adapted for computer calculations.<br />
<br />
== Track-referred positioning ==<br />
{{main|Track-referred positioning}}<br />
As the intrinsic coordinate system is difficult to use in human exchanges, field workers often use the classical linear referencing with line number, kilometre reference and distance from the post when dealing with long axis or metres from the start when dealing with short axis. <br /><br />
Those referencing systems can be linked with any relevant PositioningNetElement, ensuring the ability to translate the coordinates into an intrinsic coordinate and back. Any number of external reference systems can be linked to an element and an external reference system may of course be linked with several elements.<br />
<br />
{{navi<br />
|chapter={{RTM}} modelling concepts<br />
|chapterlink=RTM modelling concepts<br />
|prev=Structure<br />
|next=Object positioning in the network<br />
|pchapter={{rtm}} Quick Start<br />
|pchapterlink=RTM Quick Start<br />
|nchapter={{rtm}} External References<br />
|nchapterlink=RTM External References<br />
|snext=Coordinate positioning<br />
}}</div>
Ferri Leberl
http://wiki.railtopomodel.org/index.php?title=Track-referred_positioning&diff=916
Track-referred positioning
2017-03-13T15:04:11Z
<p>Ferri Leberl: navi</p>
<hr />
<div>{{Overview|text=Lorem ipsum...}}<br /><br />
<br />
== Traditional Positioning ==<br />
Localization expressed in a linear reference system, generally a coordinate along a predefined axis.<br />
<br />
<gallery><br />
File:AxisLPS.png|Axis for an LPS<br />
</gallery><br />
It could be read as “at coordinate X on the line Y” (being aware that the line Y is composed of many elements).<br /><br />
<br />
In the context of the {{rtm}} traditional positioning systems are either LRS based or based on geometric coordinate systems in their broadest meaning.<br /><br />
LRS based positioning systems are defined by the LinearReferencingMethod, the start measure, the end measure und the units of the measurement.<br /><br />
To describe local anomalies the class “LinearAnchorPoint” is provided. The attribute “measureToNext” allows to modify the basis for the interpolation of location in the interval towards the next “LinearAnchorPoint” instance.<br /><br />
“GeometricPositioningSystem” instances are defined using their Coordinate Reference System definition.<br /><br />
To locate “NetEntity” instances the class “PositioningSystemCoordinate” and the two derived classes “LinearCoordinate” and “GeometricCoordinate” are provided for traditional positioning.<br /><br />
A “LinearCoordinate” instance is defined by the measure, the lateral offset and the vertical offset. The attribute “measure” defines the position at the “line of reference” (possibly adjusted to local anomalies using “LinearAnchorPosition”).<br /><br />
In case the location is not precisely at the “line of reference” the attribute “LateralOffset” allows to define the perpendicular distance to the “line of reference”. Likewise the attribute “verticalOffset” is provided to define heights using the “line of reference” as baseline.<br />
<gallery><br />
File:PositioningSystemsLU.png|Positioning Systems (Language Unit)<br />
File:PositioningSystemsCoordinatesLU.png|Positioning Systems Coordinates (Lamguage Unit) <br />
</gallery><br />
<br />
== Other system ==<br />
<gallery><br />
File:IntrinsicExample2.png|Linear Approach<br />
</gallery><br />
In this case we manage the position of the object with another reference system (linear for instance)<br />
As the relation between the intrinsic and the linear positioning system is known, the translation to intrinsic is computable when (and if) needed.<br /><br />
'''Conclusion'''<br /><br />
In both case the coordinate is known (or computable) either in linear and intrinsic coordinate system. <br /><br />
The second case will be '''preferred''' (but not mandatory) for manually entered data (we manage the object for itself), the first case will be '''preferred''' (but not mandatory) in calculation/calculated data or data transmission (we compute the interactions).<br /><br />
In both case a relation has to be laid between the element (trail in this case) and the positioning system (else you cannot relate objects on this element), but this would be the case whatever the storage method.<br /><br />
<br />
{{navi<br />
|chapter={{RTM}} modelling concepts<br />
|chapterlink=RTM modelling concepts<br />
|prev=Structure<br />
|next=Object positioning in the network<br />
|pchapter={{rtm}} Quick Start<br />
|pchapterlink=RTM Quick Start<br />
|nchapter={{rtm}} External References<br />
|nchapterlink=RTM External References<br />
|sprev=Coordinate positioning<br />
|section=[[Positioning]]<br />
|subsection=Track-referred positioning<br />
|snext=Intrinsic positioning / referencing<br />
}}</div>
Ferri Leberl
http://wiki.railtopomodel.org/index.php?title=Coordinate_positioning&diff=915
Coordinate positioning
2017-03-13T14:59:59Z
<p>Ferri Leberl: navi</p>
<hr />
<div>{{Overview|text=This chapter introduces the concept of locating railway infrastructure elements by using coordinate reference systems.}}<br /><br />
<br />
Besides the intrinsic and the conventional linear track-referenced coordinate system, the {{rtm}} also allows to locate railway infrastructure elements using geodetic and geometric coordinate systems. The most known example in this case is the [https://en.wikipedia.org/wiki/World_Geodetic_System World Geodetic System WGS84] that is also used by the Global Navigation Satellite Systems like GPS or GALILEO. However, there is more than one geodetic coordinate system. Thus, the same infrastructure elements can be located with multiple coordinate systems, their correspondence being established in the model.<br /><br />
<gallery><br />
File:GeometricCoordinates.png|Geometric Coordinates (© RFF/SNCF Réseau)<br />
</gallery><br />
<br />
= General =<br />
== Geometric coordinates ==<br />
A geometric coordinate system can either be a projected X, Y, Z coordinate system, or a λ, ϕ, h geodetic coordinate system, or even an X, Y(, Z) schematic plan coordinate system.<br /><br />
It could be read as "at coordinate X, Y, Z in the system [EPSG:xxxxx] [01/06/2014]". More information about the EPSG code as catalogue of geodetic positioning sytems is provided in the next main chapter.<br /><br />
<br />
Geometric coordinates are quite familiar in other models and data exchange formats, too. For implementation, {{rtm}} includes basic concepts for positioning defined within the [https://en.wikipedia.org/wiki/Geography_Markup_Language Geography Markup Language GML].<br />
<br />
== Linear coordinates ==<br />
The model integrates a link between the linear positioning system and the intrinsic positioning system. It supports the "conversion" of an element position associated with a number between 0 and 1 to a kilometric point on its reference system. In the shown example the middle of the track / linear NetElement is referenced with the mileage value of 122 kilometers.<br /><br />
<br />
<gallery><br />
File:ConversionBoard.png|Conversion Board (© RFF/SNCF Réseau)<br />
</gallery><br />
<br />
= EPSG Code =<br />
As there are a number of different coordinate reference systems with different parameter sets available, it is important to identify the coordinate system without ambiguity. The International Association of Oil & Gas Producers set up the EPSG (European Petroleum Survey Group) Geodetic Parameter Registry, which provides a unique code for every coordinate system. The websites http://spatialreference.org/ and http://www.epsg-registry.org/ can be used to obtain an overview about different coordinate systems by their EPSG code.<br />
<br />
== Examples ==<br />
* EPSG code for World Geodetic System WGS84: urn:ogc:def:crs:EPSG::4326<br />
* EPSG code for ETRS89 / ETRS-TM32: urn:ogc:def:crs:EPSG::3044<br />
* EPSG code for the height coordinate system DHHN92: urn:ogc:def:crs:EPSG::5783<br />
<br />
= Relevant classes in the {{rtm}} =<br />
The classes, used to define the location and positioning systems and their coordinates, are:<br />
* '''PositioningSystem''': This class defines the general concept of a Coordinate Reference System used for positioning.<br />
* '''LinearPositioningSystem''': This class defines a Linear Referencing System. It defines a start and an end coordinate.<br />
* '''LinearAnchorPoints''': this class describes the reference points within the linear reference system (Milestones, anomaly points like gaps and overlaps...) and their characteristics.<br />
* '''LinearCoordinate''': This class is used for providing a location expressed in a Linear Reference System (LRS).<br />
* '''GeometricPositioningSystem''': This class defines a Geometrical Reference System, so it allows to locate a resource with its geometrical coordinates (x, y, z or λ, ϕ, h). The class provides the parameter ''crsDefinition'' to define the Coordinate Reference System. This parameter shall be used to name the EPSG code and thus define all the relevant parameters of the coordinate system.<br />
* '''GeometricCoordinate''': This class defines the localization expressed in a geometrical (or geographical) Reference System, so it defines the coordinates (x, y, z or λ, ϕ, h).<br />
* '''PositioningSystemCoordinate''': This class represents a coordinate in either a geometric or linear reference system.<br />
* '''IntrinsicCoordinate''': This class allows associating an intrinsic coordinate coming from the topology network to another coordinate, either geographic or linear.<br />
* '''AssociatedPositioningSystem''': This class allows to group couples of coordinates to define the translation parameters between an external (geometric or linear) coordinate system and the element’s intrinsic coordinate system.<br />
<br />
{{navi<br />
|lesson=<br><br />
* Coordinate reference systems are (besides intrinsic and conventional linear referencing) the third option to define positions/locations in the {{rtm}}.<br />
* All geodetic coordinate reference systems can be defined by a unique identifier: the EPSG code.<br />
* {{rtm}} implementation shall follow concepts of the existing international standard GML. <br />
* Coordinate reference systems can also be used to define schematic coordinates as they are used in terms of screen coordinates.<br />
|chapter={{RTM}} modelling concepts<br />
|chapterlink=RTM modelling concepts<br />
|prev=Structure<br />
|next=Object positioning in the network<br />
|pchapter={{rtm}} Quick Start<br />
|pchapterlink=RTM Quick Start<br />
|nchapter={{rtm}} External References<br />
|nchapterlink=RTM External References<br />
|subsection=Coordinate positioning<br />
|section=[[Positioning]]<br />
|snext=Track-referred positioning<br />
}}</div>
Ferri Leberl
http://wiki.railtopomodel.org/index.php?title=Positioning&diff=914
Positioning
2017-03-13T14:56:25Z
<p>Ferri Leberl: /* Track-referred positioning */</p>
<hr />
<div>== Coordinate positioning ==<br />
{{main|Coordinate positioning}}<br />
<br />
== Linear Positioning / referencing ==<br />
Linear Referencing Systems (LRS) are widely used in the transportation world. They allow specifying positions along linear elements by using distances measured along the element (possibly with a lateral and horizontal offset), not by using classical 2D or 3D coordinating systems (CRS). <br /><br />
<br />
Locating an object with linear coordinates makes sense for various reasons. First of all, a large amount of information is stored in databases from legacy systems, anterior to geographical information systems which are specifically designed to deal with classical CRS. Knowing where an object is located along a route or a pipeline is sufficient to use the data from those databases, and can be seen as an integration mean for data coming from different sources. <br /><br />
<br />
It is even sometimes more interesting to have a linear position than a spatial position. Knowing that you have train stopped at about the kilometre 45 on the Line 36 Track A is better than having a potentially more accurate GPS position, which does neither tell without ambiguity on which line nor track it stands.<br />
<br />
=== Norms ===<br />
Linear Referencing is the object of the European Norm EN19148:2012. <br /><br />
<br />
The {{rtm}} follows the same principles, but uses a simplified version of the model as a lot of cases foreseen in the norm are not encountered in the railways world.<br />
<br /><br />
=== Axis ===<br />
A linear referencing system has an axis along which the measures are done. The axis can be any linear entity, a track segment or a whole line. It does not need to have geometry as knowing its length is enough to use an LRS.<br />
=== Referencing Methods===<br />
<br />
A Linear Referencing System may use several methods to describe a position along an axis: <br />
* '''Absolute''' : the position is specified by giving the distance starting at the beginning of the axis (with an eventual offset)<br />
<br />
[[File:ReferencingMethods Absolute.png|ReferencingMethodAbsolute]]<br />
<br />
Its main disadvantage is the fact that the whole length of the axis is taken into account when measuring. It means :<br />
# that the field workers always have to begin measurement at the start of the axis. It makes it unpractical for long axes,<br />
# that each change happening in the axis before the referenced object changes the coordinate of the measured point.<br />
It is thus only suitable for short axes, or axes which are very stable in the scope of the measurement. <br />
<br />
*'''Relative''' : The position is specified by giving the distance starting from an element (referent) whose position is known.<br />
<br />
[[File:ReferencingMethods Relative.png|ReferencingMethodRelative]]<br />
<br />
This is the most commonly used in railways, with mileposts as referents. Amongst its advantages is the stability of the coordinate which is now independent from works or axis changes happening before the referent, unless the change also affects the referent.<br /><br />
It is also more practical for the field workers as the measurement only has to start at the referent. <br /><br />
On the other hand, it forces to maintain a whole set of referents, ensuring they never move, and recalculating their position at each infrastructure change.<br /><br />
It makes it most suitable for long axes, such as lines, but poorly adapted to short segments (work reservations or sidings).<br /><br />
<br />
While it is possible to measure in both directions, (km x + y meters or km x+1 – z meters), the former method is the most widely used.<br /><br />
<br />
It is also the most suited to store long term information, because of the stability of the coordinates. However, it is very poorly suited to calculations as true distances are difficult to deduce from the coordinates.<br />
Both methods can include lateral or vertical offsets.<br /><br />
=== Expression of the distance ===<br />
The distance from the start of the measure (be it the start of the axis or the referent) can be expressed in several ways. <br />
*In metres (or miles, or any unit of choice)<br />
*Relative to the length of the element <br />
**As a percentage of the element (0…100 %)<br />
**Normalized (0…1). 75 % being expressed as 0.75<br />
* Hybrid : as a percentage of the length between two successive referents<br />
<br />
===== Hybrid expression =====<br />
The major problem with the relative method of linear referencing is the fact that it cannot be stored as a number when the system has mileage anomalies.<br /><br />
As the distance between two successive referents may be more than one kilometre (or 1000 units), the coordinate needs two fields to be stored. On top of that, not all reference points have a numeric name, a referent 12A might be inserted when lengthening the track between the mileposts 12 and 13.<br /><br />
<br />
The hybrid method aims to deal with this issue by assigning a fixed coordinate to each successive referent (usually a multiple of 1000) and adding the percentage of the distance between the two referents. <br /><br />
While it doesn’t allow true distance measurement, it keeps the sequence of the objects.<br /><br />
<br /><br />
<br />
For example, assuming the distance between the kilometre post 12 and 13 is 1200m and that the object needing to be located is at km 12 + 1050m, <br />
*Kilometre post 12 : coordinate 12000<br />
*Kilometre post 13 : coordinate 13000<br />
Object coordinate : coordinate of the referent (12000)+ percentage of the distance of the object regarding the distance between the referents (1050/1200) multiplied by the difference of coordinates between the two successive referents (1000)<br />
*Object coordinate : 12000 + (1050/1200)*1000 = 12875, which is a number that can be stored in one field and on which operations may be made. <br />
<br />
= {{rtm}} structure=<br />
As the railways world uses the most suited LR method according to the case, and that the aim of {{rtm}} is to design a universal way of describing railways, it was chosen to split the reference system into two kinds:<br />
*The NetElement’s internal way of measuring is a normalized absolute LRS. The NetElement with its own internal LRS (which we called “Intrinsic Positioning System” as it is proper to the NetElement, created and destroyed with it) becomes a “PositioningNetElement”<br />
*External linear referencing systems (such as the line/milepost) may be attached to the PositioningNetElement by linking a set of external LRS coordinates to the corresponding intrinsic coordinates.<br />
Choosing a universal LRS allows designing location algorithms independently from the field situation which would decide the most practical LR method for a specific segment.<br />
== Intrinsic positioning / referencing ==<br />
As said above, each NetElement forming the network has its own linear referencing system, which is created at the same time as the NetElement and destroyed with it. <br />
The purpose of this referencing system is double: <br />
*It ensures that every NetElement has a reference system allowing to locate events on it; small track elements (e.g. work reservations or side tracks) are often not linked to any “major” linear systems such as lines)<br />
*It ensures that every NetElement has an orientation and a length. This allows to locate other NetElements relatively to it (e.g. this switch is at the beginning of this track element)<br />
<br />
The reason why it was decided to use a normalized absolute LRS is that the normalized expression allows designing algorithms which are disconnected from the unit system. Some distances may be expressed in kilometres, miles, centimetres or feet. The normalized notation (0…1) allows to deal separately with the unit conversions.<br /><br />
Also, as it is applied to the smallest element of the network (at a given level), it can be used for locating objects in any path drawn on the network topology, whatever its length or its links with external referencing systems are (path crossing two lines).<br /><br />
Although very difficult to interpret in human interaction, it is perfectly adapted for computer calculations.<br />
<br />
== Track-referred positioning ==<br />
As the intrinsic coordinate system is difficult to use in human exchanges, field workers often use the classical linear referencing with line number, kilometre reference and distance from the post when dealing with long axis or metres from the start when dealing with short axis. <br /><br />
Those referencing systems can be linked with any relevant PositioningNetElement, ensuring the ability to translate the coordinates into an intrinsic coordinate and back. Any number of external reference systems can be linked to an element and an external reference system may of course be linked with several elements.<br />
<br />
{{navi<br />
|chapter={{RTM}} modelling concepts<br />
|chapterlink=RTM modelling concepts<br />
|prev=Structure<br />
|next=Object positioning in the network<br />
|pchapter={{rtm}} Quick Start<br />
|pchapterlink=RTM Quick Start<br />
|nchapter={{rtm}} External References<br />
|nchapterlink=RTM External References<br />
|snext=Coordinate positioning<br />
}}</div>
Ferri Leberl
http://wiki.railtopomodel.org/index.php?title=Positioning&diff=913
Positioning
2017-03-13T14:55:27Z
<p>Ferri Leberl: /* Coordinate positioning */ {{main}}</p>
<hr />
<div>== Coordinate positioning ==<br />
{{main|Coordinate positioning}}<br />
<br />
== Linear Positioning / referencing ==<br />
Linear Referencing Systems (LRS) are widely used in the transportation world. They allow specifying positions along linear elements by using distances measured along the element (possibly with a lateral and horizontal offset), not by using classical 2D or 3D coordinating systems (CRS). <br /><br />
<br />
Locating an object with linear coordinates makes sense for various reasons. First of all, a large amount of information is stored in databases from legacy systems, anterior to geographical information systems which are specifically designed to deal with classical CRS. Knowing where an object is located along a route or a pipeline is sufficient to use the data from those databases, and can be seen as an integration mean for data coming from different sources. <br /><br />
<br />
It is even sometimes more interesting to have a linear position than a spatial position. Knowing that you have train stopped at about the kilometre 45 on the Line 36 Track A is better than having a potentially more accurate GPS position, which does neither tell without ambiguity on which line nor track it stands.<br />
<br />
=== Norms ===<br />
Linear Referencing is the object of the European Norm EN19148:2012. <br /><br />
<br />
The {{rtm}} follows the same principles, but uses a simplified version of the model as a lot of cases foreseen in the norm are not encountered in the railways world.<br />
<br /><br />
=== Axis ===<br />
A linear referencing system has an axis along which the measures are done. The axis can be any linear entity, a track segment or a whole line. It does not need to have geometry as knowing its length is enough to use an LRS.<br />
=== Referencing Methods===<br />
<br />
A Linear Referencing System may use several methods to describe a position along an axis: <br />
* '''Absolute''' : the position is specified by giving the distance starting at the beginning of the axis (with an eventual offset)<br />
<br />
[[File:ReferencingMethods Absolute.png|ReferencingMethodAbsolute]]<br />
<br />
Its main disadvantage is the fact that the whole length of the axis is taken into account when measuring. It means :<br />
# that the field workers always have to begin measurement at the start of the axis. It makes it unpractical for long axes,<br />
# that each change happening in the axis before the referenced object changes the coordinate of the measured point.<br />
It is thus only suitable for short axes, or axes which are very stable in the scope of the measurement. <br />
<br />
*'''Relative''' : The position is specified by giving the distance starting from an element (referent) whose position is known.<br />
<br />
[[File:ReferencingMethods Relative.png|ReferencingMethodRelative]]<br />
<br />
This is the most commonly used in railways, with mileposts as referents. Amongst its advantages is the stability of the coordinate which is now independent from works or axis changes happening before the referent, unless the change also affects the referent.<br /><br />
It is also more practical for the field workers as the measurement only has to start at the referent. <br /><br />
On the other hand, it forces to maintain a whole set of referents, ensuring they never move, and recalculating their position at each infrastructure change.<br /><br />
It makes it most suitable for long axes, such as lines, but poorly adapted to short segments (work reservations or sidings).<br /><br />
<br />
While it is possible to measure in both directions, (km x + y meters or km x+1 – z meters), the former method is the most widely used.<br /><br />
<br />
It is also the most suited to store long term information, because of the stability of the coordinates. However, it is very poorly suited to calculations as true distances are difficult to deduce from the coordinates.<br />
Both methods can include lateral or vertical offsets.<br /><br />
=== Expression of the distance ===<br />
The distance from the start of the measure (be it the start of the axis or the referent) can be expressed in several ways. <br />
*In metres (or miles, or any unit of choice)<br />
*Relative to the length of the element <br />
**As a percentage of the element (0…100 %)<br />
**Normalized (0…1). 75 % being expressed as 0.75<br />
* Hybrid : as a percentage of the length between two successive referents<br />
<br />
===== Hybrid expression =====<br />
The major problem with the relative method of linear referencing is the fact that it cannot be stored as a number when the system has mileage anomalies.<br /><br />
As the distance between two successive referents may be more than one kilometre (or 1000 units), the coordinate needs two fields to be stored. On top of that, not all reference points have a numeric name, a referent 12A might be inserted when lengthening the track between the mileposts 12 and 13.<br /><br />
<br />
The hybrid method aims to deal with this issue by assigning a fixed coordinate to each successive referent (usually a multiple of 1000) and adding the percentage of the distance between the two referents. <br /><br />
While it doesn’t allow true distance measurement, it keeps the sequence of the objects.<br /><br />
<br /><br />
<br />
For example, assuming the distance between the kilometre post 12 and 13 is 1200m and that the object needing to be located is at km 12 + 1050m, <br />
*Kilometre post 12 : coordinate 12000<br />
*Kilometre post 13 : coordinate 13000<br />
Object coordinate : coordinate of the referent (12000)+ percentage of the distance of the object regarding the distance between the referents (1050/1200) multiplied by the difference of coordinates between the two successive referents (1000)<br />
*Object coordinate : 12000 + (1050/1200)*1000 = 12875, which is a number that can be stored in one field and on which operations may be made. <br />
<br />
= {{rtm}} structure=<br />
As the railways world uses the most suited LR method according to the case, and that the aim of {{rtm}} is to design a universal way of describing railways, it was chosen to split the reference system into two kinds:<br />
*The NetElement’s internal way of measuring is a normalized absolute LRS. The NetElement with its own internal LRS (which we called “Intrinsic Positioning System” as it is proper to the NetElement, created and destroyed with it) becomes a “PositioningNetElement”<br />
*External linear referencing systems (such as the line/milepost) may be attached to the PositioningNetElement by linking a set of external LRS coordinates to the corresponding intrinsic coordinates.<br />
Choosing a universal LRS allows designing location algorithms independently from the field situation which would decide the most practical LR method for a specific segment.<br />
== Intrinsic positioning / referencing ==<br />
As said above, each NetElement forming the network has its own linear referencing system, which is created at the same time as the NetElement and destroyed with it. <br />
The purpose of this referencing system is double: <br />
*It ensures that every NetElement has a reference system allowing to locate events on it; small track elements (e.g. work reservations or side tracks) are often not linked to any “major” linear systems such as lines)<br />
*It ensures that every NetElement has an orientation and a length. This allows to locate other NetElements relatively to it (e.g. this switch is at the beginning of this track element)<br />
<br />
The reason why it was decided to use a normalized absolute LRS is that the normalized expression allows designing algorithms which are disconnected from the unit system. Some distances may be expressed in kilometres, miles, centimetres or feet. The normalized notation (0…1) allows to deal separately with the unit conversions.<br /><br />
Also, as it is applied to the smallest element of the network (at a given level), it can be used for locating objects in any path drawn on the network topology, whatever its length or its links with external referencing systems are (path crossing two lines).<br /><br />
Although very difficult to interpret in human interaction, it is perfectly adapted for computer calculations.<br />
<br />
== Track-referred positioning ==<br />
As the intrinsic coordinate system is difficult to use in human exchanges, field workers often use the classical linear referencing with line number, kilometre reference and distance from the post when dealing with long axis or metres from the start when dealing with short axis. <br /><br />
Those referencing systems can be linked with any relevant PositioningNetElement, ensuring the ability to translate the coordinates into an intrinsic coordinate and back. Any number of external reference systems can be linked to an element and an external reference system may of course be linked with several elements.<br />
<br />
{{navi<br />
|chapter={{RTM}} modelling concepts<br />
|chapterlink=RTM modelling concepts<br />
|prev=Structure<br />
|next=Object positioning in the network<br />
|pchapter={{rtm}} Quick Start<br />
|pchapterlink=RTM Quick Start<br />
|nchapter={{rtm}} External References<br />
|nchapterlink=RTM External References<br />
}}</div>
Ferri Leberl
http://wiki.railtopomodel.org/index.php?title=Transport_mode_borders&diff=912
Transport mode borders
2017-03-13T14:39:18Z
<p>Ferri Leberl: typo</p>
<hr />
<div>{{Overview|text=Lorem ipsum...}}<br /><br />
<br />
<br />
<br />
{{navi<br />
|chapter={{RTM}} External References<br />
|chapterlink=RTM External References<br />
|nchapter={{RTM}} Use Cases and Application Examples<br />
|nchapterlink=RTM Use Cases and Application Examples<br />
|pchapter={{rtm}} Modelling Concepts<br />
|pchapterlink=RTM Modelling Concepts<br />
|next=Geographical borders<br />
}}</div>
Ferri Leberl
http://wiki.railtopomodel.org/index.php?title=Template:Navi&diff=911
Template:Navi
2017-03-13T14:04:52Z
<p>Ferri Leberl: Zeichen</p>
<hr />
<div><includeonly><br />
<br /><br />
<br /><br />
<br /><br />
<br /><br />
<br /><br />
<br /><br />
<br /><br />
{| class="wikitable"<br />
|-<br />
! colspan="4"| What you should have learned<br />
|-<br />
| colspan="4"|{{{lesson|Please, enter a summary!}}}<br />
|-<br />
! colspan="4"| Navigation<br />
|-<br />
|'''[[Main_Page|Home]]'''||''←''||''•''||''→''<br />
|-<br />
|''Chapter''||{{#if:{{{pchapter|}}}|[[{{#if:{{{pchapterlink|}}}|{{{pchapterlink}}}|{{{pchapter}}}}}|{{{pchapter}}}]]}}||[[{{#if:{{{chapterlink|}}}|{{{chapterlink}}}|{{{chapter}}}}}|{{{chapter}}}]]||{{#if:{{{nchapter|}}}|[[{{#if:{{{nchapterlink|}}}|{{{nchapterlink}}}|{{{nchapter}}}}}|{{{nchapter}}}]]}}<br />
|-<br />
|''Section''||{{#if:{{{prev|}}}|[[{{#if:{{{prevlink|}}}|{{{prevlink}}}|{{{prev}}}}}|{{{prev}}}]]}}||{{{section|[[{{PAGENAME}}]]}}}||{{#if:{{{next|}}}|[[{{#if:{{{nextlink|}}}|{{{nextlink}}}|{{{next}}}}}|{{{next}}}]]}}<br />
|-<br />
|''Subection''||{{#if:{{{sprev|}}}|[[{{#if:{{{sprevlink|}}}|{{{sprevlink}}}|{{{sprev}}}}}|{{{sprev}}}]]}}||{{#if:{{{subsection|}}}|[[{{#if:{{{subsectionlink|}}}|{{{subsectionlink}}}|{{{subsection}}}}}|{{{subsection}}}]]}}||{{#if:{{{snext|}}}|[[{{#if:{{{snextlink|}}}|{{{snextlink}}}|{{{snext}}}}}|{{{snext}}}]]}}<br />
|}</includeonly><noinclude><br />
==Usage==<br />
This template offers a standardized menu for the page foot. It offers a chapter ''What you have learned'' and a swift shift to the {{rtm}} home page, the chapter home page, the previous and the next section.<br />
===Arguments===<br />
The template has two obligatory and four optional arguments, all of which are named.<br />
*Obligatory<br />
**chapter: the chapter, which the page is assigned to<br />
**lesson: this argument bears the text of the symmary<br />
*Optional<br />
**prev: the name of the previous section. Usually it will be identical with the link to the previous section, so the latter can be left away. As there is not allways a previous section, also prev may be empty.<br />
**next: the name of the previous section. Usually it will be identical with the link to the next section, so the latter can be left away. As there is not allways a next section, also next may be empty.<br />
**prevlink: an argument for the link to the previous section, if it differs from ''prev''.<br />
**prevlink: an argument for the link to the next section, if it differs from ''next''.<br />
==Examples==<br />
<pre>{{navi}}</pre><br />
delivers<br />
<br />
{| class="wikitable"<br />
|-<br />
! colspan="2"| What you should have learned<br />
|-<br />
| colspan="2"|Please, enter a summary!<br />
|-<br />
! colspan="2"| Navigation<br />
|-<br />
| [[Main_Page|Home]] || [[{{{chapter}}}|{{{chapter}}}]]<br />
|-<br />
|<small>previous:</small><br>{{#if:|[[|]]|&nbsp;}}||<small>next:</small><br>{{#if:|[[|]]|&nbsp;}}<br />
|}<br />
<br />
<pre>{{navi<br />
|lesson=Seid wachsam!<br />
|chapter={{RTM}} modelling concepts<br />
|prev={{RTM}} Quick Start<br />
|next=Borders of {{RTM}}<br />
|chapterlink=RTM modelling concepts<br />
|prevlink=RTM Quick Start<br />
|nextlink=Borders of RTM<br />
}}</pre><br />
delivers<br />
<br />
{| class="wikitable"<br />
|-<br />
! colspan="2"| What you should have learned<br />
|-<br />
| colspan="2"|Seid wachsam!<br />
|-<br />
! colspan="2"| Navigation<br />
|-<br />
| [[Main_Page|Home]] || [[RTM modelling concepts|{{RTM}} modelling concepts]]<br />
|-<br />
|<small>previous:</small><br>{{#if:{{RTM}} Quick Start|[[RTM Quick Start|{{RTM}} Quick Start]]|&nbsp;}}||<small>next:</small><br>{{#if:Borders of {{RTM}}|[[Borders of RTM|Borders of {{RTM}}]]|&nbsp;}}<br />
|}<br />
<br />
<pre>{{navi<br />
|lesson=<br />
|chapter={{RTM}} modelling concepts<br />
|chapterlink=RTM modelling concepts<br />
|next=Core elements<br />
}}</pre><br />
delivers<br />
<br />
{| class="wikitable"<br />
|-<br />
! colspan="2"| What you should have learned<br />
|-<br />
| colspan="2"|<br />
|-<br />
! colspan="2"| Navigation<br />
|-<br />
| [[Main_Page|Home]] || [[RTM modelling concepts|{{RTM}} modelling concepts]]<br />
|-<br />
|<small>previous:</small><br>{{#if:|[[|]]|&nbsp;}}||<small>next:</small><br>{{#if:Core elements|[[Core elements|Core elements]]|&nbsp;}}<br />
|}<br />
[[category:contentTemplate]]<br />
</noinclude></div>
Ferri Leberl
http://wiki.railtopomodel.org/index.php?title=Template:Navi&diff=910
Template:Navi
2017-03-13T14:03:46Z
<p>Ferri Leberl: Zeichen</p>
<hr />
<div><includeonly><br />
<br /><br />
<br /><br />
<br /><br />
<br /><br />
<br /><br />
<br /><br />
<br /><br />
{| class="wikitable"<br />
|-<br />
! colspan="4"| What you should have learned<br />
|-<br />
| colspan="4"|{{{lesson|Please, enter a summary!}}}<br />
|-<br />
! colspan="4"| Navigation<br />
|-<br />
|'''[[Main_Page|Home]]'''||''←''||•||''→''<br />
|-<br />
|''Chapter''||{{#if:{{{pchapter|}}}|[[{{#if:{{{pchapterlink|}}}|{{{pchapterlink}}}|{{{pchapter}}}}}|{{{pchapter}}}]]}}||[[{{#if:{{{chapterlink|}}}|{{{chapterlink}}}|{{{chapter}}}}}|{{{chapter}}}]]||{{#if:{{{nchapter|}}}|[[{{#if:{{{nchapterlink|}}}|{{{nchapterlink}}}|{{{nchapter}}}}}|{{{nchapter}}}]]}}<br />
|-<br />
|''Section''||{{#if:{{{prev|}}}|[[{{#if:{{{prevlink|}}}|{{{prevlink}}}|{{{prev}}}}}|{{{prev}}}]]}}||{{{section|[[{{PAGENAME}}]]}}}||{{#if:{{{next|}}}|[[{{#if:{{{nextlink|}}}|{{{nextlink}}}|{{{next}}}}}|{{{next}}}]]}}<br />
|-<br />
|''Subection''||{{#if:{{{sprev|}}}|[[{{#if:{{{sprevlink|}}}|{{{sprevlink}}}|{{{sprev}}}}}|{{{sprev}}}]]}}||{{#if:{{{subsection|}}}|[[{{#if:{{{subsectionlink|}}}|{{{subsectionlink}}}|{{{subsection}}}}}|{{{subsection}}}]]}}||{{#if:{{{snext|}}}|[[{{#if:{{{snextlink|}}}|{{{snextlink}}}|{{{snext}}}}}|{{{snext}}}]]}}<br />
|}</includeonly><noinclude><br />
==Usage==<br />
This template offers a standardized menu for the page foot. It offers a chapter ''What you have learned'' and a swift shift to the {{rtm}} home page, the chapter home page, the previous and the next section.<br />
===Arguments===<br />
The template has two obligatory and four optional arguments, all of which are named.<br />
*Obligatory<br />
**chapter: the chapter, which the page is assigned to<br />
**lesson: this argument bears the text of the symmary<br />
*Optional<br />
**prev: the name of the previous section. Usually it will be identical with the link to the previous section, so the latter can be left away. As there is not allways a previous section, also prev may be empty.<br />
**next: the name of the previous section. Usually it will be identical with the link to the next section, so the latter can be left away. As there is not allways a next section, also next may be empty.<br />
**prevlink: an argument for the link to the previous section, if it differs from ''prev''.<br />
**prevlink: an argument for the link to the next section, if it differs from ''next''.<br />
==Examples==<br />
<pre>{{navi}}</pre><br />
delivers<br />
<br />
{| class="wikitable"<br />
|-<br />
! colspan="2"| What you should have learned<br />
|-<br />
| colspan="2"|Please, enter a summary!<br />
|-<br />
! colspan="2"| Navigation<br />
|-<br />
| [[Main_Page|Home]] || [[{{{chapter}}}|{{{chapter}}}]]<br />
|-<br />
|<small>previous:</small><br>{{#if:|[[|]]|&nbsp;}}||<small>next:</small><br>{{#if:|[[|]]|&nbsp;}}<br />
|}<br />
<br />
<pre>{{navi<br />
|lesson=Seid wachsam!<br />
|chapter={{RTM}} modelling concepts<br />
|prev={{RTM}} Quick Start<br />
|next=Borders of {{RTM}}<br />
|chapterlink=RTM modelling concepts<br />
|prevlink=RTM Quick Start<br />
|nextlink=Borders of RTM<br />
}}</pre><br />
delivers<br />
<br />
{| class="wikitable"<br />
|-<br />
! colspan="2"| What you should have learned<br />
|-<br />
| colspan="2"|Seid wachsam!<br />
|-<br />
! colspan="2"| Navigation<br />
|-<br />
| [[Main_Page|Home]] || [[RTM modelling concepts|{{RTM}} modelling concepts]]<br />
|-<br />
|<small>previous:</small><br>{{#if:{{RTM}} Quick Start|[[RTM Quick Start|{{RTM}} Quick Start]]|&nbsp;}}||<small>next:</small><br>{{#if:Borders of {{RTM}}|[[Borders of RTM|Borders of {{RTM}}]]|&nbsp;}}<br />
|}<br />
<br />
<pre>{{navi<br />
|lesson=<br />
|chapter={{RTM}} modelling concepts<br />
|chapterlink=RTM modelling concepts<br />
|next=Core elements<br />
}}</pre><br />
delivers<br />
<br />
{| class="wikitable"<br />
|-<br />
! colspan="2"| What you should have learned<br />
|-<br />
| colspan="2"|<br />
|-<br />
! colspan="2"| Navigation<br />
|-<br />
| [[Main_Page|Home]] || [[RTM modelling concepts|{{RTM}} modelling concepts]]<br />
|-<br />
|<small>previous:</small><br>{{#if:|[[|]]|&nbsp;}}||<small>next:</small><br>{{#if:Core elements|[[Core elements|Core elements]]|&nbsp;}}<br />
|}<br />
[[category:contentTemplate]]<br />
</noinclude></div>
Ferri Leberl
http://wiki.railtopomodel.org/index.php?title=Open_issues&diff=909
Open issues
2017-03-13T14:02:01Z
<p>Ferri Leberl: Änderung Navi</p>
<hr />
<div>{{Overview|text=Lorem ipsum...}}<br /><br />
<br />
{{navi<br />
|chapter={{RTM}} Model Extensions<br />
|chapterlink=RTM Model Extensions<br />
|pchapter={{RTM}} Use Cases and Application Examples<br />
|pchapterlink=RTM Use Cases and Application Examples<br />
|prev=Planned extensions<br />
}}</div>
Ferri Leberl
http://wiki.railtopomodel.org/index.php?title=ETCS&diff=908
ETCS
2017-03-13T14:00:19Z
<p>Ferri Leberl: Änderung Navi</p>
<hr />
<div>{{Overview|text=Lorem ipsum...}}<br /><br />
<br />
{{navi<br />
|chapter={{RTM}} Model Extensions<br />
|chapterlink=RTM Model Extensions<br />
|pchapter={{RTM}} Use Cases and Application Examples<br />
|pchapterlink=RTM Use Cases and Application Examples<br />
|next=Open issues<br />
|section=[[Planned extensions]]<br />
|sprev=Inner track geometry (track alignment)<br />
|subsection=ETCS<br />
}}</div>
Ferri Leberl
http://wiki.railtopomodel.org/index.php?title=Inner_track_geometry_(track_alignment)&diff=907
Inner track geometry (track alignment)
2017-03-13T13:59:16Z
<p>Ferri Leberl: Änderung Navi</p>
<hr />
<div>{{Overview|text=Lorem ipsum...}}<br /><br />
<br />
{{navi<br />
|chapter={{RTM}} Model Extensions<br />
|chapterlink=RTM Model Extensions<br />
|pchapter={{RTM}} Use Cases and Application Examples<br />
|pchapterlink=RTM Use Cases and Application Examples<br />
|next=Open issues<br />
|section=[[Planned extensions]]<br />
|sprev=Meta Data / Quality data<br />
|subsection=Inner track geometry (track alignment)<br />
|snext=ETCS<br />
}}</div>
Ferri Leberl
http://wiki.railtopomodel.org/index.php?title=Meta_Data_/_Quality_data&diff=906
Meta Data / Quality data
2017-03-13T13:57:28Z
<p>Ferri Leberl: Änderung Navi</p>
<hr />
<div>{{Overview|text=Lorem ipsum...}}<br /><br />
<br />
{{navi<br />
|chapter={{RTM}} Model Extensions<br />
|chapterlink=RTM Model Extensions<br />
|pchapter={{RTM}} Use Cases and Application Examples<br />
|pchapterlink=RTM Use Cases and Application Examples<br />
|next=Open issues<br />
|section=[[Planned extensions]]<br />
|sprev=Time Management aspects<br />
|subsection=Meta Data / Quality data<br />
|snext=Inner track geometry (track alignment)<br />
}}</div>
Ferri Leberl
http://wiki.railtopomodel.org/index.php?title=Time_management_aspects&diff=905
Time management aspects
2017-03-13T13:55:50Z
<p>Ferri Leberl: Änderung Navi</p>
<hr />
<div>{{Overview|text=Lorem ipsum...}}<br /><br />
<br />
The time aspect in {{rtm}} is defined at the class “BaseObject” and refers to the time period for which a certain information object is valid in respect to availability for usage for train operations.<br /><br />
The attribute “validFrom” defines the point in time where the object in question is available for usage for train operations.<br /><br />
The attribute “validTo” defines the point in time where the object in question is no longer available for functional usage. The attribute “validTo” can be empty.<br />
<br />
=== Handling time dimension ===<br />
The handling of the time dimension manifests during input of new-, adjusted- or deleted data and then storage and export of (subsets) of data. Especially the export functions can focus on specified time frames of specified subsets (topological areas) which can be (even partly) affected by different time validities of values for the same objects.<br /><br />
Time related dependencies can be handled on the level of:<br />
* Individual (data) objects: from birth to dismantling, both for the functional placeholder of an object (designed existence) and its physical realization(s) (reality outside in the field).<br />
* Coherent data sets on group- or area level of the topology (usually demarcated on the micro-topology)<br />
* Connectivity in time and space of data-entities (e.g. to secure overall referential integrity) <br />
The last issue is secured the best if new topologically coherent datasets with a common time validity are inserted as a whole, with special care for ravel relationships with its topological environment. At the storage phase of data, this corresponds with the handling of precise demarcated and identified excisions in the original dataset in which the modifications will be applied.<br />
<gallery><br />
File:TimeDimension.PNG|<br />
</gallery><br />
<br />
=== Time granularity ===<br />
Theoretically the time dimension can be handled using any timestamp-accuracy one can think of.<br /><br />
<br /><br />
The granular size of the time dimension has to be chosen in accordance with the frequencies of the design-, data maintenance-, and placing into service processes. In general this will be a calendar day (According {{rml}} 2.2 format: yyyy-mm-dd).<br />
<br />
=== Ravel Connectivity ===<br />
Time-dependent changes in objects and (utilization) characteristics in many cases will have impact on their environment because these objects or characteristics have a relationship with other (unchanged) objects. These affected relationships (ravels) have to be restored.<br /><br />
When a complete dataset of a coherent area is replaced (according the above drawing) as a whole, these “ravels” occur on the borders of the area and are usually of various natures.<br />
<br />
{| class="wikitable"<br />
|-<br />
| In summary:<br /><br />
Ravel connectivity is the issue where changed topology or objects/phenomena inside an area (and its dataset) will require restoration of relationships with unchanged objects in its direct environment outside that area (in the drawing these areas are shown as demarcated excisions).<br />
|}<br />
<br />
This applies significantly for linear objects or -phenomena crossing the boundaries of new dataset(s) into the (invariant) data of the adjacent topology.<br /><br />
<br />
The simplest example of such an object in the topology is the trail in the micro-topology; but also the catenary or the set of demarcations of an operational point.<br /><br />
<br />
What can be the cause of ravels:<br /><br />
* Different time validities in one and the same cross-border relationship between two or more involved objects inside and outside an area. These relationships not only concern topology but a broad set of other domain data-items( see below which possible domains). This makes the ravel issue to a multi-disciplinary and a multi-dimension problem. <br />
<br />
*Multi-layer approach (= different thematic views) on infrastructure data:<br /> Excisions are made in one thematic view of the rail infrastructure (the one with the topology and the rail-technical constituents), while the characteristics of other thematic domains don’t fit correctly with the borders of the excision.<br /> For example: the rail-topology doesn’t have a 1:1 match with the catenary topology (energy domain). Also the interlocking objects (like TVD-sections) cover the rail-topology independent of the shape of the excision. The same holds for the safety system (signal-aspect relationships) and the routes.<br /><br />
<br />
In both cases there are derived data which are affected in the relationship between two (or more) objects: think for example the recalculation of intrinsic positions of objects on trails which cross the border(s) of changed area’s (excisions).<br /><br />
<br />
One can think of the next thematic layers in the (data) representation of the rail infrastructure:<br />
* Rail- & civil technical construction<br />
* Topology (schematic and geographical in more than 1 aggregation levels)<br />
* Utilization restriction/requirements (like RINF parameters)<br />
* Energy supply and re-routing scheme’s<br />
* Safety & detection system(s)<br />
* Traffic control (routes & route settings in coherence with safety)<br />
* Installation systems (network of substations, receptors and integrating computers)<br />
* Object registration in asset management <br />
<br />
All these layers are linked together in reality and have to be mutual consistent in data at any time, both inside an excision and all its cross border relationships regarding above entities.<br />
<br />
=== Complexity ===<br />
To avoid unnecessary complexity it is recommended '''NOT''' to solve ravel issues inside the exchange formats but in the applications and algorithms of the data management where it comes together.<br /><br />
<br />
This implies requirements for the exchange format itself: see notes in the paragraph below.<br />
<br />
=== Exchange format and file (XSD/XML) ===<br />
After the above analyses, the question arises how to cover a certain data extract in an exchange file (XML) and how to describe its structure elements (XSD).<br /><br />
<br />
An XML file exists globally of a header and a content partition.<br /><br />
<br />
In the header all types of references are mentioned. The content part contains the values of all requested parameters, well organized according their mutual dependencies and coherence.<br /><br />
<br />
With respect to the time dimension, the header can contain:<br /><br />
* time-stamp of the creation of the file, <br />
* the time-interval (FROM <time-stamp> TO <time-stamp>) that is used as selection criterion for the extraction of the content; this determines the data perspective of the exchange set.<br />
* the utterly expiration date for the content<br />
<br />
In the content we can distinguish between:<br />
* Per object:<br />
** Design date of its (functional) place holder (design reality).<br />
** Placing into service date of its physical realization<br />
** Current state: single selection from the list “concept, planned, under construction, in service, non-active, dismantled”. This goes along with the above mentioned dates.<br /> Note: states should not have time-overlap; also state transitions are bound to some business rules: follow the chain of the described list.<br />
** As far as known: end date(s) both for functional placeholder and physical realization<br />
* Notes:<br />
** If one constituent of a composite object is outside the time-interval (see header) but the other(s) are inside, it belongs as well to the set of the content (e.g. this can be the case if one node-port of a trail is outside (earlier creation date) but the other one is (newer) inside the time-interval.<br /> Even more (ravel connectivity): if an edge (trail or SoL) only partial passes the inside of an excision, where both end points (node-ports) of that edge are outside that excision, then this edge is part of the selection. See figure below in time frame t1.<br /> So the edge itself has to have a time validity, which on its turn has to be compliant with the time validity of the end points. This enables applications to solve ravel issues outside the exchange format on either side of the interface.<br /><br />
** Also the data-technical aspect of referential integrity has to be respected in the time dimension: internal object-references have to match according their common time frame. E.g.: a train of tomorrow should not refer to an OP that is dismantled (or non-active) since yesterday, although that OP is still in the source data set (including its validity limitations).<br />
** These ravel and referential-integrity problems arise especially in interlocking-, detection systems (TVD-sections)-, ERTMS-, and catenary phenomena. But also at the demarcation of tracks and trails.<br />
<gallery><br />
File:An edge (trail or SoL) only partially passes the inside of an excision.png|Edge passes partially the inside of an excision<br />
File:Object_Table.PNG|Object Table<br />
</gallery><br />
<br />
{{navi<br />
|chapter={{RTM}} Model Extensions<br />
|chapterlink=RTM Model Extensions<br />
|pchapter={{RTM}} Use Cases and Application Examples<br />
|pchapterlink=RTM Use Cases and Application Examples<br />
|next=Open issues<br />
|section=[[Planned extensions]]<br />
|subsection=Time Management aspects<br />
|snext=Meta Data / Quality data<br />
}}</div>
Ferri Leberl
http://wiki.railtopomodel.org/index.php?title=Planned_extensions&diff=904
Planned extensions
2017-03-13T13:52:03Z
<p>Ferri Leberl: Änderung Navi</p>
<hr />
<div>The model will be progressively enriched to support business usages.<br />
The next versions will include:<br />
* Multiple times (horizons, creation and modification dates, validity dates,…)<br />
* Projects, versions and life cycle management<br />
* Requirements for Signalling and Interlocking<br />
* …<br />
Following versions will also include:<br />
* Operational events<br />
* Traffic Management (commercial routes,…)<br />
* Asset Management<br />
* …<br />
<br />
== Time Management aspects ==<br />
{{main|Time Management aspects}}<br />
<br />
== Meta Data / Quality data ==<br />
{{main|Meta Data / Quality data}}<br />
<br />
== Inner track geometry (track alignment) ==<br />
{{main|Inner track geometry (track alignment)}}<br />
<br />
== ETCS ==<br />
{{main|ETCS}}<br />
<br />
{{navi<br />
|chapter={{RTM}} Model Extensions<br />
|chapterlink=RTM Model Extensions<br />
|pchapter={{RTM}} Use Cases and Application Examples<br />
|pchapterlink=RTM Use Cases and Application Examples<br />
|next=Open issues<br />
|snext=Time Management aspects<br />
}}</div>
Ferri Leberl
http://wiki.railtopomodel.org/index.php?title=RTM_Model_Extensions&diff=903
RTM Model Extensions
2017-03-13T13:47:24Z
<p>Ferri Leberl: Änderung Navi</p>
<hr />
<div>{{Overview|text=This page will concentrate on the {{rtm}} Model Extensions.}}<br /><br />
<br />
== Planned extensions ==<br />
{{main|Planned extensions}}<br />
<br />
== Open issues ==<br />
{{main|Open issues}}<br />
<br />
{{navi<br />
|chapter={{RTM}} Model Extensions<br />
|chapterlink=RTM Model Extensions<br />
|pchapter={{RTM}} Use Cases and Application Examples<br />
|pchapterlink=RTM Use Cases and Application Examples<br />
|section=<br />
|next=Planned extensions<br />
}}</div>
Ferri Leberl
http://wiki.railtopomodel.org/index.php?title=Netherlands:_ProRail_data_base&diff=902
Netherlands: ProRail data base
2017-03-13T13:42:59Z
<p>Ferri Leberl: Änderung Navi</p>
<hr />
<div>{{Overview|text=Lorem ipsum...}}<br /><br />
<br />
{{navi<br />
|chapter={{RTM}} Use Cases and Application Examples<br />
|chapterlink=RTM Use Cases and Application Examples<br />
|prev={{rml}} (Data Exchange)<br />
|prevlink=railML (Data Exchange)<br />
|pchapter={{RTM}} External References<br />
|pchapterlink=RTM External References<br />
|nchapter={{RTM}} Model Extensions<br />
|nchapterlink=RTM Model Extensions<br />
|section=[[Railway Infrastructure Manager Database]]<br />
|sprev=RINM<br />
|subsection=Netherlands: ProRail data base<br />
}}</div>
Ferri Leberl
http://wiki.railtopomodel.org/index.php?title=RINM&diff=901
RINM
2017-03-13T13:41:38Z
<p>Ferri Leberl: Änderung Navi</p>
<hr />
<div>* Purpose: General network description<br />
* Currently under development<br />
* Interfaces: xml and others (via FME)<br />
* Network graph based on track-centreline at micro level. Macro level being designed.<br />
<br />
<gallery><br />
File:RINM.PNG|RINM: One model, many views <br />
</gallery><br />
<br />
{{navi<br />
|chapter={{RTM}} Use Cases and Application Examples<br />
|chapterlink=RTM Use Cases and Application Examples<br />
|prev={{rml}} (Data Exchange)<br />
|prevlink=railML (Data Exchange)<br />
|pchapter={{RTM}} External References<br />
|pchapterlink=RTM External References<br />
|nchapter={{RTM}} Model Extensions<br />
|nchapterlink=RTM Model Extensions<br />
|section=[[Railway Infrastructure Manager Database]]<br />
|sprev=Banedata<br />
|subsection=RINM<br />
|snext=Netherlands: ProRail data base<br />
}}</div>
Ferri Leberl
http://wiki.railtopomodel.org/index.php?title=Banedata&diff=900
Banedata
2017-03-13T13:38:59Z
<p>Ferri Leberl: Änderung Navi</p>
<hr />
<div>* Purpose: General network description ans maintenance of infrastructure objects<br />
* Microscopic level<br />
* Interfaces: xml ({{rml}}), csv, xls; {{rml}} interface is intended<br />
* One common database containing information about all infrastructure objects (also in binary formats, e.g. drawings)<br />
<br />
{{navi<br />
|chapter={{RTM}} Use Cases and Application Examples<br />
|chapterlink=RTM Use Cases and Application Examples<br />
|prev={{rml}} (Data Exchange)<br />
|prevlink=railML (Data Exchange)<br />
|pchapter={{RTM}} External References<br />
|pchapterlink=RTM External References<br />
|nchapter={{RTM}} Model Extensions<br />
|nchapterlink=RTM Model Extensions<br />
|section=[[Railway Infrastructure Manager Database]]<br />
|sprev=InfraNet<br />
|subsection=Banedata<br />
|snext=RINM<br />
}}</div>
Ferri Leberl
http://wiki.railtopomodel.org/index.php?title=InfraNet&diff=899
InfraNet
2017-03-13T13:37:01Z
<p>Ferri Leberl: Cleanup</p>
<hr />
<div>{{Overview|text=Lorem ipsum...}}<br /><br />
<br />
* Purpose: General network description<br />
* Interfaces: xml<br />
* Specialty: Topology graph with node, each node has a detailed graph describing the driveable paths and is connected to the outside via ports<br />
<br />
<gallery><br />
File:Infranet1.PNG|InfraNet: Different levels of detail<br />
File:Infranet2.PNG|InfraNet: Vision transversale<br />
</gallery><br />
<br />
{{navi<br />
|chapter={{RTM}} Use Cases and Application Examples<br />
|chapterlink=RTM Use Cases and Application Examples<br />
|prev={{rml}} (Data Exchange)<br />
|prevlink=railML (Data Exchange)<br />
|pchapter={{RTM}} External References<br />
|pchapterlink=RTM External References<br />
|nchapter={{RTM}} Model Extensions<br />
|nchapterlink=RTM Model Extensions<br />
|section=[[Railway Infrastructure Manager Database]]<br />
|sprev=France: ARIANE<br />
|subsection=InfraNet<br />
|snext=Banedata<br />
}}</div>
Ferri Leberl
http://wiki.railtopomodel.org/index.php?title=InfraNet&diff=898
InfraNet
2017-03-13T13:36:14Z
<p>Ferri Leberl: Änderung Navi</p>
<hr />
<div>{{Overview|text=Lorem ipsum...}}<br /><br />
<br />
* Purpose: General network description<br />
* Interfaces: xml<br />
* Specialty: Topology graph with node, each node has a detailed graph describing the driveable paths and is connected to the outside via ports<br />
<br />
<gallery><br />
File:Infranet1.PNG|InfraNet: Different levels of detail<br />
File:Infranet2.PNG|InfraNet: Vision transversale<br />
</gallery><br />
<br />
<br />
{| class="wikitable"<br />
|-<br />
| '''What you should have learned'''<br /><br />
Lorem ipsum...<br />
* <br />
* Bulleted list item<br />
|}<br />
<br />
<br />
{| class="wikitable"<br />
|-<br />
! Back To !! Previous Chapter !! Next Chapter<br />
|-<br />
| [[Railway Infrastructure Manager Database]] || [[France: ARIANE]] || [[Banedata]]<br />
|}<br />
<br />
{{navi<br />
|chapter={{RTM}} Use Cases and Application Examples<br />
|chapterlink=RTM Use Cases and Application Examples<br />
|prev={{rml}} (Data Exchange)<br />
|prevlink=railML (Data Exchange)<br />
|pchapter={{RTM}} External References<br />
|pchapterlink=RTM External References<br />
|nchapter={{RTM}} Model Extensions<br />
|nchapterlink=RTM Model Extensions<br />
|section=[[Railway Infrastructure Manager Database]]<br />
|sprev=France: ARIANE<br />
|subsection=InfraNet<br />
|snext=Banedata<br />
}}</div>
Ferri Leberl
http://wiki.railtopomodel.org/index.php?title=France:_ARIANE&diff=897
France: ARIANE
2017-03-13T13:34:25Z
<p>Ferri Leberl: Änderung Navi</p>
<hr />
<div>{{Overview|text=Lorem ipsum...}}<br /><br />
{{Missing information}}<br />
* Purpose: General network description <br />
* Interfaces: text, json, xml<br />
* ARIANE Model: Connectivity graph (dual graph)<br /><br />
GAIA Database: One unique common database for all French railway businesses and activities. Multilevel and aggregation (tracks, lines, corridors, ...), supports technical components and characteristics, physical paths and logical routes, includes natively multi-referencing (geo, linear) and geometry, time scales and business segmentations.<br />
<br />
{{navi<br />
|chapter={{RTM}} Use Cases and Application Examples<br />
|chapterlink=RTM Use Cases and Application Examples<br />
|prev={{rml}} (Data Exchange)<br />
|prevlink=railML (Data Exchange)<br />
|pchapter={{RTM}} External References<br />
|pchapterlink=RTM External References<br />
|nchapter={{RTM}} Model Extensions<br />
|nchapterlink=RTM Model Extensions<br />
|section=[[Railway Infrastructure Manager Database]]<br />
|sprev=Register of Infrastructure (RINF)<br />
|subsection=France: ARIANE<br />
|snext=InfraNet<br />
}}</div>
Ferri Leberl
http://wiki.railtopomodel.org/index.php?title=Register_of_Infrastructure_(RINF)&diff=896
Register of Infrastructure (RINF)
2017-03-13T13:32:16Z
<p>Ferri Leberl: Änderung Navi</p>
<hr />
<div>{{Overview|text=Lorem ipsum...}}<br /><br />
<br />
The Register of Infrastructure (RINF) provides a general description of the rail networks witihin EU 28. National Register Entities (NRE) are requested to submit quarterly rail infrastructure data to ERA.<br />
<br />
It uses a common XML interface and is currently under construction.<br />
<br />
It supports routing at micro and macro level and makes use of both the Linear Reference System and the GPS Coordinate System.<br />
<br />
* Member State dataset with validity period<br />
<br />
<gallery><br />
File:RINFModeling.PNG|RINF: Modeling<br />
File:RINFTrackConnection.PNG|RINF: Track connection on micro level<br />
</gallery><br />
<br />
{{navi<br />
|chapter={{RTM}} Use Cases and Application Examples<br />
|chapterlink=RTM Use Cases and Application Examples<br />
|prev={{rml}} (Data Exchange)<br />
|prevlink=railML (Data Exchange)<br />
|pchapter={{RTM}} External References<br />
|pchapterlink=RTM External References<br />
|nchapter={{RTM}} Model Extensions<br />
|nchapterlink=RTM Model Extensions<br />
|section=[[Railway Infrastructure Manager Database]]<br />
|subsection=Register of Infrastructure (RINF)<br />
|snext=France: ARIANE<br />
}}</div>
Ferri Leberl
http://wiki.railtopomodel.org/index.php?title=Railway_Infrastructure_Manager_Database&diff=895
Railway Infrastructure Manager Database
2017-03-13T13:29:22Z
<p>Ferri Leberl: Änderung Navi</p>
<hr />
<div>{{Overview|text=Lorem ipsum...}}<br /><br />
== Register of Infrastructure (RINF) ==<br />
[[Register of Infrastructure (RINF)]]<br />
<br />
== France: ARIANE ==<br />
[[France: ARIANE]]<br />
<br />
== InfraNet ==<br />
[[InfraNet]]<br />
<br />
== Banedata ==<br />
[[Banedata]]<br />
<br />
== RINM ==<br />
[[RINM]]<br />
<br />
== Netherlands: ProRail data base ==<br />
[[Netherlands: ProRail data base]]<br />
<br />
{{navi<br />
|chapter={{RTM}} Use Cases and Application Examples<br />
|chapterlink=RTM Use Cases and Application Examples<br />
|prev={{rml}} (Data Exchange)<br />
|prevlink=railML (Data Exchange)<br />
|pchapter={{RTM}} External References<br />
|pchapterlink=RTM External References<br />
|nchapter={{RTM}} Model Extensions<br />
|nchapterlink=RTM Model Extensions<br />
|snext=Register of Infrastructure (RINF)<br />
}}</div>
Ferri Leberl
http://wiki.railtopomodel.org/index.php?title=RailML_(Data_Exchange)&diff=894
RailML (Data Exchange)
2017-03-13T13:24:00Z
<p>Ferri Leberl: Änderung Navi</p>
<hr />
<div>{{Overview|text=This page describes the relation between {{rtm}} as model and {{rml}} as exchange format.}}<br /><br />
<br />
Very closely related to the evolution of the {{rtm}} is the work done by members of railML.org. <br />
{{rml}} is an open-source XML-based data exchange format for IT applications in railways. {{rml}} is developed and maintained by the railML.org initiative and it has been published so far up to version 2.3. Currently, railML.org is actively contributing to the UIC {{rtm}} Expert Group with the objective to base its new version, {{rml}} 3, on the fundament of the {{rtm}}. Thus, {{rml}} 3.0 can be considered to being the exchange format for any infrastructure data base following the {{rtm}} concept. The current state of development of {{rml}} 3 is described on the website besides infrastructure, {{rml}} is also able to handle information about timetable, rolling stock and interlocking. Thus, being a widely applicable data exchange format, {{rml}} is used by many railways, manufacturers and other institutions for internal and external data exchange. <br />
Further information on {{rml}} can be found at https://www.railml.org.<br /><br />
<br /><br />
Considering the work done by the {{rml}} initiative project in co-operation with this modelling work, there are currently two products available to facilitate the exchange of data in the domain of railway infrastructure.<br /><br />
{| class="wikitable"<br />
|-<br />
| Logical model || '''The {{rtm}}''' is a generic railway data model designed to support current and future business needs. It is particularly useful for: <br /><br />
* Engineering activities - mainly based on installations and components, and<br /><br />
* Circulation activities - mainly based on routing and scheduling.<br />
|-<br />
| {{rml}} || '''{{rml}} 3''' is the latest evolution of the format created by railML.org. {{rml}} 3 was specifically developed to be compliant to the UIC's {{rtm}}.<br />
|}<br />
<br />
Thus, {{rml}} can be viewed as the first benefit of {{rtm}}. Figure 2 summarises the role that {{rtm}} and {{rml}} would play when fully integrated in existing systems.<br /><br />
<br />
Investing in a standardised railway data exchange format will provide multiple benefits for the sector, including:<br /><br />
<br />
* Improved data quality,<br />
* More efficient business performance,<br />
* Streamlined and re-usable development,<br />
* Integrated IT systems, and<br />
* Return on investments.<br /><br />
<br />
Detailed Information about {{rml}} can be found on the {{rml}} website at http://www.railML.org.<br />
<br />
{{navi<br />
|lesson=<br /><br />
* Difference between {{rtm}} and {{rml}}<br />
* Aim of {{rml}} and http://railML.org<br />
* What you can do with {{rtm}} and {{rml}}<br />
|chapter={{RTM}} Use Cases and Application Examples<br />
|chapterlink=RTM Use Cases and Application Examples<br />
|next=Railway Infrastructure Manager Database<br />
|pchapter={{RTM}} External References<br />
|pchapterlink=RTM External References<br />
|nchapter={{RTM}} Model Extensions<br />
|nchapterlink=RTM Model Extensions<br />
|section=[[{{PAGENAME}}|{{rml}} (Data Exchange)]]<br />
}}</div>
Ferri Leberl
http://wiki.railtopomodel.org/index.php?title=RTM_use_cases_and_application_examples&diff=893
RTM use cases and application examples
2017-03-13T13:19:09Z
<p>Ferri Leberl: Änderung Navi</p>
<hr />
<div><strong>This page will concentrate on the {{rtm}} Use Cases and Application Examples.</strong><br />
<br />
The following use cases were identified and structured in a general framework.<br />
<br />
{| class="wikitable"<br />
|-<br />
! Interfaces\Field !! Technical !! Operational !! Legal<br />
<br />
|-<br />
| '''Internal''' between departments <br />
|| Standardised data exchange between technical departments (e.g. engineering + capacity allocation) often using different IT technologies and definitions<br /><br />
&rArr; synergy effects<br />
|| Standardised data exchange between planning and monitoring of operations e.g. timetabling and real-time circulation tracking<br /><br />
&rArr; synergy effects <br />
|| Improved monitoring of the network condition, via dedicated 'Dashboards' providing network data summaries<br /><br />
&rArr; easier & faster data transfer and processing<br />
<br />
|-<br />
| '''National/Business''' between partners <br />
|| Standardised data exchange between IMs and their business partners, such as ETCS suppliers and maintenance sub-contractors<br /><br />
&rArr; savings in data production and transmission<br /><br />
&rArr; less vendor lock-in<br />
|| Standardised data exchange between IMs and RUs (e.g. for track possessions).<br /><br />
&rArr; reduced operational costs<br /><br />
<br /><br />
Standardised <u>inter</u>modal communications<br /> <br />
&rArr; enhanced railway market share <br />
|| Ability of RUs to determine permissible train characteristics (esp. braking) on any infrastructure, as required by EU legislation (esp. TSI OPE)<br /><br />
&rArr; time savings, less errors<br /><br />
<br /><br />
Standardised data provision to national administrations such as land registers, regions, ministries. (Example: multiannual MS-IM contract as per 2012/34, art. 8 and 30)<br /><br />
&rArr; improved quality; scalable level of detail; improved credibility of rail<br />
<br />
|-<br />
| '''International''' between countries, organisations, EU <br />
|| Standardised data model/exchange on which ETCS-, IT- and other industries can design their products<br /><br />
&rArr; from taylor-made to <u>in</u>expensive mass market solutions <br />
|| Standardised data exchange within corridors and between organisations (RNE, ...)<br /><br />
&rArr; no need to develop multiple data conversion interfaces<br /><br />
<br /><br />
Information exchange concerning station accessibility<br /><br />
&rArr; contribution to TSI PRM objectives<br />
|| Standardised/unique data provision to legal obligations; NS, RINF, Inspire, EU Freight corridors, TEN-T network<br /><br />
&rArr; Savings in data conversions and reduction of administrational burden<br />
|}<br />
== {{rml}} (Data Exchange) ==<br />
{{main|railML (Data Exchange)|{{rml}} (Data Exchange)}}<br />
<br />
== Railway Infrastructure Manager Database ==<br />
{{main|Railway Infrastructure Manager Database}}<br />
Many different topological infrastructure data models and interfaces have been created over the years, either to fulfill railway needs or to support EU directives. Indeed, in the absence of any commonly agreed standard for (international) data exchange each railway or EU initiative has been obliged to create its own data model and interface, often from scratches. Subsequently IMs are constantly requested to convert their data according to these different interfaces and data usages generating poor data quality and high data management costs. <br /><br />
<br /><br />
Several topological data models have been investigated to understand their converging and diverging points. This analysis provides the basic understanding of the current state-of-art and the feasibility of a common data model in the future.<br /><br />
<br /><br />
The following models have been considered in a more detailed manner: <br /><br />
* [[Register of Infrastructure (RINF)|RINF (ERA)]]<br />
* [[France: ARIANE|ARIANE (SNCF Réseau, France)]]<br />
* [[InfraNet|InfraNet (Infrabel, Belgium)]]<br />
* [[Banedata|Banedata (Jernbaneverket, Norway)]]<br />
* [[RINM|RINM (Network Rail, United Kingdom)]]<br />
* [[Netherlands: ProRail data base|ProRail Database (Netherlands)]]<br />
<br />
{{navi<br />
|chapter={{RTM}} Use Cases and Application Examples<br />
|chapterlink=RTM Use Cases and Application Examples<br />
|next={{RML}} (Data Exchange)<br />
|nextlink=RailML (Data Exchange)<br />
|pchapter={{RTM}} External References<br />
|pchapterlink=RTM External References<br />
|nchapter={{RTM}} Model Extensions<br />
|nchapterlink=RTM Model Extensions<br />
|section=<br />
}}</div>
Ferri Leberl
http://wiki.railtopomodel.org/index.php?title=Geographical_borders&diff=892
Geographical borders
2017-03-13T13:15:48Z
<p>Ferri Leberl: Änderung Navi</p>
<hr />
<div>{{Overview|text=Lorem ipsum...}}<br /><br />
<br />
<br />
{{navi<br />
|chapter={{RTM}} External References<br />
|chapterlink=RTM External References<br />
|nchapter={{RTM}} Use Cases and Application Examples<br />
|nchapterlink=RTM Use Cases and Application Examples<br />
|pchapter={{rtm}} Modelling Concepts<br />
|pchapterlink=RTM Modelling Concepts<br />
|prev=Transport mode borders<br />
}}</div>
Ferri Leberl
http://wiki.railtopomodel.org/index.php?title=Transport_mode_borders&diff=891
Transport mode borders
2017-03-13T13:14:32Z
<p>Ferri Leberl: Änderung Navi</p>
<hr />
<div>{{Overview|text=Lorem ipsum...}}<br /><br />
<br />
<br />
<br />
{{navi<br />
|chapter={{RTM}} External References<br />
|chapterlink=RTM External References<br />
|nchapter={{RTM}} Use Cases and Application Examples<br />
|nchapterlink=RTM Use Cases and Application Examples<br />
|pchapter={{rtm}} Modelling Concepts<br />
|pchapterlink=RTM Modelling Concepts<br />
|next=geographical borders<br />
}}</div>
Ferri Leberl
http://wiki.railtopomodel.org/index.php?title=Borders_of_RTM&diff=890
Borders of RTM
2017-03-13T13:12:10Z
<p>Ferri Leberl: Änderung Navi</p>
<hr />
<div>{{Overview|text=This page will concentrate on the Borders of {{rtm}}, i.e. its environment in the field of transport policies and standardization.}}<br /><br />
<br />
== Related initiatives, norms and standards ==<br />
* '''Transmodel'''<br />
Transmodel is a European standard data model for public transport, designed to cover multiple transportation means (bus, tramway, trains…) in terms of interoperability, and the places where they meet each-other (e.g. stations, cities, towns, villages). The aim is to support operations, and more precisely schedule and journey planning. <br /><br />
<br />
* '''Inspire'''<br />
INSPIRE is a European directive which aims to create spatial data infrastructure for the European Union (EU). This will enable the sharing of environmental spatial information among public sector organisations and better facilitate public access to spatial information across Europe.<br /><br />
<br />
* '''IFOPT''' <br />
IFOPT means "Idenification of fixed objects in public transport". IFOPT (EN28701) is an approved Technical Standard for location referencing in public transport.<br />
<br />
* '''SIRI''' <br />
The Service Interface for Real time Information covers transit communications between centres, and centre’s transit vehicles. SIRI provides traveller information on real-time transit vehicle location, predicted transit vehicle arrival/departure time, and predicted transit trip travel time.<br />
<br />
* '''TransXChange''' <br />
UK national XML based data standard for the interchange of bus route and timetable information between bus operators, the Vehicle and Operator Services Agency, local authorities and passenger transport executives, and others involved in the provision of passenger information.<br />
<br />
* '''NeTEx''' <br />
Network and Ticketing Exchange protocol for communicating timetable and fares details.<br />
<br />
* '''TRIDENT''' <br />
TRansport Intermodality Data sharing and Exchange NeTwork. Standard exchange data format for multimodal interoperability between RUs and service providers.<br />
<br />
* '''DJPS''' <br />
Exposed interface standard for distributed journey planning systems.<br />
<br />
== Transport mode borders ==<br />
{{main|Transport mode borders}}<br />
The IFOPT standard (see above) is an attempt to describe the connections between transport modes. As its acronym tells it, IFOPT deals with physical connections (interchange, etc.) rather than timetables for instance. See also:<br />
[[Transport mode borders]] (in progress).<br />
<br />
== Geographical borders ==<br />
{{main|Geographical borders}}<br />
<br />
{{navi<br />
|chapter={{RTM}} External References<br />
|chapterlink=RTM External References<br />
|nchapter={{RTM}} Use Cases and Application Examples<br />
|nchapterlink=RTM Use Cases and Application Examples<br />
|pchapter={{rtm}} Modelling Concepts<br />
|pchapterlink=RTM Modelling Concepts<br />
|next=Transport mode borders<br />
|section=<br />
}}</div>
Ferri Leberl
http://wiki.railtopomodel.org/index.php?title=Object_positioning_in_the_network&diff=889
Object positioning in the network
2017-03-13T13:03:49Z
<p>Ferri Leberl: Änderung Navi</p>
<hr />
<div>{{Overview|text=The {{rtm}} allows for all railway-related physical or logical objects an exact and unique positioning on the network. The generic class EntityLocation holds the necessary positioning information and serves as a connection to the network.}}<br /><br />
The {{rtm}} data structure is organized around the network. The '''Network''' is used as the main reference system for positioning of arbitrary information objects. This layer allows the user to project objects and entities on the topology, by referencing topology elements. <br />
* The network is built of '''NetElements'''<br />
* Objects like infrastructure assets can be located on the network as '''NetEntities'''<br />
<br />
<br />
== Net Entities and Entity Locations ==<br />
To define all types of entity, a generic class is defined: '''NetEntity'''. This class defines a general relation with a shared location to define the position on the network. The location of each entity on the network is defined using the intrinsic position of NetElement. <br />
NetEntities, specialised as '''LocatedNetEntities''', are located by assigning '''EntityLocations''' to them. An EntityLocation connects an Entity to the Network via one or more '''PositioningNetElement'''s.<br />
<br />
The figure below shows different examples of infrastructure assets that are located in the railway topology network as net entities.<br />
<br />
<gallery><br />
File:ObjectTypes.png|Object Types (© InfraBel)<br />
</gallery><br />
<br />
Each '''NetEntity''' instance possesses an unspecified number of '''EntityLocation''' instances. Each EntityLocation instance is specialised as one of three types used to locate different types of NetEntities on the network: <br />
# '''SpotLocation''': used for information objects happening at a point (e.g.: signals, buffer stops, ETCS balise, etc. - see number 1 in previous example)<br />
# '''LinearLocation''': used for information objects happening along a path (e.g.: platform, speed limit, ballast renewal, etc. - see number 2 in previous example)<br />
# '''AreaLocation''': used for information objects happening on a sub network (e.g.: catenary cases, track circuits zones, switches, stations, tunnels, bridges, etc. - see number 3 in previous example)<br />
The following figure shows the {{rtm}} class model for net entity locations.<br />
<br />
<gallery><br />
File:LocationsLU.png|NetEntity Locations (Language Unit)<br />
</gallery><br />
<br />
A NetEntity can have more than one EntityLocation in the Network. Consider the following examples:<br />
* An object can be located in the railway network via a positioning system, and additionally via an intrinsic positioning. See later explanations<br />
* A level crossing of two tracks is located on each of those tracks by (at least) one SpotLocation.<br />
* A switch has an AreaLocation (see picture), but can as well be located at its branching point by a SpotLocation<br />
* A station on the micro level of the network is represented by an AreaLocation. On the macro level it is condensed as operational point to a single topological node (nonlinear NetElement) and therefore is assigned a SpotLocation.<br />
The last two examples show that a consequent classification of NetEntities into three types, '''Spot Entity''', '''Linear Entity''' and '''Areal Entity''' is not always possible. <br />
<br />
<br />
== Relating EntityLocations to the Network ==<br />
<br />
The three types of EntityLocations are related in different ways to the network. Using an '''AreaLocation''' instance for connecting to the network means that the "NetEntity" in question is related to a subset of "NetElement" instances which together resemble an area or a sub-network. <br/><br />
A connection based on a '''LinearLocation''' instance means that the "NetEntity" in question is a path related to a linear segment of the network.<br/><br />
A connection based on a '''SpotLocation''' means that the "NetEntity" in question is either related to a nonlinear NetElement building block of the network or it is related to a specified position on a linear NetElement. <br />
<br /><br />
<br />
{| class="wikitable"<br />
|-<br />
| '''Note''' that - with reference to ''NetElements'' - the terms ''linear'' or ''nonlinear'' are used for illustration only. In the {{rtm}} network, there are only NetElements and Relations. You can imagine a nonlinear NetElement as a "node" and a linear NetElement as an "edge" to get a better understanding, but it will make no difference in the topology or the positioning of NetEntities.<br />
|}<br />
<br />
=== SpotLocation ===<br />
<br />
An entity can be located via a ''SpotLocation'' either at a nonlinear element or along a section of rail/section of line (linear element) at a certain distance.<br/><br />
If it is located at a nonlinear element, it can be interpreted as happening "in" the element (regardless the orientation). In this case, it encompasses the whole nonlinear element. Otherwise, it happens with respect to some relation of the nonlinear element (exit or entry via another net element, for example from an adjacent track edge X). It should then be located using a ''SpotLocation'' on the adjacent linear net element.<br/><br />
The following figure shows an example where a signal is located in the center of the linear net element A via a ''SpotLocation''.<br />
<br />
<gallery><br />
File:SpotLocationModified.PNG|SpotLocation Example (© InfraBel, DB Netz)<br />
</gallery><br />
<br />
If a ''NetEntity'' is situated somewhere along a track edge (linear net element) at a certain distance from the start, it is further necessary to define the lateral offset and the application direction. In particular, it has to be clarified whether the entity happens directly on the track edge, or somewhere left or right of the track edge with respect to its orientation; and if the entity occurs in both directions or only in one. For example: a conventional railway signal is located either left of right of (or above) the track and it is valid for only one direction of travel. <br />
<br />
Further, it is possible to have more than one ''SpotLocation'' for some spot entities: <br />
# Multiple location (on multi-track) on the network for the same hierarchical level (micro, macro, etc.).<br />
# Multiple location, because the entity is located on different levels.<br />
The following example may show the location of a clearing post. While the position of the clearing post is somewhere in the middle between the two tracks (not depicted), its application points exist on both tracks (linear elements E and F) that are going to join in the nonlinear net element D. Thus, the clearing post element has two spot locations on the same hierarchical level.<br />
<br />
<gallery><br />
File:MultipleSpotLocation.png|Example multiple spot location (© InfraBel)<br />
</gallery><br />
<br />
In terms of {{rtm}}, a ''SpotLocation'' is related to exactly one ''PositioningNetElement'', which could be either nonlinear or linear. This means that the ''NetEntity'' in question is located on this ''NetElement'' and its applicationDirection refers to the NetElement’s orientation. The exact localization of the SpotLocation is given depending which of two types it belongs to:<br />
<br />
<gallery><br />
File:SpotLocationLU.png|SpotLocation (Language Unit)<br />
</gallery><br />
<br />
===== SpotLocationCoordinate =====<br />
A ''SpotLocation'' of this type is related to a ''PositioningSystemCoordinate'' that refers to a specific ''PositioningSystem''. This is either a ''LinearPositioningSystem'' or a ''GeometricPositioningSystem''. The ''PositioningSystemCoordinate'' provides the exact position of the ''SpotLocation'' in the referenced coordinate system.<br />
<br />
===== SpotLocationIntrinsic =====<br />
A ''SpotLocationIntrinsic'' carries the intrinsicCoordinate in reference to the chosen ''PositioningNetElement'', as a value between 0 and 1.<br />
<br/><br />
In the spot location example from the begin of the chapter, we see a ''SpotLocation'' for a railway signal on linear ''NetElement'' A. The applicationDirection in this case is "reverse", since the signal is valid in direction 1 to 0 on A. The ''NetEntity'' of the signal "happens" at a certain distance left from the endpoint A1. As a ''SpotLocationIntrinsic'' its intrinsicCoord is 0.5. As a ''SpotLocationCoordinate'' its external coordinate is X in a referenced positioning system.<br />
<br/><br />
<br />
=== LinearLocation ===<br />
<br />
Many ''NetEntity'' instances can be seen as paths. For example, a platform edge is a linear infrastructure asset, and also track circuits or axle-counting circuits can be seen as linear installations in the railway track network. The following figure may show the axle-counting circuit example.<br />
<br />
<gallery><br />
File:LinearLocationExample.png|LinearLocation Example (© InfraBel)<br />
</gallery><br />
<br />
To describe a path or linear location, a start point, an end point and an ordered list of every encompassed element, is needed.<br/><br />
The start and end points are point locations, thus either a nonlinear element or a point along a linear element (track edge). The path should be a topological path, meaning that at each nonlinear element only one exit direction can be taken. If the start- or end point is a nonlinear element, this element is fully encompassed within the path.<br/><br />
The correct ordering of the list should be checked against the topology definition of the network. This could be the task of a validator. The orientation of the path on each track edge can be deduced from the order of the crossed nonlinear elements.<br />
Path locations in {{rtm}} are located by instances of the class type ''LinearLocation''.<br />
<br />
<gallery><br />
File:LinearLocationLU.png|LinearLocation (Language unit)<br />
File:OrderedAssociatedNetElement.png|class diagram OrderedAssociatedNetElement<br />
</gallery><br />
<br />
A ''LinearLocation'' is defined by an ordered sequence of '''AssociatedNetElements'''. Each ''AssociatedNetElement'' refers to a linear or nonlinear ''PositionedNetElement''. It either encompasses the whole ''NetElement'' or a section at the beginning or end of the linear ''NetElement'' (or an arbitrary section in case there is only one AssociatedNetElement) <br/><br />
The beginning and end of the sections of ''AssociatedNetElements'' are given in intrinsic coordinates (between 0 and 1) with respect to the related ''PositioningNetElement''. The parameter keepsOrientation defines if the ''AssociatedNetElement'' is oriented along the direction of the NetElement or in reverse direction.<br/><br />
The ''AssociatedNetElements'' have to be oriented all in the same direction, from the start to the end of the sequence. They form a connected path in the network without gaps or branches. <br/><br />
<br />
The position of the ''LinearLocation'' instance within the network itself is now complete. Additionally, more positioning systems can be used for the respective entity. If the ''LinearLocation'' is a ''LinearLocationCoordinate'', it can be assigned a position with respect to an external – linear or geometric – PositioningSystem.<br/><br />
The following figure shows how the intrinsic coordinates are used to reference begin and end coordinates of the linear element.<br />
<br />
<gallery><br />
File:LinearLocationModified.png|AssociatedNetElements for linear location (© InfraBel, DB Netz)<br />
</gallery><br />
<br />
In particular, the example shows the ''LinearLocation'' and its ''AssociateNetElements'' with respect to the underlying ''NetElements''. When writing this sequence as ordered list of NetElement segments, the results looks as follows: <br />
<br />
{| class="wikitable"<br />
|-<br />
! Nr !! AssociatedNetElement !! netElement !! intrinsicCoordBegin !! intrinsicCoordEnd !! keepsOrientation<br />
|-<br />
| 1 || A' || A || 0.7 || 1 || true<br />
|-<br />
| 2 || B' || B || 0 || 0 || n/a (nonlinear)<br />
|-<br />
| 3 || C' || C || 0 || 1 || true<br />
|-<br />
| 4 || D' || D || 0 || 0 || n/a (nonlinear)<br />
|-<br />
| 5 || E' || E || 0 || 0.8 || true<br />
|}<br />
<br />
'''Remark:''' In this example, all the underlying linear ''NetElements'' are oriented in the same direction, as can be seen by the positions of their intrinsic coordinates 0 and 1. In case that a linear ''NetElement'' instance, say E, were oriented in the other direction, the ''AssociatedNetElement'' instance E’ would have to be defined by intrinsicCoordBegin = 0.2, intrinsicCoordEnd = 1 and keepsOrientation = false. <br />
<br />
=== AreaLocation (SubNetwork) ===<br />
<br />
An area location can be seen as aggregated location that comprises spot locations and several linear locations in an unordered sequence. The example shown in the following figure may be a more realistic representation of an axle-counting circuit.<br />
<br />
<gallery><br />
File:AreaLocationExample.png|AreaLocation Example (© InfraBel)<br />
</gallery><br />
<br />
An areal object is an object represented by a subgraph (a continuous fraction of the network), that is comprehended as an object. The name "areal object" indicates that most practical examples resemble an area in reality. The respective ''AreaLocation'' is this subgraph or sub-network. Another example for an area location is the track network belonging to a station or a shunting yard.<br/><br />
<br />
<gallery><br />
File:AreaLocationLU.png|AreaLocation (Language Unit)<br />
</gallery><br />
<br />
An ''AreaLocation'' is defined analogously to spot- and linear entity locations, by listing the ''AssociatedNetElement'' instances of the location, with a pair of positions (beginning and end in intrinsic reference on the respective ''PositionedNetElement'' instance) for all ''AssociatedNetElements''.<br/><br />
The difference to ''LinearLocation'' is that the set of ''AssociatedNetElements'' does not have to be ordered and can have different orientations. Further there can be branches within the subgraph<br />
<br />
As in the case of ''LinearLocations'', if a nonlinear element is included in the collection of ''AssociatedNetElements'', then the whole element is included. The collection can include sections of linear elements, defined by their intrinsic begin and end coordinate. It must be checked that the objects included in the areal location form a connected subgraph (no independent parts) and that no object is listed twice. <br/><br />
<br />
<gallery><br />
File:AreaLocationModified.PNG|AssociatedNetElements for the above AreaLocation (© InfraBel, DB Netz)<br />
</gallery><br />
<br />
The ''AreaLocation'' in the example contains 8 ''AssociatedNetElement'' instances. Note that element E is fully included in E’, but not the adjacent nonlinear NetElement (node) in the network. The track edges A and G are oriented reverse to each other, which does not matter in an ''AreaLocation''. <br/><br />
<br />
{{navi<br />
|lessin=<br><br />
You should be able to<br />
* identify spot-, linear and areal objects in your network and chose the appropriate EntityLocation type(s) for them<br />
* understand the connection of EntityLocations to the network via intrinsic positioning<br />
* ...at last answer the question "where is...?" for every object related to a position in your railway network.<br />
|chapter={{RTM}} modelling concepts<br />
|chapterlink=RTM modelling concepts<br />
|prev=Positioning<br />
|pchapter={{rtm}} Quick Start<br />
|pchapterlink=RTM Quick Start<br />
|nchapter={{rtm}} External References<br />
|nchapterlink=RTM External References<br />
}}</div>
Ferri Leberl
http://wiki.railtopomodel.org/index.php?title=Positioning&diff=888
Positioning
2017-03-13T13:00:04Z
<p>Ferri Leberl: Änderung Navi</p>
<hr />
<div>== Coordinate positioning ==<br />
[[Coordinate positioning]]<br />
== Linear Positioning / referencing ==<br />
Linear Referencing Systems (LRS) are widely used in the transportation world. They allow specifying positions along linear elements by using distances measured along the element (possibly with a lateral and horizontal offset), not by using classical 2D or 3D coordinating systems (CRS). <br /><br />
<br />
Locating an object with linear coordinates makes sense for various reasons. First of all, a large amount of information is stored in databases from legacy systems, anterior to geographical information systems which are specifically designed to deal with classical CRS. Knowing where an object is located along a route or a pipeline is sufficient to use the data from those databases, and can be seen as an integration mean for data coming from different sources. <br /><br />
<br />
It is even sometimes more interesting to have a linear position than a spatial position. Knowing that you have train stopped at about the kilometre 45 on the Line 36 Track A is better than having a potentially more accurate GPS position, which does neither tell without ambiguity on which line nor track it stands.<br />
<br />
=== Norms ===<br />
Linear Referencing is the object of the European Norm EN19148:2012. <br /><br />
<br />
The {{rtm}} follows the same principles, but uses a simplified version of the model as a lot of cases foreseen in the norm are not encountered in the railways world.<br />
<br /><br />
=== Axis ===<br />
A linear referencing system has an axis along which the measures are done. The axis can be any linear entity, a track segment or a whole line. It does not need to have geometry as knowing its length is enough to use an LRS.<br />
=== Referencing Methods===<br />
<br />
A Linear Referencing System may use several methods to describe a position along an axis: <br />
* '''Absolute''' : the position is specified by giving the distance starting at the beginning of the axis (with an eventual offset)<br />
<br />
[[File:ReferencingMethods Absolute.png|ReferencingMethodAbsolute]]<br />
<br />
Its main disadvantage is the fact that the whole length of the axis is taken into account when measuring. It means :<br />
# that the field workers always have to begin measurement at the start of the axis. It makes it unpractical for long axes,<br />
# that each change happening in the axis before the referenced object changes the coordinate of the measured point.<br />
It is thus only suitable for short axes, or axes which are very stable in the scope of the measurement. <br />
<br />
*'''Relative''' : The position is specified by giving the distance starting from an element (referent) whose position is known.<br />
<br />
[[File:ReferencingMethods Relative.png|ReferencingMethodRelative]]<br />
<br />
This is the most commonly used in railways, with mileposts as referents. Amongst its advantages is the stability of the coordinate which is now independent from works or axis changes happening before the referent, unless the change also affects the referent.<br /><br />
It is also more practical for the field workers as the measurement only has to start at the referent. <br /><br />
On the other hand, it forces to maintain a whole set of referents, ensuring they never move, and recalculating their position at each infrastructure change.<br /><br />
It makes it most suitable for long axes, such as lines, but poorly adapted to short segments (work reservations or sidings).<br /><br />
<br />
While it is possible to measure in both directions, (km x + y meters or km x+1 – z meters), the former method is the most widely used.<br /><br />
<br />
It is also the most suited to store long term information, because of the stability of the coordinates. However, it is very poorly suited to calculations as true distances are difficult to deduce from the coordinates.<br />
Both methods can include lateral or vertical offsets.<br /><br />
=== Expression of the distance ===<br />
The distance from the start of the measure (be it the start of the axis or the referent) can be expressed in several ways. <br />
*In metres (or miles, or any unit of choice)<br />
*Relative to the length of the element <br />
**As a percentage of the element (0…100 %)<br />
**Normalized (0…1). 75 % being expressed as 0.75<br />
* Hybrid : as a percentage of the length between two successive referents<br />
<br />
===== Hybrid expression =====<br />
The major problem with the relative method of linear referencing is the fact that it cannot be stored as a number when the system has mileage anomalies.<br /><br />
As the distance between two successive referents may be more than one kilometre (or 1000 units), the coordinate needs two fields to be stored. On top of that, not all reference points have a numeric name, a referent 12A might be inserted when lengthening the track between the mileposts 12 and 13.<br /><br />
<br />
The hybrid method aims to deal with this issue by assigning a fixed coordinate to each successive referent (usually a multiple of 1000) and adding the percentage of the distance between the two referents. <br /><br />
While it doesn’t allow true distance measurement, it keeps the sequence of the objects.<br /><br />
<br /><br />
<br />
For example, assuming the distance between the kilometre post 12 and 13 is 1200m and that the object needing to be located is at km 12 + 1050m, <br />
*Kilometre post 12 : coordinate 12000<br />
*Kilometre post 13 : coordinate 13000<br />
Object coordinate : coordinate of the referent (12000)+ percentage of the distance of the object regarding the distance between the referents (1050/1200) multiplied by the difference of coordinates between the two successive referents (1000)<br />
*Object coordinate : 12000 + (1050/1200)*1000 = 12875, which is a number that can be stored in one field and on which operations may be made. <br />
<br />
= {{rtm}} structure=<br />
As the railways world uses the most suited LR method according to the case, and that the aim of {{rtm}} is to design a universal way of describing railways, it was chosen to split the reference system into two kinds:<br />
*The NetElement’s internal way of measuring is a normalized absolute LRS. The NetElement with its own internal LRS (which we called “Intrinsic Positioning System” as it is proper to the NetElement, created and destroyed with it) becomes a “PositioningNetElement”<br />
*External linear referencing systems (such as the line/milepost) may be attached to the PositioningNetElement by linking a set of external LRS coordinates to the corresponding intrinsic coordinates.<br />
Choosing a universal LRS allows designing location algorithms independently from the field situation which would decide the most practical LR method for a specific segment.<br />
== Intrinsic positioning / referencing ==<br />
As said above, each NetElement forming the network has its own linear referencing system, which is created at the same time as the NetElement and destroyed with it. <br />
The purpose of this referencing system is double: <br />
*It ensures that every NetElement has a reference system allowing to locate events on it; small track elements (e.g. work reservations or side tracks) are often not linked to any “major” linear systems such as lines)<br />
*It ensures that every NetElement has an orientation and a length. This allows to locate other NetElements relatively to it (e.g. this switch is at the beginning of this track element)<br />
<br />
The reason why it was decided to use a normalized absolute LRS is that the normalized expression allows designing algorithms which are disconnected from the unit system. Some distances may be expressed in kilometres, miles, centimetres or feet. The normalized notation (0…1) allows to deal separately with the unit conversions.<br /><br />
Also, as it is applied to the smallest element of the network (at a given level), it can be used for locating objects in any path drawn on the network topology, whatever its length or its links with external referencing systems are (path crossing two lines).<br /><br />
Although very difficult to interpret in human interaction, it is perfectly adapted for computer calculations.<br />
<br />
== Track-referred positioning ==<br />
As the intrinsic coordinate system is difficult to use in human exchanges, field workers often use the classical linear referencing with line number, kilometre reference and distance from the post when dealing with long axis or metres from the start when dealing with short axis. <br /><br />
Those referencing systems can be linked with any relevant PositioningNetElement, ensuring the ability to translate the coordinates into an intrinsic coordinate and back. Any number of external reference systems can be linked to an element and an external reference system may of course be linked with several elements.<br />
<br />
{{navi<br />
|chapter={{RTM}} modelling concepts<br />
|chapterlink=RTM modelling concepts<br />
|prev=Structure<br />
|next=Object positioning in the network<br />
|pchapter={{rtm}} Quick Start<br />
|pchapterlink=RTM Quick Start<br />
|nchapter={{rtm}} External References<br />
|nchapterlink=RTM External References<br />
}}</div>
Ferri Leberl
http://wiki.railtopomodel.org/index.php?title=Hierarchical_structure_(levels)&diff=887
Hierarchical structure (levels)
2017-03-13T12:57:58Z
<p>Ferri Leberl: Änderung Navi</p>
<hr />
<div>{{Overview|text=This chapter describes the hierarchical structure of the {{rtm}} in form of levels of detail. In particular, the concepts of aggregation and disaggregation are presented by means of simple examples.}}<br /><br />
<br />
[[File:HierarchicalStructure.png|thumbnail|Hierarchical Structure (Language Unit)]]<br />
To describe the hierarchical structure of a “Network” instance which is built from “NetElement” instances belonging to different description levels the {{rtm}} provides the classes “CompositionNetElement”, “ElementPartCollection”, “OrderedCollection” and “UnorderedCollection”.<br /><br />
The important difference between “OrderedCollection” and “UnorderedCollection” is the possibility to enforce a sequence in the “NetElements” children at the more detailed description level.<br />
<br />
The fact that a given “NetElement” instance is composed from “NetElement” instances of a more detailed description level is modelled with the “CompositionNetElement” class.<br /><br />
<br /><br />
<br />
== Aggregation ==<br />
The following step-by-step example shows the principle of aggregation.<br /><br />
Starting point is a sample railway network at micro level depicting switches and tracks.<br /><br />
<gallery><br />
File:AggregationBase.png|Aggregation: Base network (© InfraBel)<br />
</gallery><br />
<br />
The aggregation shall produce "OperatingPoints" (OP) on an aggregated level out of the micro level to be used in more generalised applications:<br /><br />
<gallery><br />
File:AggregationTarget.png|Aggregation: Target network (© InfraBel)<br />
</gallery><br />
<br />
Following the {{rtm}} principes, the original network is modelled this way (each dot represents a NetElement):<br /><br />
<gallery><br />
File:OriginalNetwork.png|NetElement instances of original network (© InfraBel)<br />
</gallery><br />
<br />
The target OPs have known boundaries that happen to be situated somewhere on the tracks. In reality, these boundaries are for example given by the station signals. So, the tracks containing those boundaries have to be split into parts in order to identify what falls inside the boundaries and what stays outside.<br /><br />
<gallery><br />
File:AggregationStep1.png|Aggregation: Step 1 – Division (© InfraBel)<br />
</gallery><br />
<br />
The {{rtm}} provides structures to split the "NetElement" instances. For each "NetElement" instance that has to be broken up, two (or more) "LinearElementPart" instances are created. The first part runs from 0 to the split point, the other part runs from the split point to 1 (or to the next split point), effectively forming two (or more) new elements on another level.<br /><br />
<gallery><br />
File:AggregationDivision.png|Aggregation: Division principle (© InfraBel)<br />
File:AggregationDivisionModel.png|Aggregation: Division principle (model view) (© InfraBel)<br />
</gallery><br />
<br />
The resulting network will be depicted as follows (Each dot is an "ElementPart", those in orange are the new "ElementParts" resulting from a split, those in blue and green are "ElementParts" that keep the totality of their parent element):<br /><br />
<gallery><br />
File:AggregationStep1Result.png|Aggregation: Step 1 result – divided intermediate network (© InfraBel)<br />
</gallery><br />
<br />
At this step, the advantage of considering linear and non-linear elements in the same way of modelling can be seen: The graph theory provides tools to aggregate nodes of a graph. All "NetElements" are seen as nodes and can be easily aggregated to form a new network:<br /><br />
<gallery><br />
File:AggregationStep2.png|Aggregation: Step 2 – Fusion (model view) (© InfraBel)<br />
</gallery><br />
<br />
Using the previously introduced symbology (where the blue dots represent linear elements and green dots represent nonlinear elements) the green rectangles show indicate how the elements will be aggregated to obtain the target description of the network:<br /><br />
<gallery><br />
File:AggregationStep2Result.png|Aggregation: Step 2 result – Target network (model view) (© InfraBel)<br />
File:AggregationTarget.png|Aggregation result: Target network (© InfraBel)<br />
</gallery><br />
<br />
=== Structure Model ===<br />
[[File:ModelPart6.png|thumbnail|Model part 6 (© {{rml}})]]<br />
In order to being able to model the aggregation as described in this section, the {{rtm}} contains a number of classes as can be seen in the figure.<br />
<br /><br />
<br /><br />
<br /><br />
<br /><br />
<br /><br />
<br /><br />
<br /><br />
<br /><br />
<br /><br />
<br /><br />
<br /><br />
<br />
== Ordered and unordered collections ==<br />
The "OrderedCollection" defines a collection that has to be a continuous string of elements, without orientation changes. By using an "OrderedCollection" it is possible to compute a length and orientation. Let's have a look at a sample railway network:<br /><br />
<gallery><br />
File:SampleNetworkHierarchie.png|Sample network (© InfraBel)<br />
</gallery><br />
<br />
The red collection of track segments shown in the next picture is an "OrderedCollection": it has a start, an end and it is possible to compute a length.<br /><br />
<gallery><br />
File:OrderedCollection.png|Example OrderedCollection (© InfraBel)<br />
</gallery><br />
<br />
The "UnorderedCollection" is more generic. Like in an "OrderedCollection" still all elements are connected, but it is not possible to calulate a length or derive an orientation. In the following figure, the purple collection is an "UnorderedCollection"<br /><br />
<gallery><br />
File:UnorderedCollection.png|Example UnorderedCollection (© InfraBel)<br />
</gallery><br />
<br />
An "UnorderedCollection" may have more than one start, more than one end and different lengths.<br /><br />
<br />
== Disaggregation ==<br />
This section proposes a modelling concept for disaggregation, which is compliant with the {{rtm}}. In most cases that the different hierarchical levels of the topology network are derived via aggregation from nano level to macro level, but it is also possible to follow the other way from an aggregated level to a more detailed one. However, this concept of disaggregation requires additional information or at least "modelling templates" for disaggregating the nodes. Examples for such "modelling templates" are a default station layout, a standard switch layout, etc.<br /><br />
<br />
The procedure of disaggregation seems to be very useful as a system function for capacity planning or for the fast configuration of simulation datasets in situations of inadequate or outdated base documentation.<br /><br />
<br />
The orientation of the Part needs not be the same as the orientation of the parent. The parameter KeepsOrientation allows to reverse the element in order to keep a homogeneous orientation for the collection.<br /><br />
<br />
In the following example we assume that the starting point is the macro level of detail for the network, and that we want to produce a more detailed level:<br /><br />
<gallery><br />
File:AggregationTarget.png|Base network (© InfraBel)<br />
</gallery><br />
<br />
In the model view this railway network is translated into:<br /><br />
<gallery><br />
File:AggregationStep2Result.png|Disaggregation: base network – Model view (© InfraBel)<br />
</gallery><br />
<br />
For disaggregation of this OP, we assume the following template of a standard station layout:<br />
<gallery><br />
File:DisaggregationTemplate.png|Disaggregation: Template (© InfraBel)<br />
</gallery><br />
<br />
The resulting object model is depicted in the following figure:<br />
<gallery><br />
File:TemplateInserted.png|Template inserted in place of OP (© InfraBel)<br />
</gallery><br />
<br />
Afterwards, the adjacent linear elements (blue dots) are fused if required.<br /><br />
<gallery><br />
File:FusionOfElements.png|Fusion of adjacent linear elements (© InfraBel)<br />
File:FusedNetwork.png|Fused network (© InfraBel)<br />
</gallery><br />
<br />
The resulting railway network model is depicted in the following figure:<br /><br />
<gallery><br />
File:AggregationBase.png|Target network (© InfraBel)<br />
</gallery><br />
<br />
To summarize:<br/><br />
Aggregation/Disaggregation are done in two steps: at first the elements are decomposed into "element parts" and then the parts are fused together to create new elements. There is thus very little difference between aggregation and disaggregation, the main difference is the purpose of the operation. While aggregation simplifies the network and reduces the number of elements, disaggregation raises this number by adding detail to the network.<br /><br />
<br />
== Different Level Views ==<br />
As show in the previous section, there are two ways of applying aggregation/disaggregation procedures:<br /><br />
Depending on how the created level will be linked to the existing level, the procedure might produce a higher or a lower description level of detail.<br /><br />
* A lower level is produced when information is added to the original Elements level.<br /><br />
* A higher level is produced if the objects of the new level can be derived as a function of the objects of the original level.<br /><br />
<br />
=== Higher level view ===<br />
Disaggregation of a higher level amounts to creating an alternative path. In other words creating another "Branch" in the tree of level definitions. For example, one may want to divide the network following a station/open track rule - the "predefined path" - for path calculation purposes, and divide it into track circuits for train tracking and control.<br /><br />
<gallery><br />
File:AggregationPaths.png|Different aggregation paths (© InfraBel)<br />
</gallery><br />
<br />
The track circuits have to be defined as collection of parts of the elements of the base network.<br /><br />
Fortunately, the {{rtm}} allows an infinite number of those branches.<br /><br />
<gallery><br />
File:AggregationPathsPrinciple.png|Different aggregation paths (principle) (© InfraBel)<br />
File:AggregationPathsProblems.png|Different aggregation paths - potential problems (principle) (© InfraBel)<br />
</gallery><br />
In the previous example, the function of macro level could be defined both in terms of the Station/open track definition and as a collection of track circuits.<br /><br />
<gallery><br />
File:AggregationPathsProblems2.png|Different aggregation paths – potential problems (© InfraBel)<br />
</gallery><br />
<br />
Both path give a valid network (in that sense that the network obeys the model’s rules), but the two results may not always be identical.<br /><br />
<br />
=== Lower level view ===<br />
Building downwards, in fact multiple "roots" are created from the trunk, adding a new definition of the elements to the "base" level. It is important to be careful and ensure that the multiple definitions result in exactly the same element at the base level.<br /><br />
<gallery><br />
File:Disaggregation.png|Disaggregation (© InfraBel)<br />
</gallery><br />
<br />
It also means that, an element at any level may have several definitions, depending on what level is considered as the source, and that a routing level has to be built at the end of each “root”. As the roots never rejoin the trunk (else, they would be built upwards) there is no real issue concerning the data coherency. As long as the client is conscious from which root he takes the data.<br /><br />
For example, a station may have several definitions, whether viewed from the point of a signalman, a passenger operator.<br /><br />
<br />
In the signalman’s view, all the tracks and switches are important. In the operator’s view, the platforms and the yard are the main elements in this view. The two definitions may be considered equivalent if there is an agreement of the boundaries, meaning that what is inside and outside stays the same(geographically or functionally).<br />
<gallery><br />
File:SignalmanView.png|Signalman’s view (© InfraBel)<br />
File:OperatorView.png|Operator’s view (© InfraBel)<br />
</gallery><br />
<br />
<br />
{| class="wikitable"<br />
|-<br />
| '''What you should have learned'''<br /><br />
* Aggregation is the process of deriving a "higher level" from a "lower level".<br />
* Disaggregation is the process of deriving a "lower level" from a "higher level".<br />
* For aggregation, it is necessary to know the exact location of the boundaries, since they are the "split points".<br />
* By aggregating elements, the number of elements decreased and information are being lost.<br />
* For producing a more detailed network by disaggregation, it is necessary to either have additional information available or to use templates.<br />
* Aggregation can be done using ordered and unordered collections.<br />
* An ordered collection has one start point, one end point and an orientation and its length can be calculated.<br />
* An unordered collection is more generic and it is not possible to determine a length or orientation.<br />
|}<br />
<br />
{{navi<br />
|lesson=<br><br />
* Aggregation is the process of deriving a "higher level" from a "lower level".<br />
* Disaggregation is the process of deriving a "lower level" from a "higher level".<br />
* For aggregation, it is necessary to know the exact location of the boundaries, since they are the "split points".<br />
* By aggregating elements, the number of elements decreased and information are being lost.<br />
* For producing a more detailed network by disaggregation, it is necessary to either have additional information available or to use templates.<br />
* Aggregation can be done using ordered and unordered collections.<br />
* An ordered collection has one start point, one end point and an orientation and its length can be calculated.<br />
* An unordered collection is more generic and it is not possible to determine a length or orientation.<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 />
|sprev=Topological structure (network)<br />
|subsection=Hierarchical structure (levels)<br />
}}</div>
Ferri Leberl
http://wiki.railtopomodel.org/index.php?title=Topological_structure_(network)&diff=886
Topological structure (network)
2017-03-13T12:55:22Z
<p>Ferri Leberl: Änderung Navi</p>
<hr />
<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>
Ferri Leberl