Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    Stephan Meißl
    @Schpidi
    Hi Tom, unfortunately I'm not aware of any deployments following the latest draft of the spec. Hopefully there are some after the sprint next week.
    Stephan Meißl
    @Schpidi
    Hi all, we could provide access to free satellite data (products, mosaics, etc.) via Euro Data Cube https://eurodatacube.com to use for the sprint - please get in touch if you're interested
    Ingo Simonis
    @ingosimonis
    Hello everyone and welcome to the Sprint. We are about to start in a minute
    Remote participants, please join the GoToMeeting: Remote Participation Link: https://global.gotomeeting.com/join/259920029
    David Blodgett
    @dblodgett-usgs
    (closed) Issue regarding coverages vs coverage: opengeospatial/ogc_api_coverages#28
    Issue on coverage collections: opengeospatial/ogc_api_coverages#8
    Chuck Heazel
    @cmheazel
    Matthew Hanson
    @matthewhanson
    Added issue for discussion on collectionid vs coverageid: opengeospatial/ogc_api_coverages#50
    James Gallagher
    @jgallagher59701
    My issue with collectionid == coverageid might be because I'm late to the conversation. Has the case where a given data provider has a number of collections each of which have a number of coverages been covered? I'm thinking of providers like NASA, where the 'collections' are well known in the user community.
    Ingo Simonis
    @ingosimonis
    @jgallagher59701 this is somewhat covered by combining the various API elements. The API-Features can be used to describe a collection that is a number of coverages. In this case, each coverage is an individual element in the collection. Hierachies of collections is where it gets messy with generic APIs. This could be a place where best practice APIs need to be established.
    Peter Baumann
    @pebau
    @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!
    Peter Baumann
    @pebau
    @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.
    James Gallagher
    @jgallagher59701
    +1 - all users want to subset
    Peter Baumann
    @pebau
    ...in the domain (spatial, temporal) and in the range, say from a coverage with 50+ climate variables.
    James Gallagher
    @jgallagher59701
    right
    Aimee Barciauskas
    @abarciauskas-bgse
    @jgallagher59701 is the opendap server you mentioned open source?
    James Gallagher
    @jgallagher59701
    @abarciauskas-bgse yes, Hyrax is open and in GutHub
    Aimee Barciauskas
    @abarciauskas-bgse
    :bow:
    James Gallagher
    @jgallagher59701
    Peter Baumann
    @pebau
    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
    James Gallagher
    @jgallagher59701
    Tom Kralidis
    @tomkralidis

    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.

    yepremyana
    @yepremyana
    Peter Baumann
    @pebau
    result of discussion: new issue has been generated for OAPI-Common: opengeospatial/oapi_common#80
    Matthew Hanson
    @matthewhanson
    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
    Matthew Hanson
    @matthewhanson
    James Gallagher
    @jgallagher59701
    Jerome St-Louis
    @jerstlouis
    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 )
    Matthew Hanson
    @matthewhanson
    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
    Ziheng Sun
    @ZihengSun
    Tom Kralidis
    @tomkralidis
    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)
    amfriesz
    @amfriesz
    @tomkralidis Thanks
    Jerome St-Louis
    @jerstlouis
    ghobona
    @ghobona
    Have just added links to the data sources to the wiki https://github.com/opengeospatial/CoverageProcessAnalytics/wiki/Datasets
    Tom Kralidis
    @tomkralidis
    Should we list implementations on wiki or an Implementations.adoc page in the repo?
    Tom Kralidis
    @tomkralidis
    I issued opengeospatial/CoverageProcessAnalytics#2 then realized there is a wiki page, but I don’t have privileges to edit the wiki page
    Stephan Meißl
    @Schpidi
    I just merged #2 guess this is easier than the wiki
    Tom Kralidis
    @tomkralidis
    Richard Conway
    @rconway
    Input from Jerome for API convergence example...