Skip to content

Remove non-standard srs argument from mask_polygon #202

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 1 commit into from

Conversation

soxofaan
Copy link
Member

geojson as used in mask_polygon is EPSG:4326/WGS84 only and openEO API currently does not provide way to extend this.

Current implementation in DataCube (and ImageCollectionClient) provides an additional srs argument to specify an alternative reference system, which is non-standard, not supported by a backend as far as I know .
Also the coverage of srs is incomplete: only the code path that handles a shapely geometry uses srs.
Other code paths do not. While it could be possible to add it to the read_vector and dict code paths, it is not possible for the Parameter code path without extending the API

I would just remove the srs argument.

(related EP-3747, Open-EO/openeo-processes#53)

geojson as used in `mask_polygon` is EPSG:4326/WGS84 only, 
openEO API does not provide way to extend this.
Implementation in DataCube was non-standard and incomplete (e.g. related to `read_vector` and `Parameter` use cases)

related to EP-3747
@soxofaan
Copy link
Member Author

an alternative could be to let the client do the reprojection, but that still has problems: that would introduce new dependency on (e.g.) pyproj which is a non-trivial package to install . The Parameter use case would also still be a problem.

@soxofaan soxofaan requested a review from jdries April 19, 2021 10:07
@soxofaan
Copy link
Member Author

Apparently this geojson extension (from 2008 spec, e.g. "crs":{"type":"name","properties":{"name": ...) is being depended on by some (internal) use cases, so we can not just drop it. On the contrary, it would be better for usability to standardize it in some way ideally at level of openEO API itself.

anyway closing this PR

@soxofaan soxofaan closed this Apr 21, 2021
@soxofaan
Copy link
Member Author

also see discussion about how to tackle this (ideally) at openEO API level: Open-EO/openeo-processes#235

soxofaan added a commit that referenced this pull request Apr 22, 2021
…egate_spatial` and `mask_polygon`

Harmonize geometry handling in `aggregate_spatial` and `mask_polygon`, including handling of non-standard crs and whitelisting of allowed GeoJSON types
Raises warning when using a CRS for the geometry of `aggregate_spatial` and `mask_polygon`
Also mark this more clearly in the docs

Related: #202, Open-EO/openeo-processes#235, Open-EO/openeo-processes#53
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant