Serve PostGIS as OGC API Features

OGC API Features is the JSON-first successor to WFS. Clients request GeoJSON over plain HTTP, and the server handles paging, spatial filters, and reprojection. neoserver reads features directly from PostGIS at request time. It does not copy or sync the data.

What you get

• A landing page, conformance declaration, and OpenAPI document for each workspace
• /collections/{id}/items with limit/offset paging and next links
• bbox, datetime, properties, and sortby parameters
• Output in any CRS the collection advertises. GeoJSON defaults to CRS84.
• CQL2 text filters with Basic Spatial Functions, compiled into parameterized SQL
• A queryables JSON Schema that also acts as the allowlist for filter properties
• Per-layer access rules, including workspaces that are public but contain private layers

In the console

The console tutorial walks through every step with screenshots.

1. Create a workspace for the project. It keeps stores, layers, styles, and credentials separate from other projects. See Create a workspace.
2. Add a PostGIS store. Enter the host, database, account, and schemas, then choose Test connection before saving. The account only needs SELECT on the tables you publish. See Connect a data source.
3. Discover and publish. Choose Add layer, select the tables and views to publish, and give each a stable public ID. To publish a query instead of a table, choose Add SQL view on the store. See Discover and publish layers.
4. Check the result in Preview, which renders the layers on an interactive MapLibre map.
5. Connect clients from Endpoints. It shows the OGC API URL, checks access, and provides ready-to-copy examples for curl, Python, JavaScript, and QGIS. Create a scoped API key for each application, or make the service public in workspace settings.

With the management API

Every console action calls the same management API, so you can script the same setup:

curl -X POST http://localhost:9000/api/v1/workspaces/demo/services \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "production",
    "type": "postgis",
    "connection_info": {
      "host": "postgres.example.com",
      "port": 5432,
      "database": "geodata",
      "user": "geo_reader",
      "password": "secret",
      "sslmode": "require",
      "schemas": ["public"]
    }
  }'

curl -X POST \
  http://localhost:9000/api/v1/workspaces/demo/services/production/layers \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"source_layer": "public.buildings", "public_id": "buildings", "title": "Building footprints"}'

The API tutorial covers the complete sequence.

Query features

OGC API Features is enabled by default for new workspaces:

curl -H "X-API-Key: $NEOSRV_API_KEY" \
  "http://localhost:9000/workspaces/demo/ogc/collections/buildings/items?bbox=13.0,52.3,13.8,52.7&limit=10"

curl -G -H "X-API-Key: $NEOSRV_API_KEY" \
  --data-urlencode "filter=height > 50 AND category = 'office'" \
  --data-urlencode "sortby=-height" \
  "http://localhost:9000/workspaces/demo/ogc/collections/buildings/items"

To see which properties a client can filter on, call /collections/buildings/queryables. QGIS, GDAL/OGR, and OGC API client libraries can connect to /workspaces/demo/ogc directly.

Same data, more protocols

A published layer isn’t tied to one protocol. Once WMS, WFS, or tiles are enabled in the workspace, the same buildings layer is served through them:

• WFS 2.0 for desktop GIS clients and transactional edits
• WMS 1.3.0 for rendered, styled maps
• Vector tiles for web maps

Full parameter reference: OGC API Features.