added geocode method for resample spatial in the processes json

[suriyahgit]

Refer:
Open-EO/openeo-processes-dask#361
#552

[clausmichele]

@suriyahgit I proposed some changes. Let's see what @jdries and @m-mohr think about this PR.

[clausmichele]

Suggested change

"description": "Resamples the spatial dimensions (x,y) of the data cube to a specified resolution and/or warps the data cube to the target projection. At least `resolution` or `projection` must be specified.\n\nSome backends may additionally support `method=\"geocode\"` as a backend-specific extension. In this mode, the input data cube is rectified/geocoded using 2D geolocation layers such as `lon`/`lat` or `longitude`/`latitude`. These geolocation layers must be aligned with the spatial grid and may be provided as coordinates, data variables, or as dedicated bands in band-based data cubes. For `method=\"geocode\"`, a non-zero `resolution` is required. If `projection` is omitted, the backend defaults to EPSG:4326.\n\nRelated processes:\n\n* Use ``filter_bbox()`` to set the target spatial extent.\n* To spatially align two data cubes with each other (e.g. for merging), better use the process ``resample_cube_spatial()``.",

"description": "Resamples the spatial dimensions (x,y) of the data cube to a specified resolution and/or warps the data cube to the target projection. At least `resolution` or `projection` must be specified.\n\nSome back-ends may additionally support `method=\"geocode\"` as a back-end-specific extension. In this mode, the input data cube is rectified/geocoded using 2D geolocation layers, which must be provided as two bands with names `longitude` and `latitude`. These bands are dropped in the resulting cube. For `method=\"geocode\"`, a non-zero `resolution` is required. If `projection` is omitted, the backend defaults to EPSG:4326.\n\nRelated processes:\n\n* Use ``filter_bbox()`` to set the target spatial extent.\n* To spatially align two data cubes with each other (e.g. for merging), better use the process ``resample_cube_spatial()``.",

@suriyahgit in openEO there's no concept of coordinates or data variables, we have dimensions (spatial, temporal, bands, other). I'm not sure which name we should adopt for the special band names, since the user can set the desired output projection probably longitude and latitude are not fitting all the scenarios and we should use something more generic if possible.

[suriyahgit]

@clausmichele I used the terms coordinates and data variables because I was initially thinking of the dataset in terms of its representation as an xarray object, and also based on how datasets appear when loaded through a local connection in the openEO ecosystem. That said, I agree these terms are not strictly necessary here and can be removed.

[m-mohr]

As the methods enum is configurable and backends just choose this, it should be simple for implementors to remove it at a central place. Thus scattering descriptions for the methods in other parameters makes this hard to maintain. All changes needed for adding geocode should only be made in the method parameter schema/description ideally.

[suriyahgit]

reviews from @m-mohr accomodated - centralised the descriptions related to method="geocode" to the method description.

[m-mohr]

Suggested change

"description": "Resampling method to use. The following options are available and are meant to align with [`gdalwarp`](https://gdal.org/programs/gdalwarp.html#cmdoption-gdalwarp-r), except for `geocode`, which is a backend-specific geocoding/rectification mode:\n\n* `average`: average (mean) resampling, computes the weighted average of all valid pixels\n* `bilinear`: bilinear resampling\n* `cubic`: cubic resampling\n* `cubicspline`: cubic spline resampling\n* `geocode`: geocodes / rectifies data with 2D geolocation layers onto a regular target grid. This mode is intended for curvilinear or swath-like inputs where per-pixel geolocation is available. The current backend implementation requires a non-zero scalar `resolution`. If `projection` is omitted, the backend defaults to EPSG:4326. The `align` parameter is currently ignored for this method.\n* `lanczos`: Lanczos windowed sinc resampling\n* `max`: maximum resampling, selects the maximum value from all valid pixels\n* `med`: median resampling, selects the median value of all valid pixels\n* `min`: minimum resampling, selects the minimum value from all valid pixels\n* `mode`: mode resampling, selects the value which appears most often of all the sampled points\n* `near`: nearest neighbour resampling (default)\n* `q1`: first quartile resampling, selects the first quartile value of all valid pixels\n* `q3`: third quartile resampling, selects the third quartile value of all valid pixels\n* `rms`: root mean square (quadratic mean) of all valid pixels\n* `sum`: compute the weighted sum of all valid pixels\n\nValid pixels are determined based on the function ``is_valid()``.",

"description": "Resampling method to use. The following options are available and are meant to align with [`gdalwarp`](https://gdal.org/programs/gdalwarp.html#cmdoption-gdalwarp-r), except for `geocode`, which is a backend-specific geocoding/rectification mode:\n\n* `average`: average (mean) resampling, computes the weighted average of all valid pixels\n* `bilinear`: bilinear resampling\n* `cubic`: cubic resampling\n* `cubicspline`: cubic spline resampling\n* `geocode`: geocodes / rectifies data with 2D geolocation layers onto a regular target grid. This mode is intended for curvilinear or swath-like inputs where per-pixel geolocation is available. If `projection` is set to `null` or not provided, the backend reprojects to EPSG:4326.\n* `lanczos`: Lanczos windowed sinc resampling\n* `max`: maximum resampling, selects the maximum value from all valid pixels\n* `med`: median resampling, selects the median value of all valid pixels\n* `min`: minimum resampling, selects the minimum value from all valid pixels\n* `mode`: mode resampling, selects the value which appears most often of all the sampled points\n* `near`: nearest neighbour resampling (default)\n* `q1`: first quartile resampling, selects the first quartile value of all valid pixels\n* `q3`: third quartile resampling, selects the third quartile value of all valid pixels\n* `rms`: root mean square (quadratic mean) of all valid pixels\n* `sum`: compute the weighted sum of all valid pixels\n\nValid pixels are determined based on the function ``is_valid()``.",

Regarding:

The current backend implementation requires a non-zero scalar resolution.

The current state of the backend implementation should not be reflected in the specification, which should be stable over time regardless of the implementation.

Is this an implementation detail that will be solved later or is this generally difficult and we should just say:

Requires a non-zero scalar resolution.

The same applies to

The align parameter is currently ignored for this method.

where the "currently" is problematic. If a general implementation is possible, this should not be mentioned and can be adapted in the specific implementation and/or throw a corresponding error.