Geoapi v2

[EPajares]

Context

There are the well-know Open-Source Geoservers such as Mapserver or Geoserver (confusing as it is same as the generic term). We are favoring at the moment a solution that can be integrated in Python (FastAPI). The main purpose of the Geoserver would be serving our geospatial data in different (OGC-compliant) formats. The following formats we would like to support at the moment:

• OGC API Tiles (MVT)
• OGC Features with Create, Update, Delete and Read
• OGC Maps (formerly WMS). We are not planning to have own WMS but just support 3rd party services.
• (if we cannot find OGC Features for Create, Update and Delete is not available we can consider doing this ourselves)

At the moment we are not sure if the Geoprocessing should also be realized using standardized procedures like OGC API Processes. Solutions we were finding are pygeoapi and tipg.

What I understand at the moment is that pygeoapi is reading the different services from a YAML config and has adapters to different data stores. For us most important is PostgreSQL/PostGIS. It seems that they are not having an own OGC API Tile or OGC API Maps service but instead only allows you to add your own services in the YAML.

Task

Overall, we need to know if we can use pygeoapi as our Geoserver solution. Currently, it might make most sense to see this as a separate microservice which is protected by the authz layer.

• Setup up pygeoapi and connect to a PostgreSQL/PostGIS DB
• Check if there is a way to load the config not from YAML but from PostgreSQL as a data store
• Check how pygeoapi behaves if we add a large number of layers (e.g. 1 million).
• How does it fit into a multi-tenant environment?
• How is performance?

### Tasks
- [ ] https://github.com/goat-community/goat/issues/2492
- [ ] https://github.com/goat-community/goat/issues/2493
- [ ] https://github.com/goat-community/goat/issues/2495
- [ ] https://github.com/goat-community/goat/issues/2496
- [ ] https://github.com/goat-community/goat/issues/2517
- [ ] https://github.com/goat-community/goat/issues/2527
- [ ] https://github.com/goat-community/goat/issues/2532
- [ ] https://github.com/goat-community/goat/issues/2771
- [ ] https://github.com/goat-community/goat/issues/2878
- [ ] https://github.com/goat-community/goat/issues/2925
- [ ] https://github.com/goat-community/goat/issues/2924

[EPajares]

In more recent discussion we concluded that it might be better at the moment to use tipg. One thing we would have to extend here though is Create, Update and Delete for features

[EPajares]

WIP

[EPajares]

We concluded using tipg (https://github.com/developmentseed/tipg) due to its high flexibility and smooth integration with FastAPI. We are having bit specific requirements as our geocatalog is saved in a database table and to avoid having potential several 100k of tables in our DB, we aim for a flattened DB schema in which one user will have a table per geometry type. So several layer for the user will be stored in one table.

We aim not to fork the project but instead make use of its modular nature and use the existing components wherever possible. For the following we might need custom implementations:

• register_collection_catalog
• collections._select_no_geo

This is a preliminary conclusion and we need further detailing.