Hi Marco,
It seems like such a rendering transformation would be very handy.
One question that I'd have is if there's an obvious way to let
DataStores push down the aggregations to the underlying databases?
Maybe there could be a GroupingVisitor that could carry out the
computation or represent the work that the DataStore would have to do
for the FeatureCollection?
I suppose I'm thinking about something like the MinVisitor:
https://github.com/geotools/geotools/blob/master/modules/library/main/src/main/java/org/geotools/feature/visitor/MinVisitor.java
which implementations can optimize for:
https://github.com/geotools/geotools/blob/master/modules/unsupported/solr/src/main/java/org/geotools/data/solr/SolrFeatureSource.java#L440-L449.
As a second thought/question, could aggregationAttribute be an
expression or would it need to be an attribute in the SimpleFeatureType?
In GeoMesa, we added a WPS process to compute statistics. This is
making me think of that process a little bit and some of the
optimizations which can be applied. So yeah, big plus one to this idea;
having this as rendering transformation should open up some interesting
styling options!
Cheers,
Jim
On 9/29/20 5:19 AM, Marco Volpini wrote:
Dear all,
I'm writing to propose the creation of a new vector rendering
transformation and have your feedback about it. The following listing
shows how it would appear:
|<Transformation> <ogc:Function
name="vec:GroupingRenderingTransformation"> <ogc:Function
name="parameter"> <ogc:Literal>data</ogc:Literal> </ogc:Function>
<ogc:Function name="parameter">
<ogc:Literal>groupByAttributes</ogc:Literal>
<ogc:Literal>attribute1</ogc:Literal>
<ogc:Literal>attribute2</ogc:Literal> ....
<ogc:Literal>attributeN</ogc:Literal> </<ogc:Function
name="parameter"> <ogc:Function name="parameter">
<ogc:Literal>aggregator</ogc:Literal> <ogc:Literal>min</ogc:Literal>
</ogc:Function> <ogc:Function name="parameter">
<ogc:Literal>aggregationAttribute</ogc:Literal>
<ogc:Literal>attributeName</ogc:Literal> </ogc:Function>
</ogc:Function> </Transformation>|
* the groupByAttributes parameter allows to define the feature's
attributes to produce the groups on which do aggregation;
* the aggregator parameter specifies the aggregation to perform (eg.
min/max);
* the aggregationAttribute provides the feature attribute used for
the aggregation.
For instance, in case of a min aggregation, the rendering
transformation will allow to return only the feature, for each group,
having the minimum value for the aggregationAttribute.
Moreover, in order to give a consistent result, the rendering
transformation will need to be fed with sorted features.
This would allow to overcome issues that would arise if sorting is
handled inside the RT:
* FeatureCollection sort method accepts only one SortBy object,
while the RT would allow to define more grouping attributes.
* The FeatureCollection sort method doesn't support ComplexFeatures.
In case the RT is issued through a sld, the sortBy attributes can be
defined through the vendorOption, while in case of a WPS process, they
can be provided through the Query object.
The output of the rendering transformation will be a FeatureCollection
wrapper, and the necessary computation will be performed in the
hasNext method of the corresponding FeatureIterator.
Best regards,
Marco Volpini
_______________________________________________
Geoserver-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
_______________________________________________
Geoserver-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
