DKK percelen: overzicht van mogelijkheden

Datasets BRK
#1

Hallo,

Is er een overzicht van de verschillende mogelijke bronnen en bestandsformaten en kenmerken en voor- en nadelen hiervan voor de kadastrale percelen?

In mijn zoektocht naar percelen als feature met oppervlakte en polygoon kwam ik o.a. het volgende tegen:

  1. Kadastrale kaart WFS => qua data precies wat ik wil maar ik stuit op een limiet van 10.000 omdat ik met de startindex in de url selecteer (“It is not possible to use a ‘startindex’ higher then 10.000. When you need to scrape the WFS I kindly refer you to the extracts available for this dataset.”).

  2. Via de Digitale Kadastrale Kaart valt dkk-gml-nl-nohist.zip te downloaden. Deze bevat 4 gml bestanden, het perceel bestand bevat volgens mij alleen Point en geen Polygoon geometrieën. Ik zie diverse forum vragen hierover met de opmerking dat zowel Point als Polygonen in de gml zitten maar ik kan hierin echt alleen Points vinden => via Python zie ik deze properties:

{'properties': OrderedDict([('gml_id', 'str'), ('namespace', 'str:25'), ('lokaalID', 'int'), ('beginGeldigheid', 'str:23'), ('tijdstipRegistratie', 'str:23'), ('volgnummer', 'int'), ('code', 'str:1'), ('waarde', 'str:6'), ('kadastraleAanduiding|TypeKadastraleAanduiding|kadastraleGemeente|KadastraleGemeente|code', 'int'), ('kadastraleAanduiding|TypeKadastraleAanduiding|kadastraleGemeente|KadastraleGemeente|waarde', 'str:11'), ('sectie', 'str:1'), ('perceelnummer', 'int'), ('kadastraleAanduiding|TypeKadastraleAanduiding|aKRKadastraleGemeenteCode|AKRKadastraleGemeenteCode|code', 'int'), ('kadastraleAanduiding|TypeKadastraleAanduiding|aKRKadastraleGemeenteCode|AKRKadastraleGemeenteCode|waarde', 'str:5'), ('kadastraleGrootte|TypeOppervlak|waarde', 'float'), ('kadastraleGrootte|TypeOppervlak|soortGrootte|SoortGrootte|code', 'int'), ('kadastraleGrootte|TypeOppervlak|soortGrootte|SoortGrootte|waarde', 'str:57'), ('perceelnummerRotatie', 'float'), ('deltaX', 'float'), ('deltaY', 'float')]), 'geometry': 'Point'}

  1. Via PDOK kon ik Kadastrale Percelen (INSPIRE geharmoniseerd) downloaden. Dit geeft cadastralparcels.gml en hierin zitten alle perceel polygonen.

  2. De PDOK download API.

Wanneer kan ik het beste wat gebruiken? Wat zijn de voor en nadelen?

Ik probeer alles eerst zelf uit te zoeken en ben heel bij met alles wat er is alleen: dit is allemaal vrij nieuw voor me en ik zie af en toe “door de bomen het bos niet meer”.

Zeker omdat ik bijvoorbeeld voor BAG panden wel via WFS per 1000 rijen zonder limiet van 10.000 op de startindex alle pand polygonen kon binnenhalen en omdat voor bijvoorbeeld de adressen (ATOM) deze downloadlink blijkbaar nog weer anders werkt (hij ziet er hetzelfde uit als de download knop bij percelen maar die doet het wel en deze niet, ik weet nog niet hoe en dat is ook niet primair mijn vraag, het is meer dat er blijkbaar zo veel verschillende manieren zijn en dat ik de meta beschrijving zoek).

Hartelijk bedankt voor enige hulp hierbij alvast! Wouter

#2

@wouter-openinfo geen volledig antwoord want hangt van je “use-case” af. Als je een landelijke dataset wilt zul je een van de downloads (jouw optie 2 of 3) moeten gebruiken. Met de download API (4) kun je wat meer filtering doen maar ook weer hele set (optie 2) downloaden. Optie 2 is m.i. “beter” dan optie 3, omdat deze rijker is, de INSPIRE set is meer een grootste gemene deler formaat tussen EU landen.

Echter is de GML-set van optie 2 lastig te verwerken zonder gespecialiseerde software. Daarvoor is er bijv NLExtract Open Source die “BRK-DKK” (dus dkk-gml-nl-nohist.zip) kan verwerken tot een PostGIS bestand, zonder de Point geometrieën. Die zijn nl niet relevant, zijn “plaatsbepalingspunten” van inmeten. Wil je niet zelf NLExtract installeren/draaien kun je bij geotoko.nl kant-en-klare BRK-DKK PostGIS dumps betrekken.

#3

Hallo Just, dank je wel, Ik vind de “hap klare brokken” van geotoko zeker fijn en ben ook van plan die te (blijven) gebruiken. Zeker met de BAG en alle extra afgeleide woningattributen. Voor sommige data en een beter begrip is het echter ook fijn om de services zelf te gebruiken. En dat vind ik nog lastig zoals je ziet.

Ik snap bijvoorbeeld niet waarom percelen bv wel een limiet op de WFS heeft en panden niet. Hier zijn misschien goede redenen voor waar ik benieuwd naar ben. Of waarom de ene download idd percelen met polygonen en de andere met x en y bevat. Ik dacht nog, misschien zijn de x en y om de nummeraanduiding mooi op een kaart te tonen? De centroid van de polygoon is daar immers niet altijd geschikt voor. Ik ben op zoek naar dit soort extra achtergrond informatie. En naar wat voorbeelden zoals hoe je de data voor heel NL eventueel toch via de WFS service kan downloaden door op een “pseudo-paginated manier met bounding boxes” toch heel NL bij elkaar te verzamelen.

Ik vind NL extract ook een mooi initiatief alleen de PostGIS db trekt mij niet zo. Ik ben bekend met de Python tooling en die maakt het allemaal super eenvoudig, ik maak van een WFS URL rechtstreeks datasets in het geheugen en heb prima performance met de data voor heel NL in een Jupyter notebook op mijn laptop.

Mvg, Wouter

#4

Je stelt een hoop vragen die ik mijzelf ook al jarenlang stel. Al die verschillen tussen de verschillende services maken het lastig om dingen op te halen op een gestandaardiseerde manier. En wat mij ook telkens weer opvalt: je download iets dat als GML word aangemerkt. Gebruik je een applicatie die met standaard GML overweg kan, dan verlies je de helft van de informatioe die wel aanwezig zou moeten zijn. Zelfde met de huidige CityJSON bestanden: als je die met standaard software out of the box probeert te lezen, dan krijg je niks bruikbaars binnen. Knap irritant zo langzamerhand, als ik eerlijk ben. Maar goed, ik dwaal enigszins af.

Je vermoeden is correct. En ik vermoed dat je software gebruikt die maar 1 geometrie per feature aankan, en dan voor het plaatsingspunt kiest in plaats van de polygoon. Daar ben ik zelf ook al wel eens tegenaan gelopen. Het is redelijk ouderwets dat iets als een plaatsingspunt nog steeds geleverd word in mijn optiek, maar ik zie met enige regelmaat dat software soms niet overweg kan met het feit dat een object 2 geometrien heeft, dus een keuze maakt voor de ene geometrie, en dat is dan net degene waar je eigenlijk niet in geinteresserd bent.

Maar ja, elke keer dat je verschillende services wilt combineren, ben je eerst uren aan het uitvogelen wat precies de details zijn van welke service en hoe je daar mee om moet gaan, en welke standaard je op welke manier wel of juist niet moet toepassen. Voorbeeldje: BAG Extract 2.0 zou GML moeten zijn. Als ik de standaard GML Reader van FME gebruik om dat te lezen, krijg ik nog geen tuinschuurtje te zien. Als ik de veel bredere XML Reader gebruik en zoek op Object:Pand (of zoiets, weet niet exact meer uit m’n hoofd wat het was), en er daarna een GeometryReplacer op zet (en dan wel voor GML kies), dan krijg ik alles binnen. Dan vraag ik mij af hoe goed de GML-standaard word toegepast… en met CityJson vanuit PDOK is het een vergelijkbaar verhaal, en er zijn veel meer van dat soort struikelblokken. Een limiet op de een en op de andere niet is er ook zo eentje helaas.

#5

@wouter-openinfo de services als WFS en APIs zijn niet bedoeld om heel Nederland “binnen te halen”. Natuurlijk, je kan met “rechthoeken” (bbox-queries) heel NL scannen en binnenhalen. Maar dat is bijna oneigenlijk gebruik, dat vooral veel (PDOK) resources kost en de performance van andere gebruikers beïnvloedt.

Tja, als je niet aan de PostGIS wil wordt het een lastig verhaal. Dan wordt het ad-hoc. Zoals ook @sbjager zegt, is de samenhang tussen de basisregistraties niet optimaal zachtst gezegd. BAG is geen GML (maar XML), BRK weer wel en BGT is CityGML ! Daar loopt ook een traject voor: “DiS” (?) waarbij “iS” staat voor “In Samenhang”. Maar is langere termijn. Met PostGIS (via NLExtract) kun je juist wel een samenhang tussen basisregistraties bereiken. Programmatisch bijv in Python loop je snel tegen limieten aan, zeker met bijv een BGT landelijke set in geheugen…

Nu gaat de volgende Grote Geo Show toevallig over Databases m.n. PostGIS: “Databases de Baas”.
Do 6 mei 19:00-20:00.
Voor mij was de stap ooit naar PostGIS het moment dat ik “echt GIS” kon doen.

1 like
#6

Bedankt voor jullie reacties. Heel goed om te weten allemaal. Op zich fijn dat het niet alleen aan mijn onervarenheid ligt. En met respect voor PDOK, de samenhang kan in mijn eigen werk soms ook beter en dat is in een veel eenvoudigere omgeving :slight_smile: En inderdaad, misschien moet ik wel met PostGIS gaan werken, ik weet nu niet wat ik mis. Ik ga er verder mee aan de slag! Mvg, Wouter

#7

Heel informatieve discussie.
Ik werk wel met postgis, maar gdal/ogrinfo/ogr2ogr ziet de oz: tags helemaal niet en dus is begrenzingPerceel (polygon) voor mij alleen zichtbaar in een file-utility (25 gb is wat groot voor een tekst editor). Ik snap dat dit oplosbaar is via NL-extract; voor zover ik weet moet ik die onder Linux gebruiken (toch?) en uiteindelijk gaat me dat wel lukken. Maar een ogr driver LVBRK naast LVBAG zou voor mij nog prettiger zijn. Is die heel misschien in de maak/te verwachten?

Met nog enige toelichting: Bezig met een project om oude risicokaart terreingrenzen te verbeteren mbv percelen. Eerst de inspire geprobeerd, met als probleem dat smalle stroken soms mee gepakt werden bij inrichtinggrenzen. Dit was niet te fine-tunen met omtrek/oppervlak of andere “slimme” trucs.
Daarom is de hoop dat de volledige download meer data heeft, en of wellicht typeoppervlak (meen ik) selectie waarde heeft t.a.v. al dan niet openbare ruimte gebruik, zodat (openbare) wegen/paden etc. uitsluitbaar zijn. Ik besef dat dit een far shot is, dus ook hier is advies nodig en gewaardeerd.
vriendelijke groet, Jan

PS hier de ogrinfo

ogrinfo -so dkk_perceel.gml perceel
INFO: Open of `dkk_perceel.gml'
      using driver `GML' successful.

Layer name: Perceel
Geometry: Point
Feature Count: 8229579
Extent: (4682.778000, 306890.510000) - (277999.857000, 634993.382000)
Layer SRS WKT:
(unknown)
gml_id: String (0.0) NOT NULL
namespace: String (25.0)
lokaalID: Integer64 (0.0)
beginGeldigheid: String (23.0)
tijdstipRegistratie: String (23.0)
volgnummer: Integer (0.0)
code: String (1.0)
waarde: String (6.0)
kadastraleAanduiding|TypeKadastraleAanduiding|kadastraleGemeente|KadastraleGemeente|code: Integer (0.0)
kadastraleAanduiding|TypeKadastraleAanduiding|kadastraleGemeente|KadastraleGemeente|waarde: String (30.0)
sectie: String (2.0)
perceelnummer: Integer (0.0)
kadastraleAanduiding|TypeKadastraleAanduiding|aKRKadastraleGemeenteCode|AKRKadastraleGemeenteCode|code: Integer (0.0)
kadastraleAanduiding|TypeKadastraleAanduiding|aKRKadastraleGemeenteCode|AKRKadastraleGemeenteCode|waarde: String (5.0)
kadastraleGrootte|TypeOppervlak|waarde: Real (0.0)
kadastraleGrootte|TypeOppervlak|soortGrootte|SoortGrootte|code: Integer (0.0)
kadastraleGrootte|TypeOppervlak|soortGrootte|SoortGrootte|waarde: String (68.0)
perceelnummerRotatie: Real (0.0)
deltaX: Real (0.0)
deltaY: Real (0.0)
#8

Ja, rare truc, maar ik antwoord mezelf hier. Ben aan het inlezen in de NL-extract en vind (hulde) ook voor BRK windows ondersteuning. Dus ik kan weer even vooruit en kom vast wel weer buurten als ik ergens niet uitkom.

#9

Mijn voornaamste behoefte aan extra informatie in de percelen is de vraag of zij al dan niet deel uitmaken van een openbareruimte. Dat lukt in principe door uit cadastralparcels de percelen waarbinnen zich een openbareruimtelabel bevindt te selecteren.
Dit lukt nu nog maar deels, en dat heeft als reden dat in de dataset via WFS er per openbareruimte dikwijls meer dan 1 label is; maar in de gml download is er slechts 1 label per openbareruimte.
De WFS heeft een extra kolom ID die ontbreekt in de GML download. Als kleine illustratie: zie de lichtgroene punten WFS niet gemaskeerd door rode punten GML voor het Lissabonerf in onderstaand plaatje. Is de volledige openbareruimtelabel dataset beschikbaar, of kan die beschikbaar gemaakt worden?

image
image571×656 32.1 KB

#10

Jammer genoeg nog geen reactie gelezen. Moet ik hier een nieuw item van maken?

#11

Soms slaan mensen niet aan op een bepaalde topic titel. Als je vraag is: “Is de Openbareruimtelabel volledig beschikbaar”, dan lijkt het me idd beter als je daar een nieuw topic voor aanmaakt.

#12

Ik zou er inderdaad een nieuw topic van maken.

En nu wat meer inhoudelijk:

Je realiseert je hopelijk dat een openbare ruimte label een kartografisch element is? En dat dat dus ergens geplaatst word, zodat het mooi uitkomt? En dat je dus erg voorzichtig moet zijn om daar conclusies aan te verbinden?

Wat is je achterliggende vraag hier? Want naast het kartografische element van de labels, zijn er ook Openbare Ruimtes vastgelegd in de BAG, die helemaal niet openbaar toegankelijk zijn. Dus wat zoek je precies als je zegt:

#13

Sorry voor de afwezigheid, zag geen meldingen van nieuwe posts.
Wat ik zoek is een manier om percelen die behoren tot een openbare ruimte te onderscheiden van de overige percelen. De reden is dat ik probeer om (voor externe veiligheid) in oude registraties geschetste terreingrenzen te herleiden tot perceelgrenzen. Deze terreinen zijn begrenzingen van de betreffende gevaarlijke activiteit. Het is zeldzaam of zelfs uitgesloten dat daar een ‘openbaar perceel’ bij hoort.
Via de WFS viel mij op dat de kartografische elementen heel vaak goed geplaatst zijn voor dit doel.
Alleen is een flink deel van de elementen in de WFS niet aanwezig in de atom feed, zoals eerder gemeld.
De plaatsing is niet 100% voor dit doel (soms op een scheidingslijn, bijv.), maar dat is niet persé nodig, omdat er nabewerking mogelijk is. Ik ben ook gaan werken met de BGT, maar het lijkt of het vooral moeilijker wordt en bovengenoemde benadering de beste ‘bang for the buck’ geeft.
Ik houd me aanbevolen voor andere opties, natuurlijk!