export stedenmodel gis

Dutch urban planning: export a GIS city model that runs in a browser

Anne Dullemond

— 8 min read
Share
Dutch urban planning: export a GIS city model that runs in a browser

For semantic exchange and multi-theme analysis, export to CityGML; for GIS pipelines and manageable file sizes, use CityJSON or CityJSONSeq; for web visualisation, choose 3D Tiles or glTF. Sample a small area first, apply tiling or streaming once you scale up, and request official extracts when a municipal viewer’s download limit gets in the way. Dutch national datasets typically hand you CityJSON and 3D Tiles by default, so plan your workflow around those two from the outset.

TL;DR:Choosing the correct export format depends on the downstream task; CityGML suits semantic analysis, while CityJSON and CityJSONSeq work better for GIS pipelines and streaming.Tiling and filtering before export improve manageability, and explicit CRS and vertical datum settings prevent errors in analysis or visualization.Public Dutch datasets typically provide CityJSON and 3D Tiles for analysis and visualization, with size and licensing considerations affecting download choices.Exporting a small test tile first helps identify CRS mismatches or missing textures early in the workflow, saving time on large-scale runs.Browser-based visualization platforms like 3D Cityplanner enable immediate stakeholder interaction and quick scenario testing after exporting clean, standards-compliant models.

3D CityplannerBring Your City Model Into PlanningUse a browser-based digital twin to analyse exported models, compare development scenarios and communicate proposals with stakeholders.Explore 3D Cityplanner

Table of Contents

Which export format should you choose for a city model?

Every export decision starts with the downstream task, not the source dataset. OGC’s guidance on 3D data exchange is blunt about this: there is no single best format, only the format that matches what you intend to do with the model. Get this wrong and you will spend more time converting files than analysing them.

CityGML remains the standard for semantic, multi-theme exchange. It carries rich attribute structures across buildings, vegetation, transport and terrain, which makes it the right choice for zoning cross-checks, utility coordination or any workflow that needs to query “what is this object and what does it belong to” rather than just “where is it”. Avoid it when file size or browser delivery matters. Full CityGML exports of a district can run into gigabytes, and it was never designed for client-side streaming.

CityJSON trades some of that verbosity for practicality. It is easier to parse programmatically, plays well with modern GIS and scripting environments, and is increasingly the default output from national data providers. CityJSONSeq, the JSON Lines variant, streams large exports feature by feature rather than loading a whole file into memory, though it only carries a subset of what a full CityJSON model supports, so check compatibility before committing a whole pipeline to it.

3D Tiles and glTF exist for one purpose: fast rendering in a browser or game engine. Do not assume they carry the semantic attributes you need for analysis; treat them as a visual layer, not an analytical dataset.

Beyond those three, a few formats solve narrower problems:

  • OBJ/STL — geometry only, useful for 3D printing or a quick visual sanity check, nothing else.
  • IFC — needed when you are coordinating with BIM teams on construction-level detail.
  • LAZ — compressed point cloud data, common when height or terrain accuracy matters more than building semantics.

Converting between any of these risks losing information: LoD4 interior geometry, template-based objects and custom attribute sets rarely survive a straight conversion untouched, so plan for that loss rather than discovering it after the fact.

Which export settings actually matter?

Getting the format right is only half the job. The settings you apply during export decide whether the file is usable, and whether it will even open, on the receiving end.

  1. Filter before you export. Spatial filters (bounding box or polygon), attribute filters and, in CityGML exporters, SQL or XML query expressions let you restrict scope before generation rather than trimming a bloated file afterwards. 3DCityDB’s CityGML exporter supports all of these plus LoD filters, so you only export the detail level the task requires.
  2. Tile large extents. Tiled exports write each tile to its own file using a consistent bounding-box scheme, which keeps individual files manageable and lets downstream teams load only the tiles they need. Adopt a clear naming and folder convention from tile one; retrofitting one across hundreds of files later is painful.
  3. Stream where memory is a constraint. 3DCityDB’s CityJSON exporter supports CityJSON versions 2.0, 1.1 and 1.0, and can output CityJSONSeq for streaming. Use it whenever a full in-memory export would choke the receiving application.
  4. Set the CRS and vertical datum deliberately. Define the target SRID and apply a coordinate transform explicitly rather than trusting a default. Document the vertical datum in use; mixing height references between a terrain layer and a building layer produces silent, hard-to-spot errors in sunlight or visibility studies.
  5. Check precision and quantisation defaults. Rounding vertex coordinates to a coarse number of decimal places shrinks file size but can distort measurements. Review the defaults, particularly if the export feeds an engineering or shadow-study workflow rather than a rough massing check.
  6. Package textures and compress. Bundle textures and ancillary files into the same ZIP or GZIP archive as the geometry, and use a replace-templates option if the target software cannot handle template-based geometry.

Pro Tip: Export one representative tile first and open it in your target software before committing to a full city-wide run. A five-minute test tile catches CRS mismatches and missing textures that would otherwise surface halfway through a multi-hour export.

What can you expect from public Dutch 3D datasets?

National and municipal data providers rarely hand you a single, all-purpose file. Understanding the split between visualisation and analysis products saves a lot of wasted download time.

  • Kadaster’s 3D Basisvoorziening separates the two deliberately: 3D Tiles for visualisation, and CityJSON or CityGML object datasets (3D Objecten Gebouwen, and the combined buildings-and-terrain variant) for analysis. Both are published under CC-BY 4.0, with datasets updated periodically, so check the version date before you build a feasibility study on it.
  • 3DBAG offers 3D Tiles at LoD1.2 to LoD2.2, WMS/WFS services and full GPKG dumps. The WMS/WFS layers only expose a 2D projection, not a genuine 3D export, so do not mistake them for analysis-ready geometry. A whole-country GPKG dump can run into tens of gigabytes compressed, which is worth knowing before you queue an overnight download on a laptop.
  • Municipal viewers typically allow small-area downloads directly, but larger extents often require a formal order form, and the dataset’s own metadata may restrict its use for legal or survey purposes.

Always check a dataset’s metadata for intended use, LoD, update date and data owner before treating it as fit for a planning decision. That single check has saved more feasibility studies than any export setting.

What is a reliable step-by-step export checklist?

A clean export is mostly about sequencing. Skip a step and you tend to discover it three tools downstream, usually at the worst possible moment.

  1. Define the downstream task and required LoD, then pick the format accordingly: CityGML for semantic analysis, CityJSON or CityJSONSeq for GIS pipelines, 3D Tiles or glTF for visualisation.
  2. Apply spatial and attribute filters, and test the configuration on one representative tile before running the full extent.
  3. Set the CRS and vertical datum, applying a coordinate transform if needed and recording the SRID used in your project notes.
  4. Choose tiling or streaming and compression settings, along with precision and quantisation values appropriate to the task.
  5. Bundle textures and ancillary files into the same archive, and add a README covering the metadata checklist below.
  6. Validate the export in the target software, checking for misaligned geometries, missing attributes or unexpectedly large file sizes.

That README is not optional paperwork. Dutch 3D standards guidance lists the fields a usable export needs to document: coordinate reference system, vertical datum, source datasets, update date, level of detail, object themes covered, licence and intended use. Without those seven items, whoever inherits the file downstream has to reverse-engineer assumptions you already knew, which is exactly how a promising site-feasibility exercise turns into a week of email threads asking “what datum is this in?”

How does a browser-based digital twin fit after export?

How does a browser-based digital twin fit after export? — overview diagram

Once a clean CityJSON, CityGML or 3D Tiles export exists, the next bottleneck is usually stakeholder communication, not data processing. Ingesting the export into a browser-based platform such as 3D Cityplanner lets a planning team run massing, sunlight and visibility checks against the model without reopening a desktop GIS session for every question a councillor or developer raises.

That matters most in early feasibility work: a municipality testing three redevelopment scenarios for a brownfield site, or a developer checking whether a proposed massing shades a neighbouring park at midwinter. Loading the exported model straight into a scenario environment turns a static export into something a planning committee can actually interrogate in the room, rather than waiting for the next iteration of static renders.

— Anne Dullemond

Turn your exported city model into a working scenario

Certain browser-based platforms ingest CityJSON, CityGML and 3D Tiles exports directly in the browser, without the need for a desktop GIS licence or local installation. That is the practical advantage over rebuilding scenarios from scratch in specialist 3D software: once your export is clean, you can be running massing comparisons, sunlight studies, visibility checks and development capacity KPIs the same afternoon.

For a municipality testing redevelopment options or a consultancy preparing a feasibility report, the platform’s urban design tools turn an exported dataset into a scenario stakeholders can actually walk through. Teams handling recurring exports and larger areas should look at the Team and Organisation plans, which start where the Starter plan’s 79 EUR per month tier leaves off. If your dataset is large or your onboarding needs support, contact 3D Cityplanner directly about implementation and project start services before you commit a full city-wide export to a new workflow.

Where to check the standards and dataset pages

Where to check the standards and dataset pages — overview diagram

For export mechanics, 3DCityDB’s exporter documentation covers CLI and GUI options in detail, and the OGC guide to 3D data exchange sets out the format-selection principles behind this article. For Dutch public data, consult the 3D Basisvoorziening dataset pages and 3DBAG’s documentation before you plan an extract.

Sources

FAQ

Which format should I export for GIS analysis?

Export CityJSON for GIS pipelines and programmatic analysis, or CityGML when you need full semantic detail across multiple object themes. 3DCityDB’s exporter supports CityJSON versions 2.0, 1.1 and 1.0, both directly usable in most modern GIS software.

How do I avoid memory issues on large exports?

Use tiling to split the export into manageable bounding-box files, and switch to CityJSONSeq (JSON Lines) for streaming rather than loading the entire model into memory at once. Testing on one representative tile before running a city-wide export catches most memory and configuration problems early.

What CRS and datum should I use?

Set the target SRID explicitly during export rather than relying on a default, and record the vertical datum in your project metadata. Mismatched height references between layers are a common, often invisible, source of error in sunlight and visibility analysis.

What metadata should every export include?

At minimum: coordinate reference system, vertical datum, source datasets, update date, level of detail, object themes and licence, as recommended in Dutch 3D standards guidance. A short README covering these fields saves the next person in the workflow from guessing.

Can I load an exported city model straight into a scenario tool?

Yes. 3D Cityplanner accepts CityJSON, CityGML and 3D Tiles exports directly, letting planners run massing, sunlight and visibility checks without a desktop GIS step in between. Current pricing for Starter, Professional, Team and Organisation plans is listed on the pricing page.

Read more