Problems with passing geometries to aggregate_spatial

[jonathom]

I'm trying to pass geometries in aggregate_spatial, and it seems that this fails when the passed sf objects don't have any attributes. I'm creating geometries from a GeoJSON string with package geojsonsf like so:

library(geojsonsf)
pol_str <- '{ "type": "FeatureCollection", "features": [ { "type": "Feature", "properties": {}, "geometry": { "type": "Polygon", "coordinates": [ [ [ 5.636715888977051, 52.6807532675943 ], [ 5.629441738128662, 52.68157281641395 ], [ 5.633561611175536, 52.67787822078012 ], [ 5.636715888977051, 52.6807532675943 ] ] ] } }, { "type": "Feature", "properties": {}, "geometry": { "type": "Polygon", "coordinates": [ [ [ 5.622982978820801, 52.68595649102906 ], [ 5.6201934814453125, 52.68429152697491 ], [ 5.628776550292969, 52.683719180920846 ], [ 5.622982978820801, 52.68595649102906 ] ] ] } } ]}'
pols <- geojson_sf(pol_str)

to then aggregate
cube_s2_b8_agg <- p$aggregate_spatial(data = cube_s2_b8, reducer = function(data, context) { p$mean(data) }, geometries = pols)
which, upon job submission, fails with a JSON parsing error.

Everything works if I simply add attributes to the sf object (it contains two polygons):
pols$A <- c(4,5)

This seems impractical. Just wanted to report / document the work-around / ask for the reason causing this.

[flahn]

Thanks for the report. Interesting case.

> class(pols)
[1] "sf"         "data.frame"

I'm not sure if all sf objects inherit also from data.frame or if this is a special circumstance when using geojson_sf. That might point in the direction that adding attributes helps, because otherwise the data.frame would be empty. I'm not sure if I can fix this. Maybe I can include a work-around of some sort behind the scenes. I will keep that in mind.

[jonathom]

I'm not sure if all sf objects inherit also from data.frame or if this is a special circumstance when using geojson_sf.

class(st_sf(st_sfc(st_point(c(0,0)))))
[1] "sf"         "data.frame"

Now when you said that I was wondering aswell, but it doesn't look like it.

[jonathom]

Additionally, the aggregation doesn't yield the exact same results as if the same FeatureCollection is submitted via python or js client. This seems to be because coordinates are rounded in R client somewhere. The sf seems fine after converting via geojsonsf, only when saving as process graph the coordinates are rounded.

See these lines of the process graph, representing the first coordinates each:
R

                    [
                      5.6367,
                      52.6808
                    ],

JS

                    [
                      5.636715888977051,
                      52.6807532675943
                    ],

edit: Results are then for example:
R
3249.4653243847874
JS
3281.4298642533936

[flahn]

The geometries are serialized into text. At that point either the default amount of digits options(digits=...) is used or you can set the precision of the geometry with st_precision. Maybe the package geojsonsf also sets some default precision.

[flahn]

During serialization of JSON with jsonlite there was an default value on the number of digits to be used for numbers. Explicitly settint digit=NA during serialization removes the digit cap.

Other than that in future versions of openeo users shall use sf objects instead of a GeoJSON representation, as there are too many packages that deal with loading GeoJSON and they all return different kinds of geojson like objects that are hard to offer steady support to.