You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
OpenSearch Geo & Time has a very broad scope and is meant for describing the URL structure of search engines with spatial and/or temporal filtering functions. The terms defined in that spec are restricted to WGS84 coordinates and RFC3339 Gregorian times. In coverage APIs there may be different requirements such as:
using spatial coordinates in the native CRS of the coverage (or the reprojection CRS as in W*S)
searching for times beyond the 4-digit year limit (paleoclimate datasets)
having more than one time dimension (model time and forecast time in weather forecasts)
The OpenSearch Geo & Time terms may be used directly for collection filtering if the above restrictions do not apply. However, for subsetting a coverage, the terms may only be used indirectly as the syntax for (currently) custom terms, since filtering in general is not subsetting and both operations may be used in a single API query, hence the need to differentiate between them. As noted in #4, the distinction between filtering and subsetting is not always clear though (correct me if I'm wrong).
The above notes should be added to the spec to guide implementers.
The text was updated successfully, but these errors were encountered:
OpenSearch Geo & Time has a very broad scope and is meant for describing the URL structure of search engines with spatial and/or temporal filtering functions. The terms defined in that spec are restricted to WGS84 coordinates and RFC3339 Gregorian times. In coverage APIs there may be different requirements such as:
The OpenSearch Geo & Time terms may be used directly for collection filtering if the above restrictions do not apply. However, for subsetting a coverage, the terms may only be used indirectly as the syntax for (currently) custom terms, since filtering in general is not subsetting and both operations may be used in a single API query, hence the need to differentiate between them. As noted in #4, the distinction between filtering and subsetting is not always clear though (correct me if I'm wrong).
The above notes should be added to the spec to guide implementers.
The text was updated successfully, but these errors were encountered: