Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    ghobona
    @ghobona
    The Github repo for the sprint is at https://github.com/opengeospatial/CoverageProcessAnalytics
    If there are any datasets that you would like to share for use in the sprint, please list them at https://github.com/opengeospatial/CoverageProcessAnalytics/wiki/Datasets
    Ensure that you have permission/licence to share the datasets.
    Tom Kralidis
    @tomkralidis
    Hi all, wondering if there are any OGC API - Coverages server deployments out there for testing?
    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