wms wfs 3d

Dutch Planners: WMS, WFS and 3D in the Browser With No Desktop GIS

Anne Dullemond

— 7 min read
Share
Dutch Planners: WMS, WFS and 3D in the Browser With No Desktop GIS

Use WMS for 2D context and WFS for structured feature attributes. Three‑dimensional geometry should come from a 3D Tiles or CityJSON service, requested using the extents and identifiers a WFS query returns. This division is not a limitation. It is the standard architecture behind most working 3D GIS pipelines, from national data platforms to browser‑based digital twins.

TL;DR:WMS provides fast, rendered images for basemaps but offers no query or attribute access, making it unsuitable for analysis.WFS supplies structured feature data with geometry and attributes, enabling parcel selection, filtering, and integration into parametric models.3D geometry mainly comes from formats like 3D Tiles or CityJSON, retrieved via WFS for metadata and feature IDs, not streamed directly through WMS or WFS.Using GetCapabilities before integrating ensures support for required formats and avoids misconfigurations or unsupported output types.Combining WMS, WFS, and 3D models in a single platform accelerates feasibility studies, scenario testing, and stakeholder engagement, reducing manual data handling.

3D CityplannerPlan In 3D, Without Desktop GISExplore a browser-based platform for combining GIS data, 3D city models and scenario planning in urban development.Explore 3D Cityplanner

Table of Contents

WMS vs WFS in 3D GIS workflows: what each one actually does

WMS (Web Map Service) returns a rendered image, a picture of a map, not the underlying data. In a 3D planning project, it earns its place as a basemap: aerial photography, cadastral overlays, or a rendered topographic layer sitting under your model for orientation. You cannot query it, select a building from it, or extract an attribute. It is a picture, and it behaves like one.

Rendered map layer beneath 3D city model

WFS (Web Feature Service) returns structured feature data, typically as GML or GeoJSON, with geometry and attributes attached to every object. That is what makes it useful for anything beyond looking: selecting a plot, filtering buildings by height or function, or feeding a parametric massing model. The OGC WFS standard was built specifically to improve interoperability, giving planning teams a single, queryable source of truth instead of stale exported shapefiles passed between departments.

A few practical points worth flagging before you integrate either service:

  • WMS is fast to add and good for context, but has no analytical value on its own.
  • WFS supports outputFormat parameters (commonly GML2, GML3, or application/json), and not every server exposes all three.
  • Neither service, by default, carries usable 3D geometry, which is where the next layer of the stack comes in.

How 3D geometry actually reaches your model: 3D Tiles, CityJSON and WFS

Genuine 3D geometry, textured building meshes, terrain, infrastructure models, rarely travels through WMS or WFS directly. It is streamed through a dedicated 3D format designed for that job.

  1. 3D Tiles handle large-scale streaming of meshes and point clouds, tiled and level-of-detail managed so a browser client only loads what is visible. OGC 3D Tiles is the standard behind most performant web-based 3D city viewers.
  2. CityJSON is a lighter, developer-friendly format for exchanging semantically rich city models, buildings with attributes such as roof type, construction year, or function attached directly to the geometry, defined in the CityJSON specification.
  3. WFS as the connector. Rather than streaming meshes itself, WFS commonly supplies the metadata, feature IDs, bounding boxes, and height properties such as MinZ/MaxZ, that a client uses to request the matching 3D tile or CityJSONFeature.

Choose CityJSON when attribute richness matters more than raw rendering speed, such as energy modelling or heritage assessment. Choose 3D Tiles when you are streaming a whole municipality’s building stock and performance is the priority.

In-market examples: 3DBAG, PDOK and public services worth testing

The Netherlands offers one of the more mature public 3D data ecosystems in Europe, and it is a useful proving ground even for teams working elsewhere, because the pattern repeats across most national mapping agencies.

  • 3DBAG publishes conventional 2D WMS/WFS webservices for browsing and filtering buildings, alongside a dedicated API that returns full 3D geometry as CityJSONFeatures, documented in the 3DBAG webservices reference.
  • PDOK exposes national datasets, cadastral parcels, elevation models, land use, through standard OGC endpoints, and its viewer lets you check layer coverage before writing a single line of integration code.
  • Always request GetCapabilities first. It costs nothing and tells you exactly which layers, coordinate systems, and output formats a server actually supports before you commit engineering time to it.

Pro Tip: Run GetCapabilities against a new WFS endpoint before assuming it supports JSON output. A surprising number of public services still default to GML3, which trips up clients expecting GeoJSON.

How do you add WMS and WFS to QGIS, Civil 3D or a browser viewer?

Connecting these services follows a similar logic across tools, even though the menus differ.

  1. QGIS: use “Add WFS Layer” or “Add WMS/WMTS Layer” from the Data Source Manager, then inspect DescribeFeatureType to see the attribute schema before loading anything. Set outputFormat to JSON where the server offers it, it parses faster than GML.
  2. Civil 3D / AutoCAD Map 3D: connect through Data Connect or the equivalent Map 3D data store, and confirm the layer’s coordinate reference system matches your drawing before importing, mismatched CRS is the single most common cause of misplaced geometry in civil workflows.
  3. Browser-based 3D viewers: layer a WMS basemap for visual context, then issue WFS queries to fetch feature extents and IDs, and use those results to request the corresponding 3D tiles or CityJSONFeatures.

Before calling any integration finished, run through this checklist: service version (1.1.0 vs 2.0.0 behave differently), SRS/CRS declaration, bounding box syntax, outputFormat, paging parameters (startIndex, count or maxFeatures), and whether the endpoint requires authentication.

Building a WFS-to-3D-mesh pipeline: the developer pattern

The pattern behind most working implementations is consistent: query the WFS GetFeature endpoint, extract the extents and elevation properties, then use those to reconstruct or request the matching mesh.

  1. Send GetFeature with a bounding box or attribute filter to isolate the relevant footprint.
  2. Read the returned properties, MinZ and MaxZ are common where the geometry itself is flat, and use them to extrude or align the 3D volume.
  3. Request the matching tile from a 3D Tiles or CityJSONFeature endpoint using the feature ID or extent from step one.

Giro3D’s WFS mesh example demonstrates exactly this: querying a WFS layer and turning the returned features into styled 3D meshes client-side, without ever streaming a full mesh payload over the wire. That matters because WFS geometries are frequently two-dimensional footprints only, developers working with BIM-linked WFS layers routinely have to reconstruct the third dimension from properties rather than trusting feature.geometry to already contain it.

Requesting a separate mesh service using the spatial filters and IDs a WFS query returns, rather than streaming full meshes through WFS itself, cuts bandwidth and keeps permission models simpler for large municipal datasets.

Tile size is the main performance lever: too coarse and users load geometry outside their viewport, too fine and request volume balloons. Client-side mesh generation from raw MinZ/MaxZ values also carries a real CPU cost at scale, worth profiling before rolling out to a full city dataset.

Best practices and pitfalls to avoid with WMS/WFS 3D integrations

A handful of recurring mistakes account for most broken integrations.

  • Confirm the coordinate reference system before anything else, and prefer server-side reprojection where the service supports it rather than transforming client-side.
  • Page large WFS requests using startIndex and maxFeatures; pulling an entire municipal building layer in one call is a common cause of timeouts.
  • Use tiled formats (3D Tiles, CityJSON delivered in chunks) for geometry, and reserve WFS for what it does well: attributes, queries and edits.
  • Different data types suit different planning stages: point clouds and meshes work best for high-fidelity context, while vector and WFS data drive parametric calculations and capacity modelling.
  • Check licence terms and update cadence before building a workflow around any public dataset; a service that refreshes quarterly needs a different caching strategy than one updated daily.

The interoperability gain is real but specific: teams stop passing manual exports between departments and start querying a shared, current dataset instead, which is the actual operational benefit the WFS standard was designed to deliver.

What combining WMS, WFS and 3D models actually changes on a project

Feasibility work moves faster once these streams sit in one workspace. A basemap from WMS, parcel and zoning attributes from WFS, and a 3D massing model layered on top, that combination turns a stakeholder meeting from a discussion about a static render into a live conversation about alternatives. A recent redevelopment scenario I reviewed used exactly this stack: WFS-derived plot boundaries, a CityJSON building layer, and a sunlight analysis run directly against the massing. Questions that used to take a week of email got answered in the room, because a browser-based platform lets planners test alternatives on the spot rather than commissioning a fresh render for every variant.

— Anne Dullemond

Test WMS, WFS and 3D models directly inside 3D Cityplanner

Most teams piecing together WMS basemaps, WFS attributes and separate 3D tile services end up maintaining three disconnected tools and a lot of manual reconciliation. 3D Cityplanner is built to remove that step: it ingests WMS layers for basemap context, pulls WFS feature data for parcels, zoning and building attributes, and combines them with 3D city models in a single browser session, with no desktop GIS installation, no plugin chain to maintain.

In the demo environment, try adding a WFS layer for a site you know, fit the view to its extent, then build two massing scenarios side by side to compare development capacity and sunlight impact. It is a fast way to see whether the platform’s feature set fits your workflow before committing. Subscription pricing details are available on the pricing page.

Sources

FAQ

What is the difference between WMS and WFS in 3D GIS?

WMS delivers rendered 2D map images for visual context, while WFS delivers structured, queryable feature data with attributes, geometry, and often the height properties used to locate matching 3D tiles.

Can WFS deliver 3D geometry directly?

Rarely on its own. WFS geometries are often 2D footprints with MinZ/MaxZ properties attached, and full 3D volumes typically come from a linked 3D Tiles or CityJSON service.

What is 3DBAG and how does it relate to WFS?

3DBAG is a Dutch building dataset that publishes standard 2D WMS/WFS services alongside an API returning 3D geometry as CityJSONFeatures.

How does 3D Cityplanner use WMS and WFS data?

3D Cityplanner ingests WMS layers for basemap context and WFS feature data for attributes, then combines both with 3D city models in one browser-based workspace for scenario comparison.

Should I use CityJSON or 3D Tiles for my project?

Use CityJSON when attribute richness matters, such as energy or heritage analysis, and 3D Tiles when streaming performance across a large area, like a full municipality, is the priority.

Read more