Kadastralekaart v5: overshoot aan objecten onwerkbaar

Datasets
#1

Beste,

In een poging onderstaande configurator uit te breiden met de kadastralekaart v5 ( PDOK API - Swagger UI )heb ik een aantal maal een full custom request gedaan.

Zoals bijvoorbeeld deze:
{
“featuretypes”: [
“perceel”
],
“format”: “gml”,
“geofilter”: “POLYGON((121243 487228,121293 487228,121293 487278,121243 487278,121243 487228))”
}

Met een Polygon van 50 bij 50 meter, doet de respons me echter meer vermoeden dat ik de percelen van heel Amsterdam terug krijg van het kadaster. Dat er een overshoot aan objecten buiten de selectie kon vallen werd in de uitleg aangekodigd. Echter levert dit me zoveel teveel informatie op dat ik het niet meer kan verwerken in Grasshopper.

Is er iemand die een idee heeft hoe ik toch de respons kan verminderen?

De uit te breiden configurator:

Alvast bedankt voor het meedenken,
met vriendelijke groet,

Thomas Broos

2 likes
#2

Beste Thomas
Dank voor je bericht goed dat je het post.
We zien inderdaad een grote overshoot en gaan ernaar kijken. Zodra we iets weten plaatsen we een post.

1 like
#3

Korte antwoord: Dat kan niet in de download API, maar zonder historie kan wel via de WFS.

Dit is het gedrag zoals het bedoeld is. De download apis zijn bedoeld om een deel van de DKK met of zonder (event verwerkings)historie (dus de wijzigingen op de wijzigingen) terug te geven in kmvakken van 2x2 km. Ze hebben altijd een overshoot, maar worden door ons wel ontdubbeld. Kleiner dan 2x2 km wordt het dus niet.

Voor data zonder historie kan je deze uit de WFS halen via het NGR.

3 likes
#4

Anouk, Roel,

Dank voor jullie snelle antwoord. In principe helder: het kan niet kleiner dan 2x2km.
Dit verklaard meteen de indruk die ik kreeg, zodra ik als locatie de Dam te Amsterdam invoerde. Binnen een van van 2x2km zijn er dan nogal wat percelen, haha.

Ik heb het daar links of rechtsom mee te doen. Dank dus ook voor je suggestie dus over de WFS.
Daarover komen er twee vervolg vragen in mij op:

1: Begrijp ik uit Perceel goed dat deze API ook json kan leveren? Dat zou mij toevallig enorm goed uit komen.

2: Wanneer je schrijft dat de data zonder historie geleverd kan worden, doel je dan op het volgende stuk zoals ik dat tot nu toe in de .gml kreeg? Als dat achterwege blijft zou dat al zo’n 15-25% aan data schelen geloof ik.

    <oz:historie>
        <h:beginGeldigheid>2006-10-17T15:21:27+02:00</h:beginGeldigheid>
        <h:tijdstipRegistratie>2006-10-17T15:21:27+02:00</h:tijdstipRegistratie>
        <h:volgnummer>0</h:volgnummer>
        <h:statusHistorie>
            <h:StatusHistorie>
                <t:code>G</t:code>
                <t:waarde>Geldig</t:waarde>
            </h:StatusHistorie>
        </h:statusHistorie>
    </oz:historie>

Wederom bij voorbaat dank voor het meedenken.
Met vriendelijke groet,

Thomas Broos

#5

Hoi Thomas,

  1. Ja, de WFS kan (Geo- ) Json leveren. Als je outputFormat=json toevoegt, dan krijg je netjes geojson terug (erg handig voor webclients zoals Openlayers bijvoorbeeld).

  2. De WFS levert alleen de actuele stand van zaken, dus daar vind je geen vervallen percelen terug. Hier vind je daar wat meer info over. Of dat data scheelt, ligt denk ik ook aan de wijze waarop je de OGC API bevraagt.

Persoonlijk heb ik me (nog) niet verdiept in OGC API’s, simpelweg omdat de WFS en WM(T)S voor mij nog prima voldoen, dus ik zie geen reden om over te stappen. Met 1 uitzondering: de historie van percelen. Als je daar de stand van zaken op een bepaald tijdstip mee zou kunnen opvragen, dan heb ik nog wel een interessante use-case daarvoor, afhankelijk van hoever je terug kunt gaan. Maar als het alleen mutaties zijn, dan is het denk ik teveel werk.

2 likes
#6

Een voorbeeld response van de WFS met jsonoutput (eerste resultaat):

https://service.pdok.nl/kadaster/kadastralekaart/wfs/v5_0?SERVICE=WFS&REQUEST=GetFeature&VERSION=2.0.0&TYPENAMES=kadastralekaart:Perceel&TYPENAME=kadastralekaart:Perceel&STARTINDEX=0&COUNT=1&SRSNAME=urn:ogc:def:crs:EPSG::28992&BBOX=135473.58228116630925797,456123.39204532216535881,135642.25492342610959895,456256.65818541665794328,urn:ogc:def:crs:EPSG::28992&outputFormat=application/json

Daar zie je beginGeldigheid attribuutwaarden. Het Kadastralekaart model heeft (o.a.) ook een eindGeldigheid. Als een object (Perceel in dit geval) nog geldig is, dan heeft dit veld geen waarde. Alles zonder eindgeldigheid is in de WFS terug te vinden (de reden deze niet terug te vinden is, is dat deze dus altijd leeg is). Precieze uitleg over deze modelattributen vind je hier.

1 like
#7

Stefan, Roel,

Beiden dank voor jullie reactie. Ik geloof dat ik hem begrijp. Ik moet eerst even het domein laten whitelisten op mijn systeem. Dus ik kan volgende week verder met bouwen denk ik. Wel heb ik door jouw voorbeeld (Roel), sterk het vermoeden dat dit gaat lukken zoals bedoeld. Als het totaal teveel is, dan gebruik ik de COUNT om ze per behapbare set aan te vragen.

Veel dank tot zo ver!

Thomas

#8

Ookal heb je er nu niets aan, er zal over enige tijd ook een OGC API tiles/styles (vectortiles) en features beschikbaar gaan komen voor de DKK. De ambitie is er al een tijdje maar het past nog niet helemaal in de planning. Houd je geinformeerd via het forum en check de nieuwsberichten van PDOK. Ik denk dat je met deze toekomstige realisaties ook geholpen zult zijn.

1 like
#9

Als het totaal teveel is, dan gebruik ik de COUNT om ze per behapbare set aan te vragen.

Alleen COUNT is daarvoor niet genoeg. Je zult response paging moeten gebruiken. Zie bijvoorbeeld: Ondersteuning voor response paging in BAG WFS