Difference between revisions of "Intrinsic positioning / referencing"
|[checked revision]||[checked revision]|
|Line 102:||Line 102:|
| [[Positioning]] || [[Track-referred positioning]] || -
| [[Positioning]] || [[Track-referred positioning]] || -
Revision as of 17:06, 13 March 2017
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).
It could be read as “At coordinate X after the start of the element”.
A major goal of the RailTopoModel® is the precise localisation of all relevant information objects in reference to the network.
The class “PositioningNetElement” describes those building blocks of a “Network” which will be used as an “element of reference” for intrinsic positioning.
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.
An “AssociatedPositioningSystem” instance possesses a set of “IntrinsicCoordinate” instances. Each “IntrinsicCoordinate” in turn is associated to one or more “PositioningSystemCoordinate” instances.
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.
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.
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.
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.
Another big advantage is that intrinsic positioning based on 0 to 1 intervals allows algorithms which operate without units.
Now that the elements have been listed, the next goal is to provide a way to place items on these elements: a referencing system.
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.
Application of intrinsic positioning
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.
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).
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).
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).
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.
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).
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.
One ravel in the environment of a topological change is caused by the intrinsic positioning method.
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.
Even in some cases where the topology is unchanged, recalculations have to be performed for locations which are expressed by intrinsic positioning.
At a second thought, we see the next disadvantages of intrinsic positioning:
- Doubtful accuracy, regardless how many digits behind the digital dot are applied
- Problems with data collection in the above value chain (+ costs)
- The same with data maintenance (+ costs)
- Bad or even impossible use ability in real life (mechanicals/operators) in the field and maintenance of history (at least conversion tool required)
- Permanent recalculation on event of any topological or geometrical or (some) technical changes (conversion tool required).
- Laborious use ability in the flow of the whole value chain with respect to the topological life cycle.
In summary: from 2e bullet to last one: is there any positive business case thinkable? Probably not.
Consequence: the modeling group has to reconsider the utilization of the intrinsic positioning method !!
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.
It is thus not intended to manage the (position of the) network/objects themselves.
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.
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.
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.
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.
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).
Its advantages are multiple when computing or transmitting data:
- 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.
- It never has to deal with “mileage anomalies”, so designing algorithms is easier and faster.
- The computation algorithms need only be designed one time (and not one for each referencing method / combination of referencing methods).
- 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…).
- 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).
- 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.
- 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)
Application to the model
Considering the following elements:
We only take spot objects and assume there is no mileage anomaly, in order to keep it simple.
The model allows two possible approaches:
We manage the intrinsic coordinate for each object: 0.19191919
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.
However, it is not a very user friendly way to manage data that has to be manually entered.
| What you should have learned|
|Back To||Previous Chapter||Next Chapter|
|What you should have learned|
|Please, enter a summary!|
|Chapter||RailTopoModel® Quick Start||RailTopoModel® modelling concepts||RailTopoModel® External References|
|Section||Structure||Positioning||Object positioning in the network|
|Subection||Track-referred positioning||Intrinsic positioning / referencing|