<div dir="ltr"><div>Hi Tom:<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Apr 1, 2021 at 12:39 PM Tom Christian <<a href="mailto:thomaschristian@gmail.com" target="_blank">thomaschristian@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">I'm attempting to resolve a question I raised in <a href="https://github.com/geopython/pygeoapi/issues/672" target="_blank">https://github.com/geopython/pygeoapi/issues/672</a> that was subsequently closed, with me being redirected to this mailing list.<div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div></div></blockquote><div><br></div><div><div>You are correct.  OGC does not care about what the underlying data store is, or how it is accessed for</div><div>that matter (that's the whole beauty of the OGC WxS/API standards).</div><div><br></div></div><div>pygeoapi is OGC Compliant and a Reference Implementation.  When putting forth the implementation for</div><div>compliance testing to OGC, one provides a deployed endpoint for the CITE tests to assertions against,</div><div>not the actual software implementation.  In the pygeoapi case, our CITE compliance is based on</div><div>the Elasticsearch backend, which provides the functionality to make the instance compliant.  As mentioned,</div><div>see [1] for more information.<br></div><div><br></div><div>..Tom<br></div><div><br></div><div>[1] <a href="https://github.com/geopython/pygeoapi/wiki/OGCCompliance">https://github.com/geopython/pygeoapi/wiki/OGCCompliance</a></div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div></div><div>Any clarification much appreciated, thanks.</div><div>Tom<br><div><br></div><div><br></div></div></div>
_______________________________________________<br>
pygeoapi mailing list<br>
<a href="mailto:pygeoapi@lists.osgeo.org" target="_blank">pygeoapi@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/pygeoapi" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/pygeoapi</a><br>
</blockquote></div></div>