geometry format and SRS of spatial aggregates may be undefined

[VladimirAlexiev]

10.10. Spatial Aggregate Functions defines these: geof:aggBoundingBox, geof:aggBoundingCircle, geof:aggCentroid, geof:aggConcaveHull, geof:aggConvexHull, geof:aggUnion. They produce a single geom from the geoms selected in a resultset.

• Section 10.9.1. Function Notes states "Functions returning a new geometry literal should follow the SRS defined in the literal format of the first geometry literal input parameter". 10.10. Spatial Aggregate Functions

• We can assume the same about aggregate functions

• But what if the resultset is unordered?

Please add this clarification:

---

10.10. Spatial Aggregate Functions

This clause defines SPARQL functions for performing spatial aggregations of data. They produce a single geometry from the geometries selected in a resultset (eventually grouped by some criterion).

Note: Requirement 40: Non-topological Query Functions (Non Simple Features) defines some functions that can also be aggregated, eg geof:metricPerimeter, geof:perimeter, geof:metricArea, geof:area. However, you can use the standard SPARQL sum() aggregate, so GeoSPARQL doesn't define special aggregate forms for them.

If the resultset includes geometries with differing format and/or SRS, please make sure the resultset is ordered. In that case, the guidelines of Section 10.9.1. Function Notes apply: "Functions returning a new geometry literal should follow the SRS defined in the literal format of the first geometry literal input parameter". Otherwise, the format and SRS of the result will be unpredictable.

[situx]

Yes, I agree with you that this may be underspecified. But I do not follow your reasoning regarding the resultset.

• We have a set of input parameters (ogc:geomLiteral). Yes, indeed, this may be unordered and may produce a different result for the same input if the input geometries differ in its SRS. This may be a problem... but that would not be the resultset; that would be the input set for me
• The resultset would be converted to one SRS, the SRS used in the first geometry of the input parameter set

[VladimirAlexiev]

@situx you're right, by "resultset" I mean the input to the aggregation, not the final resultset

[mperry455]

One approach could be to use a transform function on the input to the aggregate to give control over the SRS of the resulting geometry.

geof:metricArea(geof:transformCRS84(?geom))

[VladimirAlexiev]

@mperry455 if all input geometries use the same CRS then there's no problem. But if not and the input set is unordered, then there is a problem

@situx @nicholascar do you agree with the proposed clarification, in particular

please make sure the resultset is ordered