<div dir="ltr"><div dir="ltr"></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Sep 23, 2019 at 8:51 PM Even Rouault <<a href="mailto:even.rouault@spatialys.com">even.rouault@spatialys.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">Hi,<br>
<br>
Just a quick note to mention, to avoid any potential duplication of work if <br>
someone else is about to do that, that in the coming weeks I'll work on adding <br>
support for "OGC API - Features" (previously known as WFS3) on the client <br>
side, now that it is about to be finalized to its 1.0 version.<br>
<br></blockquote><div><br></div><div>Hi Even,</div><div><br></div><div>I'm happy to see you taking this up!</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">
My initial thought would tend towards to try to add it into the existing WFS <br>
provider. From a UI perspective, I've got some feedback that it would probably <br>
be best to access it through the existing WFS entry to avoid cluttering the UI <br>
with a new provider.<br></blockquote><div><br></div><div>I would probably advise against this approach, from the architectural point of view, I think that it would be better to address the new OGC JSON-based API with an abstract base class for providers that consume that kind of API and make WFS3 the first concrete implementation of that base.<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">
On the code level, the choice between having a dedicated provider or adding <br>
functionnality in the existing WFS one is not so obvious. Technologically, <br>
there is little in common between traditional WFS ( XML & GML based, KVP based <br>
requests ), and OAPI-F (my own acronym for OGC API - Features) (JSON & GeoJSON <br>
based, with a linking approach). But the WFS provider has something which is <br>
quite useful for the OAPI-F context, which is the local Spatialite-based cache <br>
& the background download capability. Extracting that from the WFS provider <br>
and be generic enough for multiple providers could be quite involved.<br>
<br></blockquote><div><br></div><div>Re-using the WFS-sqlite feature cache looks a good idea, you might want to refactor it out to core to make it re-usable from a family of providers.<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">
Opinions about above directions welcome.<br>
<br>
Even<br></blockquote></div><br><div>Looking forward to test it against QGIS Server, we will be providing a complete client+server solution!</div><div><br></div><div>Thanks!<br></div><div><br></div><div>-- </div><div dir="ltr" class="gmail_signature">Alessandro Pasotti<br>w3:   <a href="http://www.itopen.it" target="_blank">www.itopen.it</a></div></div>