pass geometry object to aggregate_spatial()

[przell]

I tried using aggregate_spatial in a process graph on the eurac backend. The openEO help asks for a geojson. I tried to pass the object as character representing the geojson format, then as geojson r object. It wasn't accepted with the error:

[aggregate_spatial_WFXYI0331W] Parameter 'geometries': Class character not supported in GeoJson argument
[aggregate_spatial_JVVNO1794R] Parameter 'geometries': Class geojson not supported in GeoJson argument

Then I tried an sf object and it worked. For creating the node.
Then for sending the graph to the backend or converting it via as(x, "Process") it throws this error

> as(result, "Process")
Error in value[[3L]](cond) : 
  Error serializing parameter 'geometries' in process node 'aggregate_spatial_JVVNO1794R' :Unsupported value type.

Finally, I used the webeditor and created the graph by hand, then converted to R. The geometry object in aggregate_spatial should be provided as list

geometries = list("type" = "Polygon", 
                             "coordinates" = list(list(list(11.43151370647882, 46.8947771204201), 
                              list(11.42408903273992, 46.8947771204201),
                              list(11.42408903273992, 46.900314165242335), 
                              list(11.43151370647882, 46.900314165242335), 
                              list(11.43151370647882, 46.8947771204201))))

IMO it would make sense to adapt the error message from saying what it not accepts to what it accepts?

[przell]

@flahn, generally speaking: where could it be documented which classes are accepted for which arguments when building the process graph via the R-Client?

[Florian Lahn]

This is indeed hard to manage, because the functions are generated dynamically based on the functions and argument configuration of the back-end. In you case try ?GeoJson to read the documentation. The whole spatial object handling got reworked in the last weeks. The openEO processes define GeoJSON as exchange format for vector data, but my impression is that R users shall not be bothered with handling the vector format. Because of this sf objects are currently allowed as values.

With that said, I see that we are in utter need of a better documentation for this. All parameter types that are implemented for the processes are individually documented. What is missing is a proper entrypoint. Maybe I need to add the types as links to the Argument and Parameter class documentation. Other then that, this could be a section in a "Process Graph Building" vignette.

[Florian Lahn]

related to #64

[przell]

Thanks for the quick reply!

Summarising the options:

• Error messages that tell which object is accepted wherever a parameter takes spatial information (ultimately also temporal).
• Dedicated Documentation section for the parameter types: spatial, temporal, ...
• Add the types as links to the Argument and Parameter class documentation

And it would be great if there was a way to make sure that all arguments/parameters (spatial, temporal, etc. ) of the openEO processes are handled in the same way by the R-Client. Don't know if this is possible without manually going through all openEO processes?

@soxofaan @jdries @clausmichele: How do you handle this in the python client?

[przell]

Then specifically for aggregate_spatial(), passing a sf object didn't work when sending the process graph to the backend or trying to print the process graph via as(x, "Process")

Then I tried an sf object and it worked. For creating the node.
Then for sending the graph to the backend or converting it via as(x, "Process") it throws this error

as(result, "Process")
Error in value[3L] :
Error serializing parameter 'geometries' in process node 'aggregate_spatial_JVVNO1794R' :Unsupported value type.

[Stefaan Lippens]

In the python client we don't use dynamically generated functions and have a handcrafted DataCube.aggregate_spatial method that accepts as geometry one of:

• a shapely (popular library for polygons, multipolygons, ..) geometry object (which is automatically converted to GeoJSON structure)
• a dictionary in GeoJSON-style: has a "type" fields (one of "Polygon", "MultiPolygon", "Feature", "FeatureCollection", ...) and "geometry" or "features", ...

[Florian Lahn]

related to #67

[Florian Lahn]

Just to recap: the Python client uses a data structure that is closely related to GeoJSON.

For the R client I have several packages that handle GeoJSON (geojsonR, geojsonsf, geojsonio, ...). Each with different class outputs. If we use R geometry objects like from the widely adopted sf package for polygon data, i free my package from suggesting a specific geojson package. The user can chose how to import the vector data, as long as it comes as sf or sfc object. Thinking ahead, it might be the case that at some point in the future another format is supported or enforced by the openEO API and then a transition to a new format will be much more smoothly.

Addition: sf uses the OGR library and can read from GeoJSON to sf / write GeoJSON from sf (and other formats)

[przell]

I like that idea to stay out of the trouble dealing with the multitude of available json/geojson packages/representations in R!