Filter Extension - Conformance classes realign #202
Conversation
philvarner
requested review from
m-mohr,
cholmes,
jbants,
lossyrob and
matthewhanson
extensions.md
Outdated
| @@ -69,10 +69,18 @@ the service supports. This are listed at the top of each extension description, | |||
| - <https://api.stacspec.org/v1.0.0-beta.4/item-search#fields> | |||
| - [Filter](item-search/README.md#filter) | |||
| - <https://api.stacspec.org/v1.0.0-beta.4/item-search#filter:filter> | |||
| - <https://api.stacspec.org/v1.0.0-beta.4/item-search#filter:simple-cql> | |||
| - <https://api.stacspec.org/v1.0.0-beta.4/item-search#filter:basic-cql> | |||
There was a problem hiding this comment.
all of these names align with the OGAFeat CQL2 names.
philvarner
changed the title
philvarner
requested review from
m-mohr,
cholmes and
jbants
and removed request for
cholmes,
matthewhanson,
lossyrob,
m-mohr and
jbants
| and dynamic content, so this behavior may be modified by setting the `additionalProperties` attribute in the | ||
| queryables definition to `true`. As such, any syntactically-valid term for a property will be accepted, and the | ||
| matching semantics are such that, if an Item does not have an attribute by that name, the value is assumed to be | ||
| `null`. It is recommended to use fully-qualified property names (e.g., `properties.eo:cloud_cover`). |
There was a problem hiding this comment.
Should we include something to explain that you can implement "simplified" access to complicated nested structures? So that you could add a queryable "common_band_name" that searches for a common name in eo:bands in assets?
There was a problem hiding this comment.
there's a section about that later in the doc, around line 300.
| AND datetime ANYINTERACTS 2021-04-08T04:39:23Z/2021-05-07T12:27:57Z | ||
| AND INTERSECTS(geometry, POLYGON((43.5845 -79.5442, 43.6079 -79.4893, 43.5677 -79.4632, 43.6129 -79.3925, 43.6223 -79.3238, 43.6576 -79.3163, 43.7945 -79.1178, 43.8144 -79.1542, 43.8555 -79.1714, 43.7509 -79.6390, 43.5845 -79.5442)) | ||
| AND eo:cloud_cover <= 10 | ||
| AND datetime >= "2021-04-08T04:39:23Z" |
There was a problem hiding this comment.
Wouldn't this usually be covered by a BETWEEN?
There was a problem hiding this comment.
It would, but BETWEEN is in the Advanced Comparison Operators conformance class, and I wanted these first examples to only use the Basic operators.
| ### Example 8: Spatial Disjunction | ||
|
|
||
| One limitation of the `intersects` parameter is that only a single geometry may be provided. While most | ||
| GeoJSON geometries can be combined to form a composite (e.g., multiple Polygons can be combined to form a |
There was a problem hiding this comment.
There's also the (discouraged?) GeometryCollection...
fragments/filter/README.md
Outdated
|
|
||
| #### Example 9: cql-text (GET) | ||
|
|
||
| ```javascript |
There was a problem hiding this comment.
Why are these snippets JavaScript? I guess http is more correct? (you may also want to include GET in front of the call?)
There was a problem hiding this comment.
cut and paste. I'll change them to have no language.
Co-authored-by: Matthias Mohr <webmaster@mamo-net.de>
Co-authored-by: Matthias Mohr <webmaster@mamo-net.de>
Related Issue(s):
Proposed Changes:
One difference with OAFeat CQL2 is that we do not require upper/lower as part of Advanced Comparison Ops, though I am reconsidering that. Now that IS NULL is part of the Basic CQL, LIKE is the only operator that can't otherwise be expressed in Basic CQL (e.g., IN and BETWEEN can be converted to more verbose clauses).
I would prefer that an implementor didn't need to implement function parsing to support this class, but I think, ultimately, it's not worth having this minor difference between STAC API and OAFeat CQL2, so I think we should defer to what OAFeat finalizes.
PR Checklist:
stac-specdirectory (these are included as a subtree and should be updated directly in radiantearth/stac-spec)