aggregate_polygon with multiple bands?

[m-mohr]

In API v0.3 we implicitly assumed that zonal_statistics() (now: aggregate_polygon()) works on a single band and the user must select one beforehand with filter_bands. This hasn't changed in 0.4 yet, but I think we should either document that it only works on a single band or allow multiple band and document how the results are returned. As I'm not so much into zonal_statistics: How should it work? Single Bands? Multiple Bands?
cc @jdries @mkadunc

[edzer]

GIS world view: single band (layer). Spatial data cube world view: cube with two raster dimensions (x, y) reduced to single feature dimension (polygons).

[mkadunc]

What @edzer said. The ‘statistics’ part implies, i think, that we ‘ll aggregate over positions (i.e. compute statistics over all samples in a polygon) and leave other dimensions/axes intact - i.e. slice the cube in all other dimensions until you’re left with a 2D(x,y or lon,lat) raster of values, compute statistics over that raster with each polygon mask (to get a 1D array of stats objects - one stats per polygon) then combine these arrays into a new cube with layout consistent to the input cube : out[time,band,poly_idx,height] = stats(in[time,band,height, (ALL x,y where x,y inside polygon(poly_idx))])

[jdries]

For me this is coupled a bit with the issue about output formats:
#2
Supporting multiple bands is fine, as long as there is a decent (standardized) way to share the result. It looks like coverage json would be a good option for that, so I believe we can go ahead and allow it.
Perhaps it's also good to document what a backend should do if it does not support multi-band stats? (I believe that's the current state of my implementation.)

[m-mohr]

Yes, makes sense what @edzer said. Will add that to the documentation for now.
As we won't integrate CovJSON in 0.4 due to time constraints and probably need to change the process heavily for it anyway, we can introduce multi band stats together with CovJSON in 0.5 IMHO.

[m-mohr]

Improved the documentation and moved this issue to milestone v0.5 for further improvements as discussed above and in #2.

[m-mohr]

Is there still something to do here? Please leave a comment if you see further room for improvements.