You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
While working on #141/ Open-EO/openeo-geopyspark-driver#239 a lot of struggle was related to point handling and (ad-hoc) buffering of these to get a non-empty bbox with enough pixels to work with.
First problem is currently the hardcoded 10m buffering (which assumes Sentinel2 resolution I guess). Can this be made more generic and made dependent on the collection metadata?
But maybe even better is to eliminate the point buffering hacks we now have in various places (in openeo-python-driver, openeo-geopyspark-driver, ...) and move that to the logic that actually loads the pixels (where it is easier to buffer in terms of pixels)?
The text was updated successfully, but these errors were encountered:
While working on #141/ Open-EO/openeo-geopyspark-driver#239 a lot of struggle was related to point handling and (ad-hoc) buffering of these to get a non-empty bbox with enough pixels to work with.
First problem is currently the hardcoded 10m buffering (which assumes Sentinel2 resolution I guess). Can this be made more generic and made dependent on the collection metadata?
But maybe even better is to eliminate the point buffering hacks we now have in various places (in openeo-python-driver, openeo-geopyspark-driver, ...) and move that to the logic that actually loads the pixels (where it is easier to buffer in terms of pixels)?
The text was updated successfully, but these errors were encountered: