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 <[email protected]>: > > > 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 > [email protected] > List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer > Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer _______________________________________________ QGIS-Developer mailing list [email protected] List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
