Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Geoapi v2 #2419

Closed
11 tasks done
EPajares opened this issue Jul 18, 2023 · 3 comments
Closed
11 tasks done

Geoapi v2 #2419

EPajares opened this issue Jul 18, 2023 · 3 comments
Labels
epic An epic bundles several issues
Milestone

Comments

@EPajares
Copy link
Collaborator

EPajares commented Jul 18, 2023

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?
@EPajares EPajares added API and removed API labels Jul 19, 2023
@EPajares EPajares changed the title Test pygeoapi as Geoserver Pygeoapi as Geoserver Jul 19, 2023
@EPajares EPajares added this to the v2.0 milestone Jul 19, 2023
@EPajares EPajares changed the title Pygeoapi as Geoserver GOAT v2 Geoserver Jul 19, 2023
@EPajares EPajares changed the title GOAT v2 Geoserver GOAT Geoserver v2 Jul 19, 2023
@EPajares
Copy link
Collaborator Author

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
Copy link
Collaborator Author

EPajares commented Jul 24, 2023

WIP

@EPajares EPajares changed the title GOAT Geoserver v2 Geoapi v2 Aug 9, 2023
@EPajares
Copy link
Collaborator Author

EPajares commented Aug 9, 2023

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.

@majkshkurti majkshkurti removed the Epic label Sep 3, 2023
@EPajares EPajares added the epic An epic bundles several issues label Sep 5, 2023
@EPajares EPajares closed this as completed Oct 7, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
epic An epic bundles several issues
Projects
None yet
Development

No branches or pull requests

2 participants