[pygeoapi] Clarification on Features Core Part 1 1.0 Conformance

[Francesco Bartoli]

Hi Tom,

thanks for reaching us about pygeoapi. I’m going directly to the point: I don’t interpret the statement in the same manner you did. For example I would argue that the requirement 22 is an option, in fact its schema has a required: true property
name: bbox
in: query
required: false
schema:
 type: array
 minItems: 4
 maxItems: 6
 items:
   type: number
style: form
explode: false

so basically a collection can exist without necessarily support a bbox query parameter. Having pygeoapi offering a valid and compliant endpoint with a provider that serves a collection but do not support such search capability makes sense to me.

Also, I wouldn’t see your issue very specific to pygeoapi, in my honest opinion is general enough about the specification itself. So probably it is worth raising it to the github repository of OGC API - Features.

Regards,
Francesco
Il 1 apr 2021, 18:39 +0200, Tom Christian <thomaschristian at gmail.com>, ha scritto:
> I'm attempting to resolve a question I raised in https://github.com/geopython/pygeoapi/issues/672 that was subsequently closed, with me being redirected to this mailing list.
>
> Initially my question was how pygeoapi is conformant with Features Core Part 1 1.0 when several "providers" do not support bbox or datetime filters. I was informed that the providers have varying levels of support and this is OK. However, I am trying to determine how or where the OGC spec permits different levels of conformance based on source data type. From my reading of the documentation I did not think that this was an option.
>
> Tom Kralidis stated "this is irrelevant from the OGC viewpoint", but I don't understand how this is true - OGC should expect all collections to support bbox and datetime filtering because it doesn't care about how the data was accessed. If the spec says an implementation SHALL support bbox and datetime filtering then presumably all providers need to support that behaviour? Otherwise an API client who is unaware of each collection's data source will see varying levels of spec compliance with no indication as to why.
>
> Any clarification much appreciated, thanks.
> Tom
>
>
> _______________________________________________
> pygeoapi mailing list
> pygeoapi at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/pygeoapi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/pygeoapi/attachments/20210401/26ea60ef/attachment.html>