-
Notifications
You must be signed in to change notification settings - Fork 13
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
How to handle feature-coverages? #25
Comments
I think we are closer that it looks. First, I do not think that items is equivalent to rangeset. In items you have properties with names and geographic objects with coordinates. In rangset you only have an array of numbers with no semantics whatsoever. To me you need to receive the full coverage description (domainset, rangeset and rangetype) to be at the same level of semantics as in items. Lets imagine that we have network of weather station that provides temperature and rain and the interpolation system to create a temperature coverage and a rain coverage. By doing https://acme.com/collections/foo_collection/coverages/temperature At the moment, |
Ahhh. I think I follow now. Thank you. In essence, the So we might have a cell-coverage that could be accessed The prospect of a coverage encoding that contains multiple variables is very real... NetCDF. In the case above, I may want to request specific variables from the coverage. That may be an argument to do: ??? |
yes, that's what the WCS Range Subsetting extension does; in GET/KVP notation (can also be POST/XML or SOAP): In practice, we are using this all over the place for band subsetting in hyperspectral image datacubes or variable selection in climate datacubes. |
So we might need another URL in the API: https://acme.com/collections/foo_collection/coverages?RANGESUBSET=rain,tmin,tmax to get a coverage in a format that allows more than one "range" (variable) as a response (netCDF, multipart...). This could be added to the current: If we go this route, then it might be good to use "coverage" instead of "coverages" and us the "collections" to separate coverages: I mean this will allow for I believe it opens the field for a nice integration between features and grid coverages. |
just a little addition:
good discussion! |
Please note that recently WFS 3.0 has include a "itemType" that might prevent the possibility discussed here (except if it is re-defined as an array). I would like to reconsider the decision. I hope it is not too late for that. |
API-Common defines a path up to /collections/{collectionid}/items. This path returns the content of the collection, but imposes no requirements on what that content must be. This is a job for the resource API (aka coverages). It seems to me that in the case of Coverages, /items could be an additional access path to RangeSet. The difference is that /items would inherit its behavior from API-Features while RangeSet would be based on WCS. Granted, not all coverages can be treated as a collection of Features. But as long as it fails gracefully I believe that use case can be addressed. |
there seems to be a tendency of "coverage is rangeset, plus something not really important". But coverage = { domainset, rangeset, rangetype, metadata }. Ignoring this means ignoring 15 years of discussion about importance of metadata and painstaking work to integrate them more seamlessly, in the WCS group and elsewhere.
A rangeset is really just a sequence of values, such as 1.456693,6.141732,12.20472,19.09449,22.40158,21.29921,24.6063,23.50394,21.85039,16.33858,9.448819,2.834646 ...no width/height information, no # dimensions, no spatial or temporal extent, no CRS, no range type (float, int, ...?), nothing. Think of the range set as a CSV or PNG (and even this is more than the rangeset in that it knows about x*y pixel numbers), but NOT as a TIFF. If we want to deliver a coverage then we must deliver /.../all (which is the compromise syntax we chose), all else is not a coverage. Maybe we devote some discussion in Bethesda to it to inspect this; the coverage tutorials also provide helpful information on coverage encoding (which is what we discuss here). Among others, I'd be curious what a "coverage from a feature perspective" concretely looks like, ie: a concrete example file. That might be helpful for discussion. |
I think this issue is solved / overcome by events, specifically: opengeospatial/ogcapi-common#140 A collection can now be potentially accessible as both a coverage and features.
Opened issue #99 to discuss subsetting by range type to address The |
Coverages SWG call: Agreed to close. |
It is common practice in hydrology to treat a collection of watershed features that cover the landscape as a coverage. This is also common with spatial units in various domains that can be thought of as a coverage.
There is also a very common practice where a grid (rectilinear or otherwise) can be accessed via index position. In this arrangement, the
i,j
position of a cell can be thought of as a feature identifier.In both cases, an individual entity can be identified uniquely as a feature, but it can be equally valid to access the "layer" as a coverage. From the perspective of OGC API, it would seem that we shouldn't actually make a distinction between coverages and features as unique kinds of data, but rather, support various operations on a given "layer".
So say we had a feature collection that could also be treated as a coverage, we might do:
https://acme.com/collections/foo_collection/items
as well as:
https://acme.com/collections/foo_collection/rangeset
Using this kind of arrangement, if a provider didn't want to allow access to the collection items, they wouldn't have to. Conversely, if a set of features really shouldn't be treated as a coverage of features, then the coverage functionality wouldn't be supported. But at the end of the day, functions/subsetting capabilities that operate on coverages and features could be applicable to either, right?
The text was updated successfully, but these errors were encountered: