Question about geometry function calculations and SRS
Opened this issue · 6 comments
In wake of the upcoming GeoSPARQL 1.1, I want to take the chance to clarify some things (maybe the answer is already clearly in the standard and I just missed it, in which case my apologies)
8.9.1
An invocation of any of the following functions with invalid arguments produces an error. An invalid argument includes any of the following:
A geometry literal from a spatial reference system that is incompatible with the spatial reference system used for calculations
can the geof:buffer function add a metric buffer around a line in CRS84?
(some background: in Apache Jena, this calculation currently fails with an error, because CRS84 is not a metric SRS)
I see there is a new geof:metricBuffer, presumably this function would be able to do so in any case?
The only difference between the geof:metricBuffer and the geof:buffer function is that the unit in geof:metricBuffer is fixed to meters. (this is the same for all "metric" functions in GeoSPARQL 1.1)
However, you may as well use the function geof:buffer for a metric buffer, as long as you give it a metric unit as a parameter.
Both functions return a Geometry representation e.g., a WKT Polygon, which represents the buffer area in the CRS of the input geometry literal.
Both functions are also not restricted by Geometry type. So defining a buffer around a LineString is a valid operation.
The output of the function geof:buffer is intentionally not more precisely defined in GeoSPARQL 1.0 and 1.1. So you could return any literal type. In fact, triple stores returned very different things for buffer, as we found out in the GeoSPARQL 1.0 compliance benchmark.
So according to your opinion, a metric unit is not an invalid argument and the triple store is required(?) or suggested(?) to do the conversion->metric->calculate->spheric, even though obviously it's not possible to do a metric calculation on CRS84 directly?
Ultimately that is a task up to the implementers to decide. It is also valid to say that a conversion is impossible, as the unit does not correspond to a unit defined in the used CRS, and to throw an exception.
You might say that this is underspecified, and you might be right.
However, this is likely nothing we can fix in GeoSPARQL 1.1, as we need to be backward compatible with GeoSPARQL 1.0 where the geof:buffer function was initially defined. It might be in scope for a GeoSPARQL 1.2 iteration where we make more substantial changes to the standard.
#468 asks whether uom:degree and uom:radian are valid units for geof:distance, geof:buffer, and assumes that uof:metre is valid (since it's used in an example).
@SimonBin you're more experienced with geo transformations than me, can you weigh in? Do you have concerns about geof:distance?
I have another concern about buffer: it produces circular arcs, but SF doesn't support arcs (though WKT maybe does, see #475). So should buffer produce a Polygon with many segments that approximate the arcs?
@VladimirAlexiev I guess it doesn't strictly "hurt" to support uom:degree -- in fact this is precisely one reason I opened this issue, because currently GeoSPARQL implementation of Apache Jena (due to a very strict reading of GeoSPARQL 1.0 spec) only supports uom:degree/radian when the CRS is using degree lat/lon (such as the default CRS84) (the literal is in degree lat/lon, so it is "incompatible" when trying to do some calculation in metres; currently as far as Jena is concerned, the workaround is to manually project into a metric CRS first)
however, for me as a user it seems much more practical to support metric calculation, on top of that making a "buffer" based on degrees will create not circular but oddly-shaped ellipsoids! for example, the current implementation of Apache Jena will create an ellipsoid polygon with the following bounding box:
99.9 79.9,
99.9 80.1,
100.1 80.1,
100.1 79.9
when you try to buffer a POINT(100 80) by 0.1 degree instead of the much more intuitive/metric
99.28 79.94, | 99.4 79.9,
99.64 80.12, | 99.4 80.1,
100.72 80.06, | 100.6 80.1,
100.35 79.87 | 100.6 79.9
("metric" buffer vs. buffer created by mathematically "adding" degrees)
Thanks @SimonBin ! I added #468 (comment) based on your explanation, can you please check whether it's accurate?
What are "metric" SRS: those using northing/easting?
@situx I definitely think the spec should include strong warnings about buffer, distance, area and their metric variants.
That the result may be inaccurate, or the repo may throw an exception if one uses an incompatible unit.
unit does not correspond to a unit defined in the used CRS, and to throw an exception.
Is "unit defined in the used CRS" defined formally in the OGC CRS specs, or is that commonly understood:
degree for "angular" CRSes and meter for "northing/easting" CRSes?
And a final questions: it seems to me that WGS 84 is unsuitable for engineering (metric) calculations.
Which is a bit of a problem since it's the default CRS, and the only one available for GeoJSON.
Should there be advice to use "northing/easting" CRSes if such metric calculations are needed?