Via de website Publieke Dienstverlening Op de Kaart (PDOK) worden geodatasets beschikbaargesteld als .gml bestanden. Deze bevatten actuele en betrouwbare gegevens voor zowel de publieke als private sector. De meeste PDOK diensten zijn gebaseerd op open data en voor iedereen vrij beschikbaar.
In dit artikel de resultaten van een experiment waarin van PDKO afkomstige data bestanden zijn ingelezen in AutoCAD door gebruik te maken van de standaard programmeertaal VisualLISP.
In dit artikel de resultaten van een experiment waarin van PDKO afkomstige data bestanden zijn ingelezen in AutoCAD door gebruik te maken van de standaard programmeertaal VisualLISP.
In het Downloads ondeerdeel van de de PDOK website staat een kopje Basisregistratie Kadaster (BRK). Daarin zijn opgenomen de Bestuurlijke Grenzen en de Kadastrale kaart.
De Bestuurlijke Grenzen Actueel bevat een drietal vlakgerichte bestanden van gemeente, provincie en landgrens en wordt via een zip bestand beschikbaargesteld.
De Bestuurlijke Grenzen Actueel bevat een drietal vlakgerichte bestanden van gemeente, provincie en landgrens en wordt via een zip bestand beschikbaargesteld.
bestuurlijkegrenzen.zip (8Mb)
Het inlezen van gml bestanden is standaard niet mogelijk in AutoCAD. Wel kun je via al dan niet betaalde GIS-software exports maken naar bijvoorbeeld DXF. Een mooie en krachtige tool hiervoor is QGIS. Een vrij en open source geografisch informatiesysteem.
VisualLISP (AutoLISP)
Onze uitdaging is om binnen de standaard aanwezige programmeeromgeving Visual LISP een routine te schrijven waarmee de geografische data uit een gml ("Geographic Markup Language") bestand naar AutoCAD objecten om te zetten.
Het nadeel van LISP is dat het inlezen van grote dataset niet heel snel is. Het voordeel is dat met een paar programmeerregels alle punten uit het gml bestand automatisch worden verwerkt in polylijnen. Daarbij worden de polylijnen op aparte lagen gezet.
Wat de routine doet is regel voor regel lezen wat er in het gml bestand staat daarvoor wordt een zogenaamde (while functie gebruikt. Blijf net zolang lezen tot dat het einde van het bestand is bereikt. Per regel wordt gekeken om wat voor gml instructie het gaat. Met name de instructie "</gml:featureMember>" en "<gml:posList" zijn belangrijk omdat daaruit blijkt dat het om het volgende object gaat en in de posList de bijbehorende coördinaten staan. Door deze informatie te verwerken naar een entity-data list kan met de lisp functie (entmake een polylijn gemaakt worden.
Bij bijvoorbeeld gemeente grenzen kijkt de routine ook naar het veld <kad:Gemeentenaam> en gebruik de routine deze om daarvan een laagnaam te maken.
Het nadeel van LISP is dat het inlezen van grote dataset niet heel snel is. Het voordeel is dat met een paar programmeerregels alle punten uit het gml bestand automatisch worden verwerkt in polylijnen. Daarbij worden de polylijnen op aparte lagen gezet.
Wat de routine doet is regel voor regel lezen wat er in het gml bestand staat daarvoor wordt een zogenaamde (while functie gebruikt. Blijf net zolang lezen tot dat het einde van het bestand is bereikt. Per regel wordt gekeken om wat voor gml instructie het gaat. Met name de instructie "</gml:featureMember>" en "<gml:posList" zijn belangrijk omdat daaruit blijkt dat het om het volgende object gaat en in de posList de bijbehorende coördinaten staan. Door deze informatie te verwerken naar een entity-data list kan met de lisp functie (entmake een polylijn gemaakt worden.
Bij bijvoorbeeld gemeente grenzen kijkt de routine ook naar het veld <kad:Gemeentenaam> en gebruik de routine deze om daarvan een laagnaam te maken.
Resultaten
Het omzetten van Gemeentegrenzen.gml met een omvang van 16Mb duurde 6 minuten en leverde 420 polylijnen op verdeeld over 390 lagen. Totaal 741.495 coördinaten , dus een verwerking van meer dan 2000 punten per seconden.
Het inlezen van Landsgrens.gml (1Mb) duurde 8 minuten en leverde 31 polylijnen verdeeld over 1 laag. Totaal 37.522 coördinaten, een verwerking van slechts 78 punten per seconden. Blijkbaar heeft AutoCAD veel moeite met polylijnen waarin extreem veel punten zitten.
Het inlezen van provincie grenzen (3Mb) duurde 11 minuten waarbij 42 polylijnen over 12 lagen zijn gegenereerd. Totaal 140974 punten, of te wel ruim 200 punten per seconden.
Nader onderzoek naar de grote verschillen is gewenst.
Het omzetten van Gemeentegrenzen.gml met een omvang van 16Mb duurde 6 minuten en leverde 420 polylijnen op verdeeld over 390 lagen. Totaal 741.495 coördinaten , dus een verwerking van meer dan 2000 punten per seconden.
Het inlezen van Landsgrens.gml (1Mb) duurde 8 minuten en leverde 31 polylijnen verdeeld over 1 laag. Totaal 37.522 coördinaten, een verwerking van slechts 78 punten per seconden. Blijkbaar heeft AutoCAD veel moeite met polylijnen waarin extreem veel punten zitten.
Het inlezen van provincie grenzen (3Mb) duurde 11 minuten waarbij 42 polylijnen over 12 lagen zijn gegenereerd. Totaal 140974 punten, of te wel ruim 200 punten per seconden.
Nader onderzoek naar de grote verschillen is gewenst.
Conclusie
Als de opbouw van de dataset niet veranderd bij de volgende update, dan is het mogelijk met de LISP routine in 35 minuten de dataset om te zetten naar polylijnen op verschillende lagen. Daarmee is gml import in AutoCAD dus toch mogelijk.
Vervolg experiment
Nu het inlezen van de bestuurlijke grenzen is gelukt komt de uitdaging ook de kadastrale grenzen te kunnen inlezen. Wordt vervolgt.....
Vervolg experiment
Nu het inlezen van de bestuurlijke grenzen is gelukt komt de uitdaging ook de kadastrale grenzen te kunnen inlezen. Wordt vervolgt.....
Wil je zelf de bestuurlijke grenzen in kunnen lezen in AutoCAD, neem dan gerust contact met ons op.
Download
Wil de geproduceerde AutoCAD DWG's zelf gebruiken, dan kan dat door deze hieronder aan te vragen. Je ontvangt dan een e-mail met de download link naar:
- NL-Landsgrens
- NL_gemeentegrenzen
- NL_Provinciegrenzen
Mocht je vragen hebben over de gepubliceerde downloads - of over CAD in het algemeen – bel of mail dan even!
Ik wil graag het bestand ontvangen, mijn gegevens zijn:
Geen formulier, klik dan hier
Bron
Bron afkomstig van het Kadaster, via PDOK Loket www.pdok.nl
Bestuurlijke Grenzen 2016 (bestandsgrootte: ca. 8 MB)
Bestuurlijke Grenzen 2016 (bestandsgrootte: ca. 8 MB)
RSS-feed
