bro in plannen

Avoid subsurface surprises: 5 step BRO workflow for Dutch planners

Anne Dullemond

— 10 min read
Share
Avoid subsurface surprises: 5 step BRO workflow for Dutch planners

Use BRO early in your planning decision as authoritative evidence, but treat it as one input in a federated data architecture. Access it through BROloket, REST services or PDOK, and always record the source, the peildatum and the catalogue version alongside every referenced BRO-ID. The workflow that follows shows how to move from registration object to plan constraint without losing that provenance along the way.

TL;DR:BRO data should be linked through the appropriate channels based on the planning stage, with BROloket used for quick site checks and PDOK or SOAP for automated, ongoing data feeds.Only relevant BRO registration objects linked to the specific planning question—such as geotechnical, soil, or groundwater data—should be used to avoid unnecessary data overload.Always record the source, peildatum, and catalogue version for each BRO extract and link or copy data accordingly, depending on whether a live or static dataset is needed.When integrating BRO layers into 3D models or GIS, ensure coordinate systems and attribute mappings are aligned, and visualize uncertainty rather than treating data as precise or fixed.Maintaining a clear, documented checklist of BRO sources, versions, and limitations in the planning folder significantly improves transparency and future-proofing of subsurface claims.

3D CityplannerPut subsurface data into contextUse a 3D planning platform to compare development scenarios with GIS data, 3D city models, infrastructure and site constraints.Explore 3D Cityplanner

Table of Contents

What the BRO contains and which registration objects matter for planning

The Basisregistratie Ondergrond (BRO) is a layered registration of subsurface data, and not every layer answers the same planning question. Choosing the right registration object starts with the decision you are trying to support, not with the data that happens to be available.

For most spatial plans, a handful of registration objects carry the weight:

  • Geotechnical sondeeronderzoek (CPT) and booronderzoek inform bearing capacity and foundation choices for building massing.
  • Bodemkundig and geologisch booronderzoek describe soil composition relevant to infiltration, greenery and land use decisions.
  • Grondwatermonitoring and grondwaterstanden feed questions about drainage, basements, flood resilience and sustainable urban drainage design.
  • Sondeeronderzoek combined with geotechnical borehole data together support geotechnical risk assessment for infrastructure and parking structures.

The Handreiking aanleveren BRO-gegevens sets out how each registration object links to its scope, data catalogue, message catalogues and technical interfaces, which makes the BRO Productomgeving the reference point when you are unsure which object answers your question. A bearing capacity question points you towards geotechnical borehole and CPT data; a drainage question points you towards groundwater monitoring; a contamination screening points you towards bodemonderzoek records held outside the BRO in complementary registers. Matching the object to the question first avoids the common trap of pulling every available layer into a plan and then working backwards to justify its relevance.

How to get BRO data: channels, APIs and practical constraints

Four routes give access to BRO data, and each suits a different moment in the planning process. BROloket offers an interactive search and download interface, well suited to a one-off site check or a quick feasibility scan. PDOK exposes the same registration objects through OGC webservices and bulk ATOM feeds, making it the natural choice when you want a live layer inside a GIS project or a 3D viewer. REST services provide a self-describing, OpenAPI-based interface intended for incidental, programmatic access rather than bulk retrieval. SOAP services, by contrast, support automated or bulk delivery and are typically brokered through secure connections with PKI certificates, which suits recurring pipelines more than exploratory work.

  • BROloket: interactive search and download, ideal for individual site assessments.
  • PDOK OGC and ATOM: web services and bulk feeds, ideal for GIS layers and 3D scenario tools.
  • REST: OpenAPI-based, best for incidental or prototype queries, not bulk distribution.
  • SOAP: supports automated and secure bulk delivery, requires PKI authentication.

One channel rarely fits every stage of a project. According to the Handreiking afname BRO gegevens, REST is deliberately scoped for incidental access, while PDOK’s bulk feeds and brokered SOAP services are the intended routes for reproducible, automated exchange.

For a single feasibility check, BROloket is often enough. For a live map layer feeding a GIS and BIM integration workflow, PDOK’s OGC services are the more sustainable choice. For a municipal pipeline that refreshes borehole and groundwater data on a schedule, SOAP with PKI authentication, or a scheduled PDOK bulk download, avoids the manual re-extraction that REST was never designed to carry. When combining BRO with PDOK OGC services inside a 3D viewer, check coordinate transformations and vertical units closely: a small mismatch in z-units can quietly distort a foundation depth reading and mislead a bearing capacity decision.

A step-by-step BRO-in-planning workflow for projects and plans

A reproducible workflow keeps BRO data from becoming a pile of disconnected downloads. The BRO’s own guidance frames this as starting with the decision, not with the data, and the five steps below follow that logic through to documentation.

  1. Define the planning decision and the variables you need. A zoning change near a watercourse needs groundwater levels; a redevelopment site with new high-rise massing needs geotechnical bearing capacity data.
  2. Inventory the relevant BRO registration objects and complementary sources, noting every BRO-ID and peildatum you plan to use.
  3. Extract or connect to the data, recording the service or catalogue version, then run the spatial analyses and scenario comparisons the decision requires.
  4. Translate the findings into plan constraints: phasing choices, required further investigations, mitigation measures, all with provenance attached.
  5. Archive the extracts, update project metadata and communicate the remaining uncertainty to stakeholders in plain terms.

This sequence mirrors the practical approach described in the BRO’s own frequently asked questions, which recommends inventorying BRO and complementary sources before analysis, then translating findings into constraints and scenarios rather than presenting raw data as a conclusion. A stepwise urban development workflow built around 3D scenario comparison follows a similar logic, moving from site data to massing options to stakeholder-ready visuals.

Pro Tip: Save the exact API call, file name or export timestamp alongside every BRO-ID you cite. It costs a minute now and saves a re-investigation later when someone questions the plan’s evidence base.

Skipping straight to step three, pulling data before the decision is defined, is the most common way projects end up with irrelevant layers and unanswered questions.

Integrating BRO with 3D city models and local datasets

BRO data integrated with 3D city model

BRO data rarely stands alone in a planning project. It needs to sit alongside municipal GIS layers, cadastral information and, increasingly, a 3D city model or digital twin. Ministerial evaluation of the Wet BRO recommends an architectural approach that links BRO, the Digitaal Stelsel Omgevingswet, municipal datasets and 3D city models rather than merging everything into one system, a federated model rather than a single warehouse.

Deciding whether to link or copy data matters here. Linking through a live OGC service keeps your 3D model current with the latest BRO release, which matters for groundwater levels that change over time. Copying a static extract makes sense when you need a frozen snapshot for a formal plan submission, provided you record the peildatum used.

  • Keep coordinate reference systems consistent between BRO services and your municipal or 3D city model to avoid silent misalignment.
  • Align model resolution so borehole point data does not imply more precision than the surrounding terrain model supports.
  • Map attributes explicitly rather than assuming BRO field names match your local schema.
  • Visualise uncertainty, using opacity, confidence layers or distinct symbolisation for boreholes and groundwater readings rather than presenting them as fixed values.

These principles show up directly in planning practice. A feasibility study for building massing on a former industrial site benefits from geotechnical borehole data displayed alongside the proposed footprint. A sunlight or visibility analysis for public space gains little from subsurface data, but a parking capacity study for an underground structure depends heavily on it. The benefits of 3D city models for feasibility and stakeholder communication become sharper once uncertainty from underlying data sources is visible rather than hidden inside a flat colour fill.

Data quality, versioning and limitations: what to disclose in a plan

BRO is comprehensive within its scope, but it is not exhaustive, and treating it as a complete subsurface picture is one of the more frequent mistakes in planning practice. Complementary sources such as DINO archives, local LGR records and project-specific sondages often fill gaps that BRO’s registration objects do not cover, particularly for older contamination data or site-specific investigations commissioned outside the registration.

Version control deserves the same discipline applied to any other authoritative dataset. Pin the catalogue version, the service version and the peildatum for every extract, and save the extract itself rather than relying on a live query that may return different results next month.

  • Assuming completeness where BRO has no coverage for the site or period in question.
  • Mixing catalogue versions across different parts of the same analysis.
  • Ignoring quality flags attached to individual observations.
  • Treating a single borehole as representative of an entire development parcel.

Implementation notes on BRO access advise checking the registration object, data catalogue and peildatum before use, and archiving the extract for later reference, precisely because catalogue updates can otherwise go unnoticed.

Pro Tip: When borehole density around a site is low or readings are more than a few years old, treat that as a signal to commission targeted fieldwork rather than stretching the existing data to cover the gap.

Practical checklist and documentation to attach to a spatial plan

A short, consistent annex saves a plan’s evidence base from becoming unclear months after publication. The checklist below covers the fields worth capturing for every BRO-based claim in a dossier.

  1. State the planning decision the data supports.
  2. List the registration objects used, by name.
  3. Record every BRO-ID referenced in the analysis.
  4. Note the service and catalogue version used to extract the data.
  5. Record the peildatum for each dataset.
  6. Name complementary sources, such as DINO or local sondages.
  7. State known limitations, including data gaps or age.
  8. Recommend follow-up investigation where uncertainty remains material.
Field What to capture
Registration object Name of the BRO object used (for example, geotechnical booronderzoek)
BRO-ID Unique identifier for each referenced observation
Peildatum Reference date of the data extract
Catalogue version Version of the BRO data catalogue applied
Complementary source Name of any non-BRO dataset used alongside it

A short annex text might read: this plan uses BRO geotechnical and groundwater data, extracted via PDOK on the stated peildatum, catalogue version as recorded, supplemented by local sondage reports where BRO coverage was insufficient. That single paragraph, repeated consistently across a dossier, turns a subsurface claim into something a reviewer can trace and verify.

Applying BRO pragmatically in municipal practice

Applying BRO pragmatically in municipal practice — overview diagram

Most delays in using BRO data well are not technical, they are organisational. Teams often lack a shared starter template for a data room, so every project re-invents how to record sources and peildatum, and that inconsistency is what makes evidence hard to defend later. A short training session on the BRO Productomgeving catalogues, paired with a fixed checklist template, tends to remove more friction than any new tool.

Visualising subsurface constraints in 3D alongside proposed massing shortens the back and forth in stakeholder sessions considerably: a groundwater layer shown under a proposed basement makes a constraint self-evident in a way a report appendix rarely does. None of this replaces careful data governance. It rewards it, because a well-documented pipeline is what makes a compelling 3D scenario trustworthy rather than merely persuasive. The practical answer is not a bigger system, it is a smaller, repeatable habit: document the source, note the date, revisit it when the plan changes.

— Anne Dullemond

How 3D Cityplanner helps put BRO data to work in a plan

3D Cityplanner is a browser-based platform for designing, analysing and comparing urban development scenarios in 3D, and it connects to PDOK and OGC web services, which means BRO layers such as boreholes and groundwater readings can sit alongside proposed building massing, infrastructure and public space in the same view. For a feasibility study, that means a planner can show a client or council committee how a proposed footprint interacts with known subsurface constraints, rather than describing the constraint in a separate document.

In a stakeholder session, that combination shortens the explanation considerably: a 3D massing option next to a visualised groundwater layer answers a question that would otherwise take a written appendix to convey. Plans start with a Starter tier available, with Professional, Team and Organisatie tiers for larger teams, all detailed on the pricing page. Readers evaluating fit for a specific project can review the digital twin urban planning page or book a demo to see BRO and municipal layers combined in a live scenario.

Sources

FAQ

What is the BRO and why does it matter for spatial plans?

The Basisregistratie Ondergrond (BRO) is the Dutch national registration of subsurface data, covering boreholes, groundwater monitoring and geotechnical investigations. Planners use it as authoritative evidence for foundation, drainage and land use decisions, provided the source, peildatum and catalogue version are recorded alongside each claim.

Which BRO access route should I use for a one-off site check?

BROloket is designed for interactive, one-off searches and downloads, which makes it the practical choice for an individual feasibility check. For a live layer feeding a GIS or 3D scenario tool, PDOK’s OGC web services are a better fit than a manual export.

Is REST suitable for bulk BRO data extraction?

REST services are self-describing through OpenAPI and are intended for incidental, programmatic access rather than bulk distribution. For automated or large-scale exchange, PDOK’s bulk ATOM feeds or a brokered SOAP service with PKI authentication are the routes the handreiking afname recommends.

Does BRO data cover every subsurface question a plan needs?

BRO is comprehensive within its registered scope but not exhaustive, and older contamination data or site-specific investigations often sit in complementary sources such as DINO archives or local sondage reports. Where borehole coverage is sparse or dated for a site, that gap is a reasonable trigger to commission targeted fieldwork rather than relying on the existing registration alone.

How does BRO fit into a digital twin or 3D city model?

Ministerial evaluation of the Wet BRO recommends linking BRO with municipal datasets and 3D city models through a federated architecture rather than merging everything into a single system. Platforms such as 3D Cityplanner support this by connecting to PDOK and OGC services so BRO layers appear alongside proposed massing and infrastructure in the same 3D scenario.

Read more