What units are allowed for geof:distance, geof:buffer?

[VladimirAlexiev]

What units are allowed for the functions geof:distance, geof:buffer?
GeoSPARQL 1.0 defines them merely as units: xsd:anyURI, eg:

geof:buffer (geom: ogc:geomLiteral, radius: xsd:double, units: xsd:anyURI): ogc:geomLiteral

Our own documentation https://graphdb.ontotext.com/documentation/10.5/geosparql-support.html#example-4
shows an example from the uom: <http://www.opengis.net/def/uom/OGC/1.0/> namespace.

One can explore that namespace eg at

• https://defs.opengis.net/vocprez/object?uri=http://www.opengis.net/def/uom/OGC/1.0/&_mediatype=text/turtle
• https://defs.opengis.net/vocprez/object?uri=http://www.opengis.net/def/uom/OGC/1.0/unity&_mediatype=text/turtle

And the members of that collection are:

• metre: The metre is the length of the path travelled by..
• GridSpacing: Spacing between adjacent grid lines, or between centers of adjacent pixels
• degree: Angular degree
• radian: Angular radian
• unity: unitless ratio of two quantities with the same units

Of these, only metre seems a suitable value?

• uom:GridSpacing begs the question: which grid?
• degree and radian could be interpreted as "angular measure at the equator (111139 m and 6367798 m respectively)?

Is there are default value, i.e. is it ok to leave units unbound?

Links:

• a bit related to vocprez (OGCNA) defects: GeoSPARQL function parameters/results, namespaces, etc #467
• internal doc issue: https://ontotext.atlassian.net/browse/GDB-9323
• internal impl issue: https://ontotext.atlassian.net/browse/GDB-9320 if units is unbound

[situx]

I think we deliberately did not constrain the unit parameter to a specific vocabulary, and the uom:metre example was, at the time of definition of GeoSPARQL 1.0, probably the only vocabulary around or recommended by OGC.
In my opinion, it is up to implementers to choose a suitable vocabulary to support, e.g., https://github.com/HajoRijgersberg/OM or https://www.qudt.org/pages/QUDToverviewPage.html
Out of those, you could define the units you would like to support in your implementation.

We did not define default values for the geof:buffer function per se, but you could consider the metric versions e.g. metricBuffer as default functions

[VladimirAlexiev]

But shouldn't the spec at least say: these should be Length units,
eg as defined by QUDT for unit:M:
unit:M qudt:hasDimensionVector dimension:A0E0L1I0M0H0T0D0.

[situx]

We do have section 8.3, which recommends vocabularies for Units of Measure for all GeoSPARQL functions.

Yes, we could have written that we would recommend a length unit for clarity in the case of geof:buffer
I assume we thought that this would be implicitly clear because we are describing a radius here.
I can take this into our next call so that we may improve the wording here if you like.

[VladimirAlexiev]

• Can you give a link to the new sec 8.3? (I haven't yet read version 1.1 in depth).
• It's very natural to assume that only Length units are allowed. But when I saw https://stackoverflow.com/questions/77680391/geosparql-geofdistance-measurement-in-query-yields-bad-or-no-result/77691719 someone using degree I started wondering whether the implementation also allows "angular measure at the equator" (111139 m)

[situx]

Here you are:
https://opengeospatial.github.io/ogc-geosparql/geosparql11/spec.html#_recommendation_for_units_of_measure

[VladimirAlexiev]

the particular Spatial Reference System (SRS) that is associated with a Geometry instance will specify a unit of measurement

Does that mean it's ok to use

• degree (Angular degree) with WGS84, or
• GridSpacing with some gridded SRS (I don't know any such: I'm not a geometer)

others may be used, as long as they are well-described

• for backward compatibility. it should mention that http://www.opengis.net/def/uom/OGC/1.0/ can be used (although it is neither comprehensive, nor well described)
  • You can raise a legitimate objection that a mere example in an older version of the standard shouldn't obligate a newer version of the standard. But examples have that nature: people latch on to them and use them, regardless of their "stature"
• or restrict to http://www.opengis.net/def/uom/OGC/1.0/metre only

[situx]

Yes, you would be free to use these other units like degree.

Whether it makes sense to use them in your context is one question. Whether the implementation is willing to support it and how is another one we did not aim to solve in the specification as to not restrict the standard unnecessarily. We do not even mandate that all or any of the uom units should be supported.
We merely suggest that implementers support a set of well-known units for the functions and document these.

If we were to restrict the unit to uom:metre only, then our function would be useless because there is still geof:metricBuffer which is restricted to meter already.

But I think I know what you mean: We should probably provide some useful examples concerning different units and how people might typically want to use them in practice in order to make the choice for supporting units easier for implementers.

[mathib]

when more and more geometry formats are supported with GeoSPARQL 1.2+, so will increase the number of "input" units for spatial functions. Units are defined in a CRS and/or in the geometry description itself. Sometimes, there are clear and standard IDs/URIs for units, but in some frequently used geometry formats such as STEP in IFC, these are "just" strings which have to be harmonized still by an interpreter before executing a spatial function.

When many different kinds of input units becomes a reality, I think this increases the need for a clear and harmonized approach to units in the "output" of spatial functions.

For what it's worth, the construction industry in Europe already agrees on using QUDT for quantitative properties (e.g. "volume" which is calculated from a 3D geometry description) by the EN 17632-1. It's already applied in several companies as we speak.

[VladimirAlexiev]

@situx Please give your personal opinion: does this guess make sense:

degree and radian could be interpreted as "angular measure at the equator (111139 m and 6367798 m respectively)?

@mathib I'm very interested in applications of GeoSPARQL to architectural geometry. I've seen some 3D functions in GeoSPARQL (eg is3D, volume). Being able to attach Feature "measurements" like Volume is certainly useful, and it's nice that SML uses QUDT.
But is GeoSPARQL capable of capturing fully-featured 3D geometries?

https://opengeospatial.github.io/ogc-geosparql/geosparql11/spec.html#_geosparql_and_simple_features_sfa_ca:

Neither GeoSPARQL nor SFA-CA support full three dimensional geometry. Coordinates may be three-dimensional, which means that points may have a Z-coordinate next to an X- and Y-coordinate. The Z-coordinate then holds the value of height or depth. However, lines or surfaces can only have one Z value for any explicit or interpolated X,Y pair. This approach is often referred to as 2.5 dimensional geometry. Geometric functions working with Geometries that have Z values will ignore Z values in calculations and first project geometry onto the Z=0 level.

[VladimirAlexiev]

#398 suggests that degree, radian are acceptable units for these functions.
However, it also warns that metric calculations in WGS 84 or any other SRS based on angles are inaccurate: eg the buffer of a point is a weird ellipse instead of a circle.

Therefore this guess

degree and radian could be interpreted as "angular measure at the equator (111139 m and 6367798 m respectively)
is very likely wrong: the results are likely to be different if you ask for 1 uom:degree vs 111139 uom:metre.
But the difference depends more on the SRS of the geometry than the uom parameter. In fact #398 suggests that repositories are free to throw an exception if you ask for uom:metre of a geometry that uses WGS 84.