Skip to content
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

collection itemType can contain multiple types? #581

Closed
pvgenuchten opened this issue Nov 28, 2020 · 2 comments
Closed

collection itemType can contain multiple types? #581

pvgenuchten opened this issue Nov 28, 2020 · 2 comments
Labels
enhancement New feature or request

Comments

@pvgenuchten
Copy link
Contributor

when implementing #579 i was surprised to find only "features" as collection itemType.

Then i found that itemType is calculated from the 'default provider' at

collection_data = get_provider_default(v['providers'])

In case a dataset is exposed as features and maps (typical behaviour?) i'd expect both types to be available in collection-itemType

I suggest we allow collection.itemType to contain an array of types.

@pvgenuchten pvgenuchten added the enhancement New feature or request label Nov 28, 2020
pvgenuchten pushed a commit to pvgenuchten/pygeoapi that referenced this issue Nov 28, 2020
itemType as an array of types
@tomkralidis
Copy link
Member

As I understand it:

  1. pygeoapi configuration collection.type: this tips off pygeoapi whether this is a collection (which can have 1..n providers), or something else (like a STAC collection or a process atm). See docs for more information
  2. itemType: this is rooted in expressing various item types that are bound to features or records (e.g. rasters do not have a type). Note that itemType in OAFeat is also a string.
  3. pygeoapi configuration resource.provider.type: from docs:
The providers block is a list of 1..n providers with which to operate the data on. Each provider requires a type property. Allowed types are:
- feature
- coverage
- tile

A collection’s default provider can be qualified with default: true in the provider configuration. If default is not included, the first provider is assumed to be the default.
  1. Note that one can also derive how they can interact with the data from a collection response's link relations.

Based on this, the first provider.type (or provider.type=true) should be interpreted as is what the data format/type really is. So to render on a UI, the best bet is to either a. display all the provider.type values by assembling them all and including them in the dict that gets passed to the j2 template, or b. in the j2 template, looping through all the link relations and getting a flattened list of provider types. Option a seems easier at first glance.

@pvgenuchten
Copy link
Contributor Author

pvgenuchten commented Dec 1, 2020

Thanx Tom, yes if itemType is a string (and not adopted by all OGC API's), then we don't have much options

I guess the open api document will be leading to api developers in exploring the API. However other users, such as incidental human beings, search engine crawlers, traditional GIS clients, etc may arrive at a collection endpoint without being aware of the open api document (or how to consume it). I find the follow-the-links a bit too technical and loose for ease-of-use.

Even with OGC-API-Coverage not supporting the itemType parameter at the collection level (because they expect to have collections supporting both coverage as well as a feature output), the spec doesn't indicate that we can't add it as a vendor parameter...

closing this for now

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants