Add concepts for accuracies and tolerances

[FransKnibbe]

Contributed by Anna Wagner and Mathias Bonduel for the white paper "Benefits of Representing Spatial Data using Semantic and Graph Technologies":

The AEC domain struggles with geometric representations of planned objects and built objects and corresponding tolerances and inaccuracies, respectively. Planned objects are created on a scratchpad, while construction sites do not offer perfect conditions to recreate the planned geometry completely. Depending on the construction material, the geometry descriptions are commonly enriched with tolerance values, ranging from millimeters (steelwork) to centimeters (masonry). For the geometry of already built objects, the (measured) accuracy is also not perfect, as measuring techniques cannot provide flawless representations. Furthermore, by processing or simplifying geometry descriptions (e.g. from point cloud to mesh), inaccuracies can occur, which are also of interest to attach (represented accuracy). Hence, the possibility to attach accuracies (measured or calculated accuracy) and tolerances would be beneficial for building geometry.

[rob-metalinkage]

Given that precision and accuracy (and thresholds ) are not usually measurable themselves - but rather a characteristic of a measurement or definition process, such metadata is logically attached to a dataset rather than individual properties. This also means that we can work with individual properties without reifying them and annotating each one. We cant do this at the Dataset level - because a Dataset may contain many feature types, and each feature type may have multiple properties. The only option currently available is to use RDF-Datacube to describe dataset structure, which gives us a place to provide such qualifiers. QB4ST (https://www.w3.org/TR/qb4st/) has made a start - either identifying a better option or updating it to have everything you need would be a good place to start.

[mathib]

(original contribution raised by @AnnaWagner and I)

The QB4ST might be the way forward, but I'm worried that it might be a little to complex for what we try to achieve. Personally, I would allow both to directly:

• annotate a geometry description, or
• annotate a group of geometry descriptions (e.g. using a concept similar to omg:GeometryContext)

with a measurement or definition process, that contains information regarding accuracy, tolerance, etc.

Users of the geometry descriptions are probably more concerned about the accuracy of geometry descriptions directly, so a "shortcut" between the accuracy and geometry descriptions would be useful for them. This might result in some kind of "summary" properties for the geometry description's accuracy (e.g. mean deviation between point cloud and simplified geometry), derived from the (settings/context/...) of the measurement or definition process.

[FransKnibbe]

@rob-metalinkage: in most cases accuracy of geometry can be expressed at the dataset level, and in those cases it is probably best to do so (although all geometry instances do need a link back to the dataset, via a parent spatial thing or otherwise, I think). But there are cases where accuracy depends on position. Just think of a series of GNSS locations with varying amounts of satellites in view. There are also cases where accuracy varies between points describing a more complex shape, and it's also possible to have different accuracies for X, Y and Z in a single geometric point. Sometimes it is necessary to have this in the data.

I also think accuracy should be expressible for all numeric data, not just spatial data. The need to express accuracy exists in many domains, but it would be best for all if a method is specified at the highest level.

[mathib]

added to the OGC standards tracker: http://ogc.standardstracker.org/show_request.cgi?id=633

[dr-shorthair]

Basic form implemented in GEOX as

• hasResolution
• hasResolutionM

Referred to in opengeospatial/geosemantics-dwg#73

[mathib]

We have implemented the Level of Accuracy spec from the USIBD. I found it useful since it differentiates between measured (e.g. point cloud or discrete points) and represented accuracy (= geometry derived from the measured geometry, e.g. a simplification or transformation into other geometry type (Mesh, NURBS, BREP, etc)):

• https://w3id.org/gom#RepresentedAccuracyAnalysis
• https://w3id.org/gom#hasSimplifiedGeometry
• https://w3id.org/gom#hasSurveyGeometry
• https://w3id.org/gom#totalOccluded
• https://w3id.org/gom#totalRelevant
• https://w3id.org/gom#totalLOA10, https://w3id.org/gom#totalLOA20, etc.
• https://w3id.org/gom#total95PercentUpperLimit
• plus some other properties to link metadata related to the analysis method, tools, settings, etc.

[jabhay]

MoSCoW poll created

[FransKnibbe]

This issue is about adding ways to express resolution and accuracy. Resolution has been added to GeoSPARQL 1.1 hasSpatialResolution, see also issue 98. That leaves spatial accuracy. Why don't we add it to GeoSPARQL 1.1 too?

[FransKnibbe]

Given that precision and accuracy (and thresholds ) are not usually measurable themselves - but rather a characteristic of a measurement or definition process, such metadata is logically attached to a dataset rather than individual properties. This also means that we can work with individual properties without reifying them and annotating each one. We cant do this at the Dataset level - because a Dataset may contain many feature types, and each feature type may have multiple properties. The only option currently available is to use RDF-Datacube to describe dataset structure, which gives us a place to provide such qualifiers. QB4ST (https://www.w3.org/TR/qb4st/) has made a start - either identifying a better option or updating it to have everything you need would be a good place to start.

Couldn't dataset partitioning using VoID also be used for stating different accuracies/resolutions for different parts of a dataset in its metadata?

[oldskeptic]

I'd like to put in a word for point / shape level resolution and accuracy data. In cases where the "dataset" is the result of the fusion of multiple sources or a sensor with variable performance (field GPS, radar track), there is a real need to tag the geometry with performance data.

In the past, I've hacked my way out of that problem by instantiating a Feature inside of a Geometry Polygon, but it is ugly.