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

[Alessandro Pasotti]

Hello Jan,

I am very happy to hear that you are interested in the OGC API server
development, I am currently busy implementing JSON-FG and schema
support as discussed in the QEP
https://github.com/qgis/QGIS-Enhancement-Proposals/blob/master/qep-414-server-oapif-jsonfg-flatgeobuf.md

More comments in the text below:

On Sun, Jun 28, 2026 at 9:32 PM Jan Dalheimer via QGIS-Developer
<qgis-developer at lists.osgeo.org> wrote:
>
> 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.
>

You are right, when I started the implementation of what at the time
was called WFS3 (now OAPIF) it wasn't entirely clear to me how the
different API would eventually be glued together.

Thas said, despite the poor choice of classes and files names (e.g.
Wfs3 instead of OAPIF), I think that the foundational architecture of
the base classes wasn't so bad: there is even an example of a custom
API (not an OGC standard) that provides a catalog of QGIS projects
(again not named very well): the landing page.

The catalog (landing page) is also a good example of a separate
package that can be installed and activatetd separately.

> 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,

That's actually not correct (see the landing page/catalog): you can
definitely package and register APIs individually.

> 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.
>

My advice is to open a QEP for your proposed changes, we can discuss
the details there.

Kind regards.

--
ItOpen:   www.itopen.it