pdok/mapserver-wfs-ogr repository overview

⁠Mapserver WFS OGR

⁠TL;DR

docker build -t pdok/mapserver-wfs-ogr .
docker run -e MS_MAPFILE='/srv/data/example.map' -d -p 80:80 --name mapserver-example -v /path/on/host:/srv/data pdok/mapserver-wfs-ogr

docker stop mapserver-example
docker rm mapserver-example

⁠Introduction

This project aims to fulfill two needs:

1. create a OGC WFS⁠ service that is deployable on a scalable infrastructure.
2. create a useable Docker⁠ base image.

Fulfilling the first need the main purpose is to create an Docker base image that eventually can be run on a platform like Kubernetes⁠.

Regarding the second need, finding a usable Mapserver Docker image is a challenge. Most images expose the &map=... QUERY_STRING in the getcapabilities, don't run in fastcgi and are based on Apache.

⁠What will it do

It will create an WFS-only Mapserver application run with a modern web application NGINX in which the map=.. QUERY_STRING is fixed. The application will work best incombination with GDAL/OGR vector datasources like: Geopackage⁠ or SHAPE files.

⁠Components

This stack is composed of the following:

• Mapserver⁠
• OGR2OGR⁠
• Lighttpd⁠

⁠Mapserver

Mapserver is the platform that will provide the WFS services based on a raster datasource.

⁠OGR2OGR

For transforming simple features from a data store to WFS features.

⁠Lighttpd

Lighttpd is the web server we use to run Mapserver as a fastcgi web application.

⁠Docker image

The Docker image contains 2 stages:

1. builder
2. service

⁠builder

The builder stage compiles Mapserver. The Dockerfile contains all the available Mapserver build option explicitly, so it is clear which options are enabled and disabled. In this case the options like -DWITH_WFS are enabled and -DWITH_WMS are disabled, because we want only an WFS service.

⁠service

The service stage copies the Mapserver, build in the first stage, and configures NGINX and Supervisor.

⁠Usage

⁠Build

docker build -t pdok/mapserver-wfs-ogr .

⁠Run

This image can be run straight from the commandline. A volumn needs to be mounted on the container directory /srv/data. The mounted volumn needs to contain at least one mapserver *.map file. The name of the mapfile will determine the URL path for the service.

docker run -d -p 80:80 --name mapserver-run-example -v /path/on/host:/srv/data pdok/mapserver-wfs-ogr

The prefered way to use it is as a Docker base image for an other Dockerfile, in which the necessay files are copied into the right directory (/srv/data)

FROM pdok/mapserver-wfs-ogr

COPY /etc/example.map /srv/data/example.map
COPY /etc/example.gpkg /srv/data/example.gpkg

Running the example above will create a service on the url: http://localhost/example/wfs⁠? An working example can be found: https://github.com/PDOK/mapserver-wfs-ogr/tree/natura2000-example⁠

⁠Misc

⁠Why no WMS

If one wants a OGC WMS⁠ service, then we have our pdok/mapserver-wms-ogr⁠ image. So why are those (WFS and WMS) seperated? We regard both service as completly different. Regarding microservices it is logical to split those from each other. Also in our experience we have run to often into issues that the same data is exposed as a WMS and WFS.

⁠Why Geopackage

With our prefered way of usage the data source is copied into the Docker image. This makes the data also scalable, instead of putting all our different datasets into one (or two) big database that cannot scale up or down and are therefore scaled for max capacity.

⁠Why NGINX

We would like to run this on a scalable infrastructure like Kubernetes that has it's Ingress based on NGINX. By keeping both the same we hope to have less differentiation in our application stack.

⁠Used examples

• https://github.com/srounet/docker-mapserver⁠
• https://github.com/Amsterdam/mapserver⁠