Add support for Spatial Aggregate functions

[situx]

Geospatial literals currently cannot be queried using traditional aggregate functions such as MIN,MAX,AVG.
However it may be useful to get the minimum or maximum X,Y or Z coordinate for a given set of geometries which is currently not possible in GeoSPARQL.
One use case could be: Finding a bounding box of a set of geometries for which a minimum X,Y and maximum X,Y coordinate of all geometries within a graph would be needed.
To my knowledge there is no such functionality currently available in GeoSPARQL.
My proposal:
Adding the following aggregate functions:
MINX, MINY, MAXX, MAXY, MINZ, MAXZ
In addition adding a BBOX aggregate method which would calculate a minimum bounding box of a set of geometries bound to a query variable.
I have not yet found a use case for an AVG aggregate function so I would neglect it, however, maybe there are some ideas about that from the community.

[situx]

I just discovered SPARQL-MM which might help with this issue.
https://github.com/tkurz/sparql-mm

[FransKnibbe]

This looks like a change request for GeoSPARQL. It should probably be added to the OGC issue tracker (http://ogc.standardstracker.org), if it's not already there.

[situx]

Thank you FransKnibbe, I have now filed it as request 626 http://ogc.standardstracker.org/show_request.cgi?id=626

[dr-shorthair]

A basic version of Temporal Aggregates is described in https://w3c.github.io/sdw/time-aggregates/

[jabhay]

MoSCoW poll created

[situx]

Even though we marked this issues as GeoSPARQL 1.1, we should think about which aggregates to define for GeoSPARQL 1.1.
I would include Aggregate functions for a Z coordinate, as the literals which are currently supported in GeoSPARQL all support Z coordinates.
If in the standardization process we decide to also accept T and L coordinates, then we should also add Spatial aggregate functions accordingly (MINT, MAXT etc.)
I am a bit undecided about M coordinates.
I believe WKTLiterals already support M coordinates, so an aggregate function like MINM,MAXM would make sense. But I am not sure about the other literal types.

[situx]

As we are working towards tackling this issue for GeoSPARQL 1.1:

I would propose the following functions to be included:

• MINX, MAXX, AVGX, MINY, MAXY, AVGY, MINZ, MAXZ, AVGZ functions
• BBOX function to calculate a minimum bounding box over the given geometry literals
• CENTROID function to calculate the centroid of the given geometry literals
• CONVEXHULL function to create the convex hull of the given geometry literals
• UNION function to create the aggregate union of all geometry literals

Functions from related work I am not sure whether to integrate them:

• CONCAT_LINES function to concatenate LineStrings represented by geometry literals
• CONCAVEHULL function to create the convex hull of the given geometry literals

Functions that need further discussions (GeoSPARQL 2.0):

• MINM, MAXM, AVGM and similar functions that depend on the consideration of T, L or further coordinates in the standard.

Are there any other spatial aggregate functions which I forgot that should be included?

[mperry455]

I do not see the MIN, MAX, AVG X/Y/Z aggregates supported by SQL Sever, Post GIS or Oracle. Would MIN/MAX be handled by BBOX? Also, what is the general use case for AVG X/Y/Z?

The others, including CONCAT_LINES and CONCAVEHULL, look good to me.

[FransKnibbe]

Wouldn't it be sufficient to have min and max x/y/z functions for single geometries? That is, if there is an aggregate bounding box function, which is useful to have anyway. Then one could just get the min/max coordinates from the bounding box.

[situx]

I do not see the MIN, MAX, AVG X/Y/Z aggregates supported by SQL Sever, Post GIS or Oracle. Would MIN/MAX be handled by BBOX? Also, what is the general use case for AVG X/Y/Z?

The others, including CONCAT_LINES and CONCAVEHULL, look good to me.

I agree that a BBOX function is sufficient if you could get the X,Y coordinates from it.

Maybe I do not know how to do this, but currently I do not know how to write a query like:
SELECT BBOX(?geo).MaxX WHERE {
?abc geo:asWKT ?geo .
}
But if we had a MAXX function we could state:
SELECT MAXX(?geo) WHERE {
?abc geo:asWKT ?geo .
}
Is there a better way to do this?

Referring to Frans:
Yes it is true with min/max functions per geometry we could work as well, but they would also need to be defined.

[mperry455]

I agree that it is a good idea to define MIN/MAX X/Y for a single geometry. Then we can use it for aggregates with BBOX, and it will also be useful in other non-aggregate cases.

[mperry455]

Based on the comments, it looks like a proposal would be:

Aggregates:
BBOX
CENTROID
CONCAT_LINES
CONCAVEHULL
CONVEXHULL
UNION

New Functions on Single Geometries:
MAXX
MAXY
MAXZ
MINX
MINY
MINZ

[nicholascar]

@situx since your additions based on this request are merged into master, can you review this and close if you're happy? We still have the OGC Change Request to close upon publication of 1.1.

[situx]

It is on my TODO. I will close it once my pull request for the fixes is finished

[nicholascar]

Please put a "Fixes #7" in the PR description so that, when merged, it will auto-close this.

[situx]

We have added this to GeoSPARQL 1.1 so I will close this issue