@jgallagher59701 : yes, this has been discussed, but then the decision presented has been made (not unanimously). One reason is that the Features group pushed the "view" perspective, ie: some coverages might also be seen as features, and vice versa. As has been stated by experts in the room that does not always work anyway. Second, AFAIK REST is not able to describe recursively nested items, such as collections of collections, of undefined depth. Personally, I very much like the idea of nested collections, maybe we can flesh out a suggestion?
@tomkralidis thanks for posting the link!
@jgallagher59701 another reason: there is a very justified requirement to be able to retrieve geo objects on a server regardless of the type (feature, coverage, coverage sub-type, etc.). So /collections/ would retrieve all objects (filtering might limit the number of hits, just to anticipate the concern). In case of nested objects the user would get back a tree essentially, and that has not (yet?) been included in OAPI Common. Challenge: can this be done in a way that is still simple to handle for the user? Looking forward to discussion.
re subsetting in a foreign CRS (ie, not the coverage's Native CRS), here is a (very brief) draft: https://github.com/opengeospatial/ogc_api_coverages/blob/extensions/extensions/crs.adoc
For the EO Subsetting breakout group: The notes are here: https://docs.google.com/document/d/1jZ9khoTEkLzlDYs-4eDQRbgAzECCVUNj7kzSs_Zz0oc/edit?usp=sharing
And there's an attendee list here: https://docs.google.com/document/d/1aGC_iZ2xeKDqLHQaVB2MphUPqAwNBymaYrbrYAa9L68/edit?usp=sharing
hi all: for those interested in pygeoapi, a branch for implementing coverages is in https://github.com/geopython/pygeoapi/tree/coverages
note: we are starting at ground zero, so I am implementing the core workflow that various backends can be glued to.
The Feature/Coverage/Processing API Convergence notes:
https://docs.google.com/document/d/1wix89MRMM9qgBUFbMJeyzttjfhsJfgvNMXwslVwqosA/edit?usp=sharing
https://docs.google.com/document/d/1wix89MRMM9qgBUFbMJeyzttjfhsJfgvNMXwslVwqosA/edit?usp=sharing
Here is a browsable STAC interface (discussed in convergence group): https://landsat.stac.cloud/
Note this is an older version of STAC, and it’s a static catalog (just a bunch of JSON files on s3), and not queryable
Note this is an older version of STAC, and it’s a static catalog (just a bunch of JSON files on s3), and not queryable
Overall architecture diagram for potential convergence is found in the OGC API - Common Best Practice ( https://github.com/opengeospatial/oapi_common/blob/master/19-072BP.pdf )
and in processes opengeospatial/wps-rest-binding#47
and in TB15 Machine Learning ER: http://docs.opengeospatial.org/per/19-027r2.html#_d105_ogc_api_features_service_recommendations
Here’s a STAC API, it’s got two collections: sentinel-s2-l1c and sentinel-s2-l2a, but just one Item in the sentinel-s2-l2a collection: https://fn8d3qzbhk.execute-api.us-west-2.amazonaws.com/omega
I can additional scenes as needed
I can additional scenes as needed
Another old version of stac-api documentation: http://sat-utils.github.io/sat-api/#tocsitemcollection http://sat-utils.github.io/sat-api/#tocsitem
FYI, as requested, in pygeoapi we are working on OGC API - Coverages initial implementation. For my part, I am working against the following sample data: https://github.com/geopython/pygeoapi/blob/coverages/tests/data/CMIP5_rcp8.5_annual_abs_latlon1x1_PCP_pctl25_P1Y.nc (CMIP5 NetCDF)
Fleshed out API convergence ideas: https://gist.github.com/jerstlouis/567acb48537a748ee9bee6f9659fcc1c
Have just added links to the data sources to the wiki https://github.com/opengeospatial/CoverageProcessAnalytics/wiki/Datasets
I issued opengeospatial/CoverageProcessAnalytics#2 then realized there is a wiki page, but I don’t have privileges to edit the wiki page
thanks @Schpidi implementations now at https://github.com/opengeospatial/CoverageProcessAnalytics/blob/master/Implementations.adoc
Please find attached fleshed out OGC API combination/convergence ideas following the first day of discussion at the Code Sprint.
Also at https://gist.github.com/jerstlouis/567acb48537a748ee9bee6f9659fcc1c with a comments-free version validating as JSON.
Also at https://gist.github.com/jerstlouis/567acb48537a748ee9bee6f9659fcc1c with a comments-free version validating as JSON.
@matthewhanson if you could help me correct the STAC filter (which I had no idea how to specify) that would be great
please start adding your contributions to the "end of sprint slides". We use the slide set used throughout the sprint, just add at the end: https://docs.google.com/presentation/d/1gMpGKc6JnsCHUATH21E1VWC-80ItvxMW8Wdkdhy4n-g/edit?usp=sharing
@ingosimonis sorry for the inconvenience, but I was not able to push my python notebook to https://github.com/opengeospatial/CoverageProcessAnalytics. I push the notebook out to my personal repo (https://github.com/amfriesz/ogc_openapi/tree/master/Notebooks). Would you be able to move the python notebook to the CoverageProcess Analytics repo?
hi all: small update: I added spatial subsetting to the pygeoapi server/demo just now if anyone wants to test.