PositionPoint (coordinate) accuracy

[EmilieSkog]

There is a need to provide information about the accuracy of a coordinate. As a minimum Norwegian utilities must indicate whether a coordinate is a measured or nominal (no: "innmålt") value when reporting to NRL (no: "Nasjonalt register over luftfartshindre", en: national register of aviation obstacles). CIM does not seem to contain such information.

Could the GeoSPARQL property geo:hasSpatialAccuracy be a suitable candidate? (https://opengeospatial.github.io/ogc-geosparql/geosparql11/spec.html#geo:hasSpatialAccuracy)

Description: The property geo:hasSpatialAccuracy is applicable when a Geometry is used to represent a Feature. It is expressed as a distance that indicates the truthfulness of the positions (coordinates) that define the Geometry. In this case accuracy defines a zone surrounding each coordinate within which the real positions are known to be. The accuracy value defines this zone as a distance from the coordinate(s) in all directions (e.g., a line, a circle, or a sphere, depending on spatial dimension).

geo:hasSpatialAccuracy
    a rdf:Property, owl:ObjectProperty;
    rdfs:isDefinedBy geo: ;
    skos:prefLabel "has spatial accuracy"@en ;
    skos:definition "The positional accuracy of the coordinates of a Geometry."@en ;
    rdfs:domain geo:Geometry ;
.

If so, the utilities/NRL would have to agree on an accuracy limit that makes the destinction between nominal and measured values, e.g. all coordinates with an accuracy zone larger than 5 meters are considered nominal.

[VladimirAlexiev]

hi @EmilieSkog !

• With hasSpatialAccuracy you need to use an intermediate node to specify the UoM in addition to the value
• It's better to use hasMetricSpatialAccuracy, which is simple number (xsd:double)

Furthermore, GeoSPARQL considers using "qualified" geometries that can can use qualifiers such as time, confidence, evidence, role:

• https://github.com/opengeospatial/ogc-geosparql/issues/241
• https://github.com/opengeospatial/ogc-geosparql/issues/430

So you don't need to map measured vs nominal to a meter threshold, but can use thesaurus values (skos:Concept) to capture the exact meaning, eg something like this:

<substation> a geo:Feature; geo:hasGeometry <substation/geo/measured>, <substation/geo/nominal>.
<substation/geo/measured> a geo:Geometry; geo:asWKT "..."^^geo:wktLiteral; ex:quality <geo/quality/measured>.
<substation/geo/nominal> a geo:Geometry; geo:asWKT "..."^^geo:wktLiteral; ex:quality <geo/quality/nominal>.

<geo/quality> a skos:ConceptScheme; skos:prefLabel "Coordinate quality"; 
  dct:source "national register of aviation obstacles"@en, "Nasjonalt register over luftfartshindre"@no.
<geo/quality/measured> a skos:Concept; skos:inScheme <geo/quality>; skos:prefLabel "measured"@en.
<geo/quality/nominal> a skos:Concept; skos:inScheme <geo/quality>; skos:prefLabel "nominal"@en, "innmålt"@no.

[EmilieSkog]

Update: NRL only requires DSOs to report the below Code value for each Structure, ACLineSegmentSpan and Zone (no: "mast", "luftspenn" og "flate"). In principle a true or false of whether the coordinate accuracy complies with th 2023 reporting requirements.	Name	Description	Code value	Status
FOR-2020-10-16-2068, §5(1)	The aviation obstacle has been reported according to the requirements for reporting accuracy specified in §5(1) of the Norwegian aviation obstacle regulations, with effect from January 1, 2023.	20230101_5-1	Valid
none	The aviation obstacle has been reported before January 1, 2023, without the facility owner verifying that the obstacle complies with the reporting requirements in the revised regulation, which comes into effect after December 31, 2022. The code value is also used for aviation obstacles that are reported after January 1, 2023, but do not meet the accuracy reporting requirements	0	Valid

[Sveino]

What @EmilieSkog is outlining is the requirement we got from the Norwegian Mapping Authority, so we would need to be able to derive to this information from the authority dataset. Typically the geospatial information in the power industry is derived from:

• measured : The information is measured according to a given standard.
• calculated : The power line is regularity scanned by taking plain photograph and from the geospatial information is calculated.
• estimated : Based on other measured or calculated values the data is estimated.
• manual : Based on looking at the map and other sourced the data is entered manually.

I like the idea of aligning with PROV, however I am wondering if the prov:hadActivity is most relevant. And by this have geo:hasActivity

[EmilieSkog]

Thank you @VladimirAlexiev, We have a specific use case where the DSOs need to specify whether the given coordinate is related to the top or bottom of a pole/tower.

Typically the geospatial information in the power industry is derived from:

• measured : The information is measured according to a given standard.
• calculated : The power line is regularity scanned by taking plain photograph and from the geospatial information is calculated.
• estimated : Based on other measured or calculated values the data is estimated.
• manual : Based on looking at the map and other sourced the data is entered manually.

With refrence to the above, If the pole has been deployed but it's height has not yet been accurately measured, the DSOs could either

1. Measure the coordinate with reference to the bottom of the pole(ground level), this coordinate would then be reported according to the standard
2. Estimate the coordinate with reference to the top of the pole by adding the height of the pole to the measured coordinate at the bottom of the pole. This coordinate would then NOT be reported according to the standard.

This means that to stay compliant with the standard the DSOs would report a coordinate with reference to the bottom of the pole while the pole has not yet been accurately measured. Once the pole has been accurately measured the DSOs would report a coordinate with reference to the top of the pole.

Could such top/bottom references also be specified using f.ex. a role qualifier, similarily to what you showed in your example?

[VladimirAlexiev]

@EmilieSkog Yes, you should definitely add such qualifiers.

We've seen a similar case in urban planning, where a building height could be reported eg:

• FROM: ground level, or German standard height reference (water level at some canal)
• TO: bottom edge of roof, or top edge of roof

In our case we combined these 2 factors into thesaurus URLs like <heightReference/from/1000/to/4300> (where the codes come from the German XPlanung standard) because there were only a few combinations.