WFS en OGC API Features vergeleken

Het Forum Standaardisatie beheert twee lijsten die hier tellen. OGC API Features maakt deel uit van het pakket Geo-standaarden op de lijst Pas toe of leg uit. De pagina van dat pakket noemt het toepassingsgebied letterlijk:

OGC-API - Features Part 1 en Part 2 moeten worden toegepast bij het per REST API aanbieden voor derden van geografische object-informatie

Bron: Forum Standaardisatie, pagina Geo-standaarden, toelichting bij opname. Het besluit zelf luidt volgens dezelfde pagina dat het OBDO op 19 september 2024 instemde met het verplichten van OGC API Features deel 1 en 2 en OGC API Tiles deel 1, en met het aanbevelen van het Nederlandse WFS-profiel en het Nederlandse WMS-profiel.

Het WMS-profiel valt sinds hetzelfde besluit ook onder Aanbevolen; het kaartbeeld-verhaal staat bij WMS en WMTS.

OGC API Features heeft vier vastgestelde delen (1, 2, 3 en 5) en een ontwerp-deel 4. Alleen deel 1 en 2 staan op de lijst Pas toe of leg uit. Over de latere delen schrijft het Forum op de WFS-pagina: "Deel 3 en verder specificeren functionaliteit voor onder andere transacties, schema’s, en uitgebreide filters. Deze delen staan (nog) niet op de 'Pas toe of leg uit'-lijst." Bij OGC zelf zijn ze wel verder. De tabel zet de status van alle delen naast elkaar, met wat de PDOK-service Bestuurlijke Gebieden in zijn /conformance opgeeft.

Een leverancier die deel 3 of 5 aanbiedt, doet dus meer dan de verplichting vraagt; een aanbesteding die ze eist, moet dat zelf motiveren. Over de vraag wanneer een leg-uit gerechtvaardigd is, zie aanbesteding GIS-viewer eisen.

WFS 2.0 is een service-standaard met XML-aanroepen, OGC API Features is een REST-API met JSON. Het Forum beschrijft het zelf zo: WFS is "onderdeel van de eerste generatie" en wordt "gaandeweg vervangen door een nieuwe generatie op REST gebaseerde OGC API-standaarden". Voor het selecteren op eenvoudige criteria, met de mogelijkheid het coördinaatreferentiesysteem te kiezen, noemt het Forum OGC API Features meer geschikt.

Zo'n OpenAPI-definitie sluit aan op de regels voor overheids-API's; die staan op NL API Design Rules. De conformance-lijst van de PDOK-service verwijst zelfs naar de ADR-publicatie van Logius.

Het voorbeeld gebruikt de PDOK-dataset Bestuurlijke Gebieden, collectie gemeentegebied, en vraagt gemeente Haarlem op. Beide aanroepen zijn op 11 oktober 2026 gedraaid en gaven HTTP 200. Over PDOK als bron staat meer in het overzicht van open geodata en PDOK.

# OGC API Features: gemeente Haarlem, geometrie in WGS84 lengte/breedte (CRS84, de standaard)
curl -s -G "https://api.pdok.nl/kadaster/bestuurlijkegebieden/ogc/v1/collections/gemeentegebied/items" \
  --data-urlencode "f=json" \
  --data-urlencode "naam=Haarlem" \
  --data-urlencode "limit=1"

# Zelfde vraag in RD: crs kiest het stelsel, Content-Crs in het antwoord bevestigt het
curl -s -G -D - -o /dev/null "https://api.pdok.nl/kadaster/bestuurlijkegebieden/ogc/v1/collections/gemeentegebied/items" \
  --data-urlencode "f=json" \
  --data-urlencode "naam=Haarlem" \
  --data-urlencode "limit=1" \
  --data-urlencode "crs=http://www.opengis.net/def/crs/EPSG/0/28992" | grep -i "^content-crs"

Het antwoord bevat onder meer deze eigenschappen en een MultiPolygon in lengte en breedte. Het tweede commando gaf de header Content-Crs: <http://www.opengis.net/def/crs/EPSG/0/28992>.

"properties": {"code":"0392","identificatie":"GM0392","ligt_in_provincie_code":"27",
  "ligt_in_provincie_naam":"Noord-Holland","naam":"Haarlem"}

Dezelfde vraag aan de WFS-service van dezelfde dataset:

# WFS 2.0: dezelfde gemeente, met een FES-filter in plaats van een query-parameter
curl -s -G "https://service.pdok.nl/kadaster/bestuurlijkegebieden/wfs/v1_0" \
  --data-urlencode "service=WFS" \
  --data-urlencode "version=2.0.0" \
  --data-urlencode "request=GetFeature" \
  --data-urlencode "typeNames=bestuurlijkegebieden:Gemeentegebied" \
  --data-urlencode 'filter=<fes:Filter xmlns:fes="http://www.opengis.net/fes/2.0"><fes:PropertyIsEqualTo><fes:ValueReference>naam</fes:ValueReference><fes:Literal>Haarlem</fes:Literal></fes:PropertyIsEqualTo></fes:Filter>' \
  --data-urlencode "count=1" \
  --data-urlencode "outputFormat=application/json"

Dit antwoord bevat dezelfde gemeente met "crs":{"properties":{"name":"urn:ogc:def:crs:EPSG::28992"}} en RD-coördinaten, omdat u geen srsName opgaf.

Het volgende Node-script (Node 18 of nieuwer) roept beide services aan en toont de naam, het identificatienummer en de eerste coördinaat. Zo ziet u in één oogopslag dat de objecten gelijk zijn en de coördinaten niet.

// Node 18 of nieuwer. Haalt gemeente Haarlem op via OGC API Features en via WFS 2.0.
const OGC = 'https://api.pdok.nl/kadaster/bestuurlijkegebieden/ogc/v1';
const WFS = 'https://service.pdok.nl/kadaster/bestuurlijkegebieden/wfs/v1_0';

const ogcUrl = new URL(OGC + '/collections/gemeentegebied/items');
ogcUrl.search = new URLSearchParams({ f: 'json', naam: 'Haarlem', limit: '1' });

const filter =
  '<fes:Filter xmlns:fes="http://www.opengis.net/fes/2.0"><fes:PropertyIsEqualTo>' +
  '<fes:ValueReference>naam</fes:ValueReference><fes:Literal>Haarlem</fes:Literal>' +
  '</fes:PropertyIsEqualTo></fes:Filter>';
const wfsUrl = new URL(WFS);
wfsUrl.search = new URLSearchParams({
  service: 'WFS', version: '2.0.0', request: 'GetFeature',
  typeNames: 'bestuurlijkegebieden:Gemeentegebied',
  filter, count: '1', outputFormat: 'application/json',
});

for (const [naam, url] of [['OGC API Features', ogcUrl], ['WFS 2.0', wfsUrl]]) {
  const res = await fetch(url);
  const fc = await res.json();
  const f = fc.features[0];
  const eerste = f.geometry.coordinates[0][0][0];
  console.log(naam, res.status, f.properties.naam, f.properties.identificatie, f.geometry.type, eerste);
}

Uitvoer op 11 oktober 2026:

OGC API Features 200 Haarlem GM0392 MultiPolygon [ 4.645161917512311, 52.42196465138656 ]
WFS 2.0 200 Haarlem GM0392 MultiPolygon [ 104523.402, 492942.613 ]

Voor omrekening tussen beide stelsels, bijvoorbeeld om zo'n RD-punt op een achtergrondkaart te zetten, kunt u de RD-naar-WGS84-tool gebruiken.

De volgorde van de assen verschilt per combinatie van service en CRS. Eigen test op 11 oktober 2026, voor dezelfde gemeente met EPSG:4258 (ETRS89 geografisch):

Een kaartbibliotheek zoals OpenLayers of MapLibre verwacht GeoJSON in lengte, breedte. Vraagt u via OGC API expliciet om EPSG:4258, dan klopt dat niet meer en landt het object in de Indische Oceaan in plaats van bij Haarlem. Houd daarom het standaardstelsel aan voor weergave en gebruik crs alleen als u het resultaat in een ander stelsel nodig heeft.

Kies WFS als een afnemer of pakket alleen WFS spreekt, of als u functies nodig heeft die OGC API Features deel 1 en 2 niet bieden. Het Forum zegt dat WFS in "specifieke, complexe use cases" kan worden gebruikt "wanneer OGC-API-standaarden niet voldoen, middels het ‘leg uit’-principe". Denk aan bestaande desktoppakketten en koppelingen die al op GetFeature draaien. Bij een koppeling waar u zelf de regie heeft, kiest u beter de nieuwe standaard.

• Nieuwe publicatie. OGC API Features, met WFS alleen erbij als bestaande afnemers dat nodig hebben.
• Bestaande WFS. Laat staan, beschrijf hem in uw catalogus (zie DCAT-AP-NL) en plan de komst van een OGC API ernaast.
• Alleen een kaartbeeld. Dan gaat het niet om objecten; zie WMS en WMTS.
• Bestanden voor lokaal gebruik. Een download als GeoPackage is geschikter dan duizenden paginaverzoeken.

Een einddatum voor WFS bij PDOK of een verplichte uitfasering is in de geraadpleegde bronnen niet gevonden. Voor high value datasets vraagt de Europese verordening om API's; zie high value datasets.

• Andere eigenschapsnamen. Dezelfde dataset heet in OGC API ligt_in_provincie_naam en in WFS ligtInProvincieNaam. Code die beide spreekt, heeft een vertaaltabel nodig.
• Aliaspaden. De self-link in het OGC API-antwoord wees op 11 oktober 2026 naar /kadaster/brk-bestuurlijke-gebieden/, terwijl de documentatie /kadaster/bestuurlijkegebieden/ noemt. Bewaar het pad dat de documentatie noemt.
• Grote geometrieën. Eén gemeente leverde ruim 60 kB aan geometrie op. Vraagt u honderden objecten per verzoek, dan is een download of vector tile beter dan paginering.
• Verwarring met deel 3. Filteren met CQL2 werkt bij PDOK en deel 3 is sinds 2024 een OGC-standaard, maar het staat niet op de lijst Pas toe of leg uit. Een andere aanbieder hoeft het niet te ondersteunen; houd een uitwijkroute via de eenvoudige query-parameters van deel 1.
• Eerlijk gebruik. Cache en limiet staan op PDOK fair use en caching.