FOSS4G 2022 general tracks

With our Lizmap hosting service, we provide and monitor several hundred of QGIS servers. These QGIS Servers receive and process 3.5 million requests per week, including 3 million WMS GetMap requests.

We do not control the content of these QGIS projects, which are sent by our customers on our servers. Therefore, we need to deal with projects having some various kind of issues. Some QGIS projects can have very heavy SQL views which are slow to load. Our infrastructure may host projects having hundreds of layers with complex symbology. Users can publish QGIS PDF layouts (A4 and A3) with custom logos etc. This can lead to memory problems.

GIS technicians can add different data sources : vector and raster files, PostgreSQL / PostGIS database, OGC WMS, WFS and WMTS web services into these QGIS projects. We need to ensure that QGIS Server is working properly, for all customers, to execute incoming requests when some external Web Services providers are too slow to respond or are temporarily offline.

We need to take care of possible errors propagated by these projects. In some circumstances, we have about 10 thousand errors per week coming from QGIS server.

The goal of this presentation is to give an overview of what QGIS Server can experience into the wild and what we need to do to make the Lizmap user experience the best possible: monitoring, proxy, caching.

PgMetadata is made for people using QGIS as their main GIS application, and PostgreSQL as their main vector data storage.

The layers metadata are stored inside your PostgreSQL database, in a dedicated schema. Classical fields are supported, such as the title, description, categories, themes, links, and the spatial properties of your data.

PgMetadata is not designed as a catalog application which lets you search among datasets and then download the data. It is designed to ease the use of the metadata inside QGIS, allowing to search for a data and open the corresponding layer, or to view the metadata of the already loaded PostgreSQL layers.

By storing the metadata of the vector and raster tables inside the database:

• QGIS can read the metadata easily by using the layer PostgreSQL connection: a dock panel shows the metadata for the active layer when the plugin detects metadata exists for this QGIS layer.
• QGIS can run SQL queries: you can use the QGIS locator search bar to search for a layer, and load it easily in your project.

The administrator in charge of editing the metadata will also benefit from the PostgreSQL storage:

• PostgreSQL/PostGIS functions are used to automatically update some fields based on the table data (the layer extent, geometry type, feature count, projection, etc.).
• The metadata is saved with your data anytime you backup the database
• You do not need to share XML files across the network or install a new catalog application to manage your metadata and allow the users to get it.

The plugin contains some processing algorithms to help the administrator. For example:

• a script helps to create or update the needed "pgmetadata" PostgreSQL schema and tables in your database
• a algorithm creates a QGIS project suitable for the metadata editing. This project uses the power of QGIS to create a rich user interface allowing to edit your metadata easily (forms, relations). Why use another interface when QGIS rocks ?

More PgMetadata features will be shown during the presentation:

• Modification of the template to tune the displayed metadata
• Export a metadata dataset to PDF, HTML or DCAT
• Publish the metadata as a DCAT catalog with Lizmap Web Client module for PgMetadata. It can then be harvested by external applications (Geonetwork, CKAN)
• The data model is very close to the QGIS metadata storage and the DCAT vocabulary for compatibility.

We will also show the last features such as the new support of the PostgreSQL rasters