Add vector_buffer

[m-mohr]

Adds a new process "vector_buffer", see #264

If I understand https://openeo.vito.be/openeo/1.0/processes/backend/vector_buffer correctly (some ambiguities are present), it should be possible to merge both in a way that there's no conflict.

Implementations looked at:

• https://r-spatial.github.io/sf/reference/geos_unary.html
• https://openeo.vito.be/openeo/1.0/processes/backend/vector_buffer
• https://postgis.net/docs/ST_Buffer.html
• https://geopandas.org/en/stable/docs/reference/api/geopandas.GeoSeries.buffer.html
• ( https://developer.ibm.com/learningpaths/data-analysis-using-python/working-with-geospatial-vector-data-in-python/#buffer )
• https://developers.google.com/earth-engine/apidocs/ee-feature-buffer

Question:

• How to handle the number of segments per quadrant? -> leave up to implementation, be tolerant in test suite
• Should we allow negative distances? -> seems useful

[mattia6690]

I think that a negative buffer is very useful for many researchers to either exclude or specifically research areas at the boundaries of Polygons or in the vicinity of points and lines.
Otherwise the current structure is fine

[jdries]

We certainly use negative buffer distances.
Not sure about segments per quadrant, seems like a parameter that you can leave to the implementation?
Seems fine otherwise, hope we don't need to mathematically specify what a rounded buffer is.

[m-mohr]

Not sure about segments per quadrant, seems like a parameter that you can leave to the implementation?

@jdries I assume that would be an issue in the process validation suite if the implementations differ in the number of segments.

[jdries]

I assume that would be an issue in the process validation suite if the implementations differ in the number of segments.

Yes, when doing vector operations on the sphere, quite a few things can go wrong and need to be specified if you want absolute accuracy. So you would need to start by defining your error tolerances. Or make it dynamic, because if vector data is combined with raster, then there's no need to go far beyond the resolution of your raster cubes.
Another example is vector-pixel intersection tests, which you use in aggregate_spatial.

So my experience is that the validation suite will need to have some built-in leniency as to what the error can be for a specific process.

[m-mohr]

Okay, happy to keep it simple (except in the test suite). Then we can (until requested by users) define the process without such a parameter. Negative distances seem useful so then this is ready for review.

[m-mohr]

Merging as this seems to be finished, except for the general unit discussion in #330.