Clarification on Features Core Part 1 1.0 Conformance

Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Clarification on Features Core Part 1 1.0 Conformance

cheesybiscuits
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
[hidden email]
https://lists.osgeo.org/mailman/listinfo/pygeoapi
Reply | Threaded
Open this post in threaded view
|

Re: Clarification on Features Core Part 1 1.0 Conformance

Tom Kralidis
Hi Tom:

On Thu, Apr 1, 2021 at 12:39 PM Tom Christian <[hidden email]> wrote:
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.


You are correct.  OGC does not care about what the underlying data store is, or how it is accessed for
that matter (that's the whole beauty of the OGC WxS/API standards).

pygeoapi is OGC Compliant and a Reference Implementation.  When putting forth the implementation for
compliance testing to OGC, one provides a deployed endpoint for the CITE tests to assertions against,
not the actual software implementation.  In the pygeoapi case, our CITE compliance is based on
the Elasticsearch backend, which provides the functionality to make the instance compliant.  As mentioned,
see [1] for more information.

..Tom



 
Any clarification much appreciated, thanks.
Tom


_______________________________________________
pygeoapi mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/pygeoapi

_______________________________________________
pygeoapi mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/pygeoapi
Reply | Threaded
Open this post in threaded view
|

Re: Clarification on Features Core Part 1 1.0 Conformance

xbartolone
In reply to this post by cheesybiscuits
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 <[hidden email]>, 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
[hidden email]
https://lists.osgeo.org/mailman/listinfo/pygeoapi

_______________________________________________
pygeoapi mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/pygeoapi