[QGIS-Developer] OGC API Features provider

[Stefan Keller]

Hi,

As I already talked about elsewhere I'm implementing a "minimal OGC-API Features
Server".

Now I'd like to test this service with QGIS as client. And I also
tested QGIS with the "kataster" service [1] the mentioned in the docs
[2].
Unfortunately I count not get both services to work (display) in QGIS.

* Our own service is being asked by QGIS with bbox and "limit=10&" any
time a zoom or pan occurs. But QGIS displays just 10 which are not
replaced by others whatever I do with QGIS.
* The kataster service asks about the CRS, then reports a large number
of features (which means there must be a different "limit="), and
finally does not answer requests from QGIS anymore.

Question 1: Any idea what QGIS makes it's OGC-API-Features reader to
add limit=10?

Question 2: Does anybody know about any another OGC-API Features
service we could use to test?

:Stefan


[1] https://www.ldproxy.nrw.de/rest/services/kataster
[2] https://gdal.org/drivers/vector/oapif.html




Am Di., 24. Sept. 2019 um 11:26 Uhr schrieb Even Rouault
<even.rouault at spatialys.com>:
>
> > 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.
>
> While I understand this idea, I see several difficulties:
> - the candidate providers are the feature one, a coverage and a tile / map
> one, but vector and raster providers have little in common
> - at the time of writing, to the best of my knowledge, only the OAPI-F has
> reached a sufficient degree of maturity in its spec and initial
> implementations. In particular while I think there is an intention to have a
> OAPI-Common at some stage, I don't think this has emerged yet (the current
> github repo for it is a copy&paste of OAPI-F), so making an abstraction with
> just a single implementation is not going to work well at that stage.
> - if looking at the existing providers in QGIS, the arcgisrest ones seem to be
> the closest to what you mention above. From what I see, the code between the
> AMS and AFS is quite separate, likely for the reasons I mentionned in my first
> point. They do have some utility functions qgsarcgisrestutils.h in common, so
> that would be more the kind of communality I can imagine if a OAPI-Tile/Map
> provider is later added. Perhaps things like parsing service metadata.
>
> Regarding the UI, I'm not completely sure of the best option. I can understand
> the opinion I got that reusing the WFS UI could be better because people are
> familiar with it, and that would limit the number of provider entries (people
> just have to figure out if the URL they are provided with is a WFS, OAPI-F or
> ArcGIS REST Feature one...). It can also makes sense if the OAPI-F stuff is
> added to the existing WFS provider.
> The other point of view, having a dedicated UI & provider, has also its
> advantages in term of code clarity (but provided the point below can be
> solved)
>
> > 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.
>
> I haven't completely given up on trying that idea. Just scares me :-)
>
> --
> Spatialys - Geospatial professional services
> http://www.spatialys.com
> _______________________________________________
> QGIS-Developer mailing list
> QGIS-Developer at lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer