BGT downloaden via PDOK: Download API en OGC API

De Basisregistratie Grootschalige Topografie (BGT) is een gedetailleerde digitale kaart van Nederland met objecten als gebouwen, wegen, water, spoorlijnen en groen. Het Kadaster bouwt en beheert de Landelijke Voorziening (LV-BGT). De bronhouders zijn gemeenten, provincies, waterschappen, ProRail en drie ministeries. Elke bronhouder is verantwoordelijk voor een eigen deel van de kaart.

In de Basisregistratie Grootschalige Topografie (BGT|IMGeo) standaarden staat beschreven hoe overheidsorganisaties de inrichting van de buitenruimte - wegen, water, groen, bebouwing - in Nederland digitaal vastleggen.

Bron: Geonovum, BGT | IMGeo, gelezen op 11 oktober 2026.

De BGT bevat de verplichte kern, IMGeo is de uitbreiding. Volgens Geonovum is het toepassen van de gegevenscatalogus BGT wettelijk verplicht. IMGeo laat bronhouders daarnaast meer objecten en meer detail uitwisselen, bijvoorbeeld bakken en palen in de openbare ruimte.

In de praktijk ziet u dat terug in de PDOK-collecties. Naast pand, wegdeel en waterdeel bevat de OGC API objecttypen als bak, paal, kast, mast en bord. Welke u gevuld aantreft, hangt af van wat de bronhouder heeft aangeleverd. Omdat IMGeo aanvullend is, hoeft niet elke bronhouder die objecten te leveren. Reken er dus niet op dat collecties als paal of bak landelijk dekkend zijn.

De downloadbestanden verwijzen naar IMGeo-schema versie 2.1 (de XML-namespace in onze testdownload); het model en de bijbehorende documentatie staan bij Geonovum. Wilt u de gegevens in een gemeentelijke kaartviewer tonen, lees dan ook GIS-viewer voor gemeenten.

Kies de OGC API voor een kaartvenster en de Download API voor een gebied of het hele land. PDOK biedt daarnaast WMTS en vector tiles voor weergave, maar die leveren plaatjes of tegels, geen objecten voor analyse.

De volledige procedure voor de downloadvarianten staat in de OpenAPI-beschrijving van de Download API en in het stappenplan van PDOK. Een eigen kopie van de BGT hosten en bijwerken is een beheertaak; zie GIS-beheer en hosting.

De OGC API Features werkt zonder key en geeft GeoJSON. Met bbox en bbox-crs geeft u een venster in RD op. Standaard komen de coördinaten terug in WGS84 (CRS84); met crs vraagt u RD. Het voorbeeld is op 11 oktober 2026 met Node 24 gedraaid.

const url = new URL('https://api.pdok.nl/kadaster/bgt/ogc/v1/collections/pand/items');
url.searchParams.set('f', 'json');
url.searchParams.set('bbox', '154150,462680,154250,462760');
url.searchParams.set('bbox-crs', 'http://www.opengis.net/def/crs/EPSG/0/28992');
url.searchParams.set('limit', '100');

const res = await fetch(url);
if (!res.ok) throw new Error('PDOK gaf status ' + res.status);
const fc = await res.json();

const actueel = fc.features.filter((f) => f.properties.eind_registratie === null);
console.log(fc.numberReturned, 'voorkomens,', actueel.length, 'actueel');
console.log(actueel.map((f) => f.properties.bag_pnd));

Uitvoer:

15 voorkomens, 6 actueel
[ '0307100000311531', '0307100000347585', '0307100000338918',
  '0307100000341963', '0307100000308303', '0307100000595635' ]

Het venster is 100 bij 80 meter bij het station van Amersfoort. De service gaf vijftien voorkomens terug, waarvan zes zonder einddatum. Een pand kan namelijk meerdere versies hebben; het eerste feature in het antwoord had een eind_registratie in 2017, terwijl een nieuwere versie van hetzelfde BAG-pand (0307100000338918) wel actueel was. De eigenschap bag_pnd koppelt het BGT-pand aan het pand in de BAG.

Een attribuutfilter bestaat niet. Een CQL-filter gaf status 400 met de melding "CQL support is not enabled for this API", en een onbekende queryparameter (bag_pnd=…) gaf eveneens 400. Selecteer dus ruimtelijk en filter in uw eigen code. Wie koppelt met de BAG, kan het 2D-pand daarna combineren met de 3D BAG voor hoogte.

Een custom download is asynchroon. U doet een POST met de objecttypen, het formaat en een optioneel geofilter, wacht tot de status COMPLETED is en haalt dan het zipbestand op. Het geofilter is een WKT-polygoon in RD; alleen Polygon en MultiPolygon zijn toegestaan en gaten (inner rings) worden niet ondersteund. De API verwacht format en featuretypes, en de formaatwaarden zijn citygml, gmllight en stufgeo.

BASE=https://api.pdok.nl/kadaster/bgt/download/v1_0

# 1. aanvraag: alleen panden, gebied als WKT-polygoon in RD (EPSG:28992)
RESP=$(curl -s -X POST "$BASE/full/custom" \
  -H "Content-Type: application/json" \
  -d '{"featuretypes":["pand"],"format":"citygml","geofilter":"POLYGON((154150 462680,154250 462680,154250 462760,154150 462760,154150 462680))"}')
ID=$(echo "$RESP" | grep -o '"downloadRequestId":"[^"]*"' | cut -d'"' -f4)

# 2. wachten tot de status COMPLETED is
until curl -s "$BASE/full/custom/$ID/status" | grep -q COMPLETED; do sleep 2; done

# 3. downloadlink uit de status halen en het zipbestand ophalen
LINK=$(curl -s "$BASE/full/custom/$ID/status" | grep -o '"href":"[^"]*extract.zip"' | cut -d'"' -f4)
curl -s -o bgt-pand.zip "https://api.pdok.nl$LINK"
unzip -l bgt-pand.zip

De POST gaf status 202 met een downloadRequestId. Het hele script duurde bij de test op 11 oktober 2026 ongeveer 41 seconden. Het zipbestand was 4.402.285 bytes groot en bevatte één bestand, bgt_pand.gml, van 67.690.421 bytes.

Het geofilter is niet exact. De OpenAPI-beschrijving zegt dat het filter het gebied limiteert, maar dat de download een overshoot aan objecten buiten de selectie kan bevatten. Bij onze test van 100 bij 80 meter was die overshoot groot. Het GML-bestand bevatte 25.385 BuildingPart-elementen. De eerste coördinaat van de elementen zonder einddatum lag tussen x 153.953 en 156.010 en tussen y 461.967 en 464.023, dus verspreid over ongeveer twee bij twee kilometer.

Daarnaast bevat het bestand ook beëindigde voorkomens. Van die 25.385 elementen hadden er 12.467 geen eindRegistratie; de rest is historie. Controleer de bestandsgrootte en het aantal objecten dus altijd, knip het gebied zelf exact bij met uw GIS-pakket en filter op eindRegistratie voordat u telt of toont. Gebruikt u dit voor een rapportage over één wijk, bouw dan die twee stappen vast in uw script.

Het spreidingsbereik is bepaald op het eerste punt van elk element. Zie het als een indicatie van de omvang van de overshoot, niet als maat voor een analyse.

• Lijnen, punten en vlakken zijn aparte collecties. Een object als kunstwerkdeel staat in de OGC API als kunstwerkdeel_lijn, kunstwerkdeel_punt en kunstwerkdeel_vlak. In de Download API is het één objecttype.
• Historie in alle routes. Zowel de OGC API als de download leveren voorkomens met einddatum. Filter op eind_registratie (OGC API) of eindRegistratie (GML).
• Standaard WGS84. De OGC API geeft zonder crs lengte-breedtegraden terug, terwijl het geofilter van de Download API RD verwacht. Zet beide expliciet.
• Trage grote verzoeken. Een verzoek met limit=1000 duurde bij onze test ongeveer elf seconden. Vraag kleine vensters en cache de antwoorden, zoals beschreven bij PDOK fair use en caching.
• Fouten in de kaart. PDOK verwijst voor wijzigingen naar de voorziening Verbeter de kaart; zie terugmelden bij basisregistraties.

De BGT beschrijft de fysieke buitenruimte, niet wie waar woont of eigenaar is. Voor adressen gebruikt u de BAG, voor percelen en eigendom de BRK en kadastrale kaart. Een achtergrondkaart voor een website bouwt u met WMTS of vector tiles, niet met feature-downloads. Hoogte komt uit de AHN of de 3D BAG.

Drie toepassingen laten zien hoe de BGT als ondergrond werkt. Een bomenregister vult de plek en het type uit de BGT aan met soort, aanlegjaar en beheergegevens. Een kaart van afvalcontainers legt containerlocaties tegen de standplaatsen in de BGT. Een begraafplaatsregister gebruikt de paden, het groen en het water op de begraafplaats als detailkaart.

Wilt u BGT-data omzetten naar een formaat dat uw systemen lezen, dan is GDAL het gebruikelijke gereedschap. Voor een viewer met BGT als ondergrond, zie GIS- en kaartoplossingen. Het overzicht van andere bronnen staat op de hub open data.