Guidance for spatial resolution of geometry output

[FransKnibbe]

Some GeoSPARQL functions produce new Geometry instances, geof:buffer for example. At the moment the spatial resolution of output geometry is not specified. This means that geometry produced by GeoSPARQL functions could vary a lot between implementations. In order to make it better known to users what to expect, guidelines on spatial resolution for geometry output should be added to the documentation of the Geometry extension.

As far as I can tell. the following functions generate new geometry for which spatial resolution is undetermined:

• geof:buffer
• geof:aggBoundingCircle

[FransKnibbe]

As far as I know, in GIS there are two methods in use for specifying spatial resolution of generated geometry:

1. A resolution (tolerance) is set at the dataset level and is carried over to all geometries that are part of the dataset.
2. A resolution is set by means of extra function arguments.

The first method can not be used in GeoSPARQL because geometries are not necessarily member of a data set with settings at the data set level. And GeoSPARQL at the moment does not have mechanisms for data set level settings or metadata (although that would be nice to have).

I guess the second method is impossible too because we are not at liberty to change existing function signatures to add extra arguments.

The only remaining solutions I can think of:

1. Base spatial resolution on the resolution implied by the significant digits of the coordinates of the input geometry/geometries. For example, output geometry could use the largest separation distance resulting from an analysis of input coordinates.

2. Assuming that the only geometry parts with undetermined resolution are circle segments, we can set a value for the number of line segments to approximate a circle, like is done in the PostGIS st_buffer function.

[mperry455]

Oracle Spatial uses a tolerance value - either passed in directly or looked up in a metadata table.

Our GeoSPARQL implementation requires you to set CRS and tolerance info at the RDF dataset level. All geometries will be transformed to the desired CRS internally and the dataset-level tolerance value will be used for all computations.

To me, this feels like more of an implementation issue. Simple Features for SQL should have the same problem, and it doesn't make any requirements on the spatial resolution of the returned geometry from what I can tell.

[FransKnibbe]

To me, this feels like more of an implementation issue. Simple Features for SQL should have the same problem, and it doesn't make any requirements on the spatial resolution of the returned geometry from what I can tell.

It could be left for the implementation to decide, yes. But I do think there can be a difference in what to expect from a stand-alone SQL database system and a SPARQL endpoint on the Web that may be part of distributed systems. For instance, an RDBMS user could use a SQL query to find out the tolerance for a particular dataset. But how is a consumer (human or machine) to do that in case of a SPARQL endpoint?

[mperry455]

Per SWG discussion, we should postpone to 1.2 or 2.0 because adding new resolution requirements to previous functions could break backwards compatibility.