-
Notifications
You must be signed in to change notification settings - Fork 47
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
Filter Extension - Conformance classes realign #202
Filter Extension - Conformance classes realign #202
Conversation
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
all of these names align with the OGAFeat CQL2 names.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wouldn't this usually be covered by a BETWEEN?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There's also the (discouraged?) GeometryCollection...
fragments/filter/README.md
Outdated
|
||
#### Example 9: cql-text (GET) | ||
|
||
```javascript |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
cut and paste. I'll change them to have no language.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Added some comments, but nothing really blocking I think.
I love that this is now fully aligned!
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-spec
directory (these are included as a subtree and should be updated directly in radiantearth/stac-spec)