FOSS4G 2023

Using generic or standard content management system (CMS) like Wordpress or Strapi for managing geospatial data isn't an optimal solution. Since object geometry isn't just one of many data fields, it requires special handling for setting the data (e.g., on the map), storing data, transforming data for various needs (geometry output format, CRS etc.) and using them for spatial analysis.

When talking about a geospatial CMS, one would think that using GeoServer should be a must. How else would you vizualize a non-trivial amount of data on the map, right? Although Geoserver might be a good answer, that's not the only one. We, at our company, have developed our custom geospatial CMS using the OpenLayers mapping library on the frontend and PostgreSQL (with PostGIS, of course) on the backend, using PHP Laravel and GeoJSON as middle man between the data store and the frontend.

CMS platforms frequently have one specific feature. Different objects may have various attributes. Using the EAV (entity-attribute-value) model is one of the methods that is frequently utilized, although this choice usually comes with a number of issues, such as querying and storing the data. We used the possibility to swap out the EAV model for a straightforward json field in our CMS.

This talk will present what choices we had to make to build solution in such way and what some of our challenges were.