Need to finetune "property filtering" documentation

[soxofaan]

Triggered from the recent improved support for "queryables" (Open-EO/openeo-python-client#483, Open-EO/openeo-python-client#879, Open-EO/openeo-geopyspark-driver#536), I searched for coverage of "property filtering" in the CDSE docs to see if there are quick wins to improve/update.

---

https://documentation.dataspace.copernicus.eu/APIs/openEO/openeo_processing.html

Known issues
Property filtering depends on the data space catalogue, which currently has limited STAC capabilities. This sometimes prevents the usage of standardised STAC property names, which affects the portability of other process graphs.

Which is probably outdated information after the STAC migration. This whole "known issues" section can probably be removed (or given a better title).

---

https://documentation.dataspace.copernicus.eu/APIs/openEO/openeo-community-examples/python/Federation/FederatedProcessing.html

To avoid this, you can be explicit about which backend to use for a given ‘load_collection’ call, by using the property filtering mechanism:
properties=[collection_property("federation:backends")=="terrascope"]

This is the only usage of properties=[collection_property(... in code that got a bit of explanation.
However with the quickfix proposed under Open-EO/openeo-aggregator#198 this usage is going to trigger warnings, as illustrated in Open-EO/openeo-aggregator#199

---

https://documentation.dataspace.copernicus.eu/notebook-samples/openeo/Radar_ARD.html#specify-area-of-interest-temporal-extent-polarization

it only has this in a snippet, without explanation

    properties={"sat:orbit_state": lambda od: od == "ASCENDING"},

(note that this can be written more succinctly with collection_property helper

---

https://documentation.dataspace.copernicus.eu/APIs/openEO/openeo-community-examples/python/ManagingMultipleLargeScaleJobs/ManagingMultipleLargeScaleJobs.html

just usage of

properties={"eo:cloud_cover": lambda x: x.lte(60)}

which can be expressed less cryptic nowadays.

---

https://documentation.dataspace.copernicus.eu/APIs/openEO/openeo-community-examples/python/LoadStac/LoadLandsatSTAC.html

usage of

properties={"platform": lambda x: x == "landsat-8"},

which is an interesting use case to document
but it's with connection.load_stac instead of connection.load_collection

---

https://documentation.dataspace.copernicus.eu/APIs/openEO/openeo-community-examples/python/DynamicLandCoverMapping/Dynamic%20land%20cover%20mapping.html

usage of

 {"eo:cloud_cover": lambda v: v <= 80}

[soxofaan]

in summary:

• there is very little existing documentation in terms of real explanation about property filtering
• most examples promote outdated/cryptic usage patterns