[QGIS-Developer] Approach for adding more OGC APIs to QGIS Server

[Jan Dalheimer]

Hello,

I've been wanting to implement more OGC APIs in QGIS Server but have run 
into a few questions I want to discuss before starting.

---

Currently, there's QgsServerOgcApi which is sort of a container for a 
single OGC API, and then handlers are registered to it for each 
endpoint. However, this is based on the assumption that each OGC API 
type is free-standing. However, the way OGC APIs have evolved, there's a 
strong incentive to combine OGC APIs and use them more like building 
blocks to build a complete API - you can have both OGC API Features, OGC 
API Tiles, and OGC API Styles "merged together", where Features and 
Tiles present the same data in the same collections optimized for 
different use-cases (Tiles for visualization at different scales, 
Features for picking individual objects given a set of filters) and 
Styles provide styles for rendering vector tiles from Tiles.

I can think of two main options:

A. Continue extending the wfs3 package with other OGC APIs. The name 
will be somewhat wrong/confusing but that's mostly to do with packaging 
and not something most users will notice. There'd be no way to install 
individual OGC APIs like you can with the older w[mfc]s packages, but 
the code changes to add new OGC APIs would be quite straightforward.
B. Put a "default" QgsServerOgcApi instance into QgsServiceRegistry and 
have one package per OGC API, which each add their handlers to the 
"default" QgsServerOgcApi rather than creating their own, while keeping 
the ability to create custom QgsServerOgcApi instances for backwards 
compatibility. A few changes to QgsServiceRegistry but nothing major, 
and makes it possible for plugins to extend the "default" OGC API 
endpoint. May want to put some functionality that's common across OGC 
APIs in the qgs_server target. The biggest challenge would be how to 
handle cross-OGC API-interactions, for example links between styles and 
tiles - maybe some sort of "link provider registry" which each OGC API 
endpoint handler calls to get additional links?

Personally, I'm leaning towards option A., it just feels way more 
straight-forward and easier to extend with additional OGC APIs, and I 
don't see that much value in having separate packages (but that might 
just be that I've not come across that use-case yet).

A third option would of course be to implement this in a plugin, however 
that would also require re-implementing the existing OGC API Features 
support in the plugin and I believe it makes sense for a standard 
implementation of the OGC APIs to exist in QGIS Server proper.

---

Also, are there any established guidelines when a new standard is 
accepted into QGIS Core? For example, would a PR with OGC API Styles 
(still in the draft stage) support be accepted? On the one hand I don't 
think there are any huge changes expected and implementation in major 
software can help the standard reach 1.0.0, on the other hand QGIS may 
then be stuck with an old version of the standard.

---

Regards,
Jan Dalheimer