Purpose

Localisation is the operation consisting in linking some location (the portion of space consumed by a network entity, or any other spatial entity) with topology, under consideration of geographic positioning and linear positioning. Localisation logically lends its name to the package.

Diagrams

The localisation vocabulary can be represented in three diagrams.

Localisation core

This diagram defines what a location is with respect to topology elements, and breaks locations down into three disjoint classes:

• Spot locations, mapped to a point on or near topology elements;
• Linear locations, mapped to a sequence of contiguous linear elements, or parts thereof;
• Area locations, mapped to a "bag" (unordered set) of topology elements of any nature.

As of localisation version 0.4:

Note: the diagram uses the Graphol representation of OWL2, which is somewhat similar to the UML ODM profile. In particular,

• object properties are represented by diamonds, and are linked to their domain via a white square and to their range via a black square.
• similarly, data properties are represented by small circles.
• double edges on properties means "functional property" (at most one value).
• thick black edges on object properties means "inverse functional".
• combined double edged and thick black edged diamond means "functional and inverse-functional".
• The black, flattened hexagons usually signal disjoint unions. For instance, class BaseLocation is equivalent (double arrow) to the disjoint union of LinearLocation and NonlinearLocation.

Locations are "places on earth" associated with spatial objects, also called "Features" in GeoSPARQL, hence the geo:Feature superclass.

Locations can be expressed by coordinates or other means, such as a position along a track.

Locations should not be confused with the coordinates used to express them: these can vary (think of a moving object), can use various reference systems, be subject to measuring errors, etc.

We distinguish spot, linear, and area locations, excluding "volumes" (a subject better covered by BIM), in relation with the number of dimensions needed to describe them. Since dimensionality is different, spot, linear, and area location classes are disjoint. Class BaseLocation is defined as the disjoint union of spot-, linear-, and area location classes, so BaseLocation would be equivalent to an abstract superclass in UML (a class with no direct instances).

Please note that the same domain object can have several locations, according to the level of detail: e.g. a station would have an area location on a track plan, but a mere spot location on a passenger information map.

The Localisation vocabulary allows to express the location of spatial objects with respect to the network topology, if relevant. If the network topology is irrelevant (example: the location of a downtown ticket vendor), there is not need to refer to it, as GeoSPARQL will express the geographic positioning using some standard serialization (WKT, GML...). You may even envisage a postal address, using other ontologies such as foaf.

In the simplest case, a location is expressed as a collection of topology elements (individuals of class NetElement). This could be expressed with an ordinary object property, with domain = BaseLocation and range = NetElement. We however chose to express this collection as a closed, ordered list, because:

• the order of the included net elements may be relevant, especially in the case of linear locations (mapped to a sequence of linear elements);
• being able to close the list (with a conventional "null" element) provides certainty about the data being complete.

Concerning the representation of such lists in OWL, see About RDF OWL. In the present case, we chose to use the List ontology published by Pauwels and Terkaj as a component of IfcOwl. This is because we do not need to represent the list as a container (with a particular identity and properties...); it suffices to represent the sequence of net elements as a linked list: a chain of items (individuals of class ListedElement), with each item pointing to a net element as contents, and to the next item in the sequence.

BaseLocation points at the first element in the list (using object property listedElement). A BaseLocation should however point to one list at most: having multiple lists (multiple first elements) would leave open the question "do we have all lists?", defeating the very purpose of having a closed list (see previous paragraph). Consequently, property listedElement should be declared a functional property, in the sense of OWL2.

In the case of an area location, the order of net elements in the linked list is arbitrary: the user may adopt whatever convention he/she would find useful, or leave it to the data processing (it is however good practice to adopt a convention, so that comparisons can be performed efficiently). In the case of area locations, the added value of having a list is limited to it being closed by a last, "null" element.

In the case of a linear location, all net elements involved are necessarily linear. The order in the list reflects the sequence of linear elements that would be traversed by a travelling vehicle (leaving navigability issues aside) from the first element to the last. This implies that all linear elements be connected, and also that each linear element be oriented. For that purpose, the class ListedLinearElement is used instead of ListedElement, and the data properties startsAt and endsAt set the orientation. Property values are intrinsic coordinates along the linear elements: value 0.0 at the first port, 1.0 at the second port.

By using values other than 0.0 and 1.0 (denoting extremities of linear elements), it is also possible to include parts of linear elements to one or another end of the sequence.

More generally, parts of linear elements can be referenced by any location (e.g. area location), replacing a ListedElement by a ListedLinearElement, thus giving access to the startsAt and endsAt properties. In practice, the lists will most likely be represented using blank nodes, so the presence of startsAt and endsAt property instances will actually determine the item type.

Finally, spot locations typically refer to one linear element: it suffices to provide a value to the startsAt property. Other properties of ListedLinearElement (not shown here) allow to stipulate a side (to the left or right of the linear element, taken in its nominal orientation from the first to the second port), a lateral offset, and even an application direction (think of signals that do not work in both directions).

As was the case in RTM/RS/1.2, a spot location can refer to more than one net element (think of a signal addressing converging tracks).

Offsets, sides, application directions

As of version 0.4:

Defining composite net elements

From topology 1.0rc2 on, composition of net elements to create other net elements no longer uses an ad hoc composite pattern, but instead uses the composition mechanism provided by the Localisation package.

As of version 0.4:

About the OWL List ontology

This diagram is added for illustration only:

Shortly:

• every instance of OWLList has one next OWLList (forming a chain) or EmptyList (terminating the chain).
• An EmptyList instance is only there to signal that the end of the list is reached, and it has no next element and no contents.
• By contrast, any OWLList individual can have a content of any type.
• while hasNext points to the immediately following individual, isFollowedBy points to all downstream individuals (by transitivity).

In practice, referring to a list (as a whole) consists in referring to its first element. This is why the properties elementList and linearElementList, pointing to at most one list, appear to be functional properties (represented by a double-edged diamond) in the first diagram above.

Next steps?

1. using intrinsic coordinates in a more explicit way (formal references to GeoSPARQL and to ISO 19148, possibly via IFC or DATEX classes). This would entail the replacement of two data properties (startsAt, endsAt) by complex object properties. Whether this is worthwhile is debatable.

2. Offsets were only lateral in earlier versions (up to RSM 1.2), and are now generalized to tangential and vertical, effectively defining a 3-axis local coordinate system. Explicitly defining a local cartesian coordinate system would be a conceptual simplification and could make use of IFC classes.

3. OWL profiles relevance: compliance with OWL2-RL ensures tractability in polynomial time (≠OWL2-DL: exponential time). The downside is some limitations (e.g. cardinalities or data sub-types), many of which can be expressed as SHACL shapes.

4. OWL profile compliance checks: EDDY and TopBraid Composer can check against OWL2-RL. Looking for a convenient tool for OWL2-DL.

5. Blind spot? everything is being examined as projections on a horizontal plane, except of course vertical offsets. Are there any realistic use cases where the effect of profiles on odometry (“distance along”) would become relevant?