-
Notifications
You must be signed in to change notification settings - Fork 42
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
simplify specifying collection properties #246
Comments
What would Long-term it might make sense to adopt something like CQL2 text (see OGC APIs) as a simplified version instead of objects, which are more human-readable and flexible (e.g. PS: cloud cover equality is probably not the best example... |
yes, multiple properties would imply an AND condition in my interpretation |
or introduce a minimal (SQL-like) query language properties="cloudcover<90 and platform=s1a" that is converted by python client appropriately |
CQL2 text would be exactly that, which then you can also re-use for STAC API queries etc. And we could hope that we get a Python library from OGC API implementors so that we don't need to implement it ourself. |
related API issue: Open-EO/openeo-api#396 (what properties can be filtered on?) |
such a mini language could even be useful in other places, e.g.: cube.reduce_dimension("bands", reducer=" (B08 - B05) / (B08 - B05)")
mask = cube.apply("x == 4") that's actually a generalization of what's under construction under #255 |
In #331 I experimented with this approach: from openeo import collection_property
cube = con100.load_collection(
"S2",
properties=[
collection_property("eo:cloud_cover") <= 75,
collection_property("platform") == "Sentinel-2B",
]
) |
Currently, in load_collection, property filtering only seems to work with callbacks:
This increase the learning curve somewhat, and a lot of property filters are based on equality. So something like:
could be translated into a correct callback by the client?
The text was updated successfully, but these errors were encountered: