Serve PostGIS and DuckDB as WMS

WMS is still the most widely supported way to put a styled map into a GIS client or web map. neoserver renders WMS 1.3.0 maps directly from PostGIS tables and DuckDB Spatial databases. The data stays in its source, and the styling lives in neoserver.

What you get

• GetMap as PNG, JPEG, GIF, TIFF, SVG, PDF, KML/KMZ, and MapML, plus GeoTIFF when the GDAL driver is available
• GetFeatureInfo as JSON, XML, HTML, or text for clickable maps
• GetLegendGraphic and DescribeLayer
• Server-side styling with SLD 1.0/1.1 and SE 1.1. CSS, YSLD, and Mapbox styles are also available once the dynamic-style extension is enabled.
• Time and elevation dimensions bound to source columns
• Vector layers and raster coverages mixed in one request, plus layer groups that act as a single named layer
• Limits on image size, pixels, features, vertices, and render concurrency, so one request can’t overload the server

In the console

1. Connect the source. In your workspace, choose Add store and pick PostGIS or DuckDB. For DuckDB, enter the database path and the native SRID of its coordinates. Choose Test connection, then save. See Connect a data source.
2. Publish layers. Choose Add layer, select the tables or views, and give each a stable public ID. That ID becomes the WMS layer name. See Discover and publish layers.
3. Style them. Create a style in the style editor, starting from a template or pasting existing SLD, then set it as the layer’s default style. You can add alternate styles that clients choose with STYLES=. See Styles and map preview.
4. Enable WMS in the workspace’s service settings, with a title, abstract, and image limits. WMS must also be enabled on the server (WMS.Enabled, or NEOSRV_WMS_ENABLED=true). See Workspace settings.
5. Preview the rendered map on the MapLibre map, with the style, opacity, and legend of each layer.
6. Connect clients. Endpoints lists the workspace’s service URLs and shows whether each is active. Add the WMS URL to your GIS client or web map, and give each client its own scoped API key, or make the service public.

With the API

Enable WMS for the workspace, then request capabilities and a map:

curl -X PUT http://localhost:9000/api/v1/workspaces/demo/settings/wms \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"enabled": true, "title": "Demo WMS", "max_width": 4096, "max_height": 4096}'

curl -H "X-API-Key: $NEOSRV_API_KEY" \
  "http://localhost:9000/workspaces/demo/wms?SERVICE=WMS&VERSION=1.3.0&REQUEST=GetCapabilities"

curl -o map.png -H "X-API-Key: $NEOSRV_API_KEY" \
  "http://localhost:9000/workspaces/demo/wms?SERVICE=WMS&VERSION=1.3.0&REQUEST=GetMap&LAYERS=buildings&STYLES=&CRS=EPSG:4326&BBOX=52.3,13.0,52.7,13.8&WIDTH=800&HEIGHT=600&FORMAT=image/png&TRANSPARENT=true"

WMS 1.3.0 follows the CRS axis order: EPSG:4326 uses latitude,longitude in BBOX, and CRS:84 uses longitude,latitude.

Serving map tiles too

The same layers and styles can be served as cached map tiles through WMTS and OGC API Tiles. This is usually the better choice for high-traffic web maps, because tiles can be seeded ahead of time. See Vector tiles from PostGIS.

Related

• Core concepts: workspaces, stores, and publications
• WMS 1.3.0 reference
• Serve PostGIS and DuckDB as WFS
• Publish GeoParquet and DuckDB data