Open jdries opened 3 years ago
What would properties={"cloudcover":90, "platform": "S1a"}
translate to? Are they connected with "and" or "or"?
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. cloudcover < 90 AND platform = 's1a'
). Assuming that a CQL2 text parser will be implemented soon.
PS: cloud cover equality is probably not the best example...
yes, multiple properties would imply an AND condition in my interpretation cloudcover is indeed a special case: most search catalogs somehow don't seem to have a problem with specifying this as an equals and interpreting it as smaller than, but we may need to check the details on that!
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: https://github.com/Open-EO/openeo-api/issues/396 (what properties can be filtered on?)
or introduce a minimal (SQL-like) query language
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?