maandag 10 september 2018

Basisregistratie Grootschalige Topografie (revisited)

In maart 2016 is een proefje gedaan of de watergerelateerde lagen van de Basisregistratie Grootschalige Topografie (BGT) makkelijk in te lezen zijn in QGIS/PostgreSQL. Dat lukte redelijk. Nu maar eens kijken of het nog slimmer kan en wat een volgende stap kan zijn in het gebruik van de BGT in eigen processen en kernregistraties.


Op een downloadpagina van PDOK wordt  een BGT export via het selecteren van kaartvierkanten voorbereid en wordt een grote .zip met alle objecten gedownload. De .zip bevat voor ieder bgt- objecttype een .gml bestand. Het downloaden lukt de ene keer wat beter dan de andere keer, maar door de bank genomen werkt het wel. Het is voor mij (als burger) nog niet mogelijk om geclipte informatie (bijvoorbeeld per gemeente) of mutaties op te vragen.

 Voor de waterbeheerder zijn (als BGT afnemer) de volgende bgt-objecttypen van belang:
  • bgt_waterdeel
  • bgt_ondersteunendwaterdeel
  • bgt_kunstwerkdeel
  • bgt_waterinrichtingselement
  • bgt_sensor
De overige bgt-objecten zijn natuurlijk belangrijk als referentiedata.
De bgt-objecten uit bovenstaand lijstje zullen op één of andere manier in beheer genomen moeten worden omdat het de basis vormt voor de informatievoorziening van een waterbeheerder.

In 2016 is bgt_waterdeel nog in een aantal stappen met handwerk via QGIS in PostgreSQL geladen, waarbij de data door beperkingen van het tussentijds gebruikte SHAPE formaat ook nog eens is verminkt. Deze werkwijze is anno 2018 echt niet meer acceptabel (Shapefile must die !). Ditmaal wordt de GDAL library aangeroepen om in één stap een .gml bestand over te zetten naar PostgreSQL. Bijvoorbeeld voor bgt_waterdeel:

ogr2ogr -overwrite -nlt POLYGON -f PostgreSQL PG:"dbname='demo'
host='localhost' port='5432' active_schema=bgt user='****'
password="*****" bgt_waterdeel.gml

Deze stap is uitermate goed te automatiseren.
De datastructuur in de database (de tabel bgt.bgt_waterdeel) wordt automatisch aangemaakt en neemt 1:1 de .gml inhoud over. GDAL werk wat dat betreft ècht goed en is zeer robuust.
Veel simpeler kan het niet worden zou je denken.

Eigenlijk kan het wèl simpeler, de data zou ook geleverd kunnen worden in het opensource OGC GeoPackage formaat (.gpkg). Dat is in principe al een (SQLite) database, maar verpakt in een bestand. Deze bestanden zijn direct te openen in bijvoorbeeld QGIS. Dit .gpkg formaat is de beoogde opvolger van SHAPE. Als externe partij zou ik zeer geholpen zijn als waterbeheerders dit soort bestanden als open datasets beschikbaar stelt.

Maar goed, met GDAL werkt het ook. De PostgreSQL tabel bgt.bgt_waterdeel wordt aan een QGIS project toegevoegd, van een projectie (SRID = 28992) een een weergave stijl voorzien, en het kaartbeeld is compleet. Nu nog even de dataset clippen met het gebied van de waterbeheerder en de basis voor een kernregistratie-water ligt klaar.
Van GML bestand naar de presentatie in QGIS is pakweg een kwartiertje werk. Het ziet er dan bijvoorbeeld zo uit:


Dit is nu de BGT basis die de waterbeheerder volgens de wet vanaf 1/1/2016 moet gebruiken in haar werkprocessen.

Drie uitdagingen worden al snel duidelijk als je naar de data kijkt:
  • De bgt kent vele bronhouders en is continu aan verandering onderhevig. De waterbeheerder kan voor de initiële vulling en bijhouding van zijn registraties zich niet op een bewegend doel blijven richten, dus zal de bgt informatie op één of andere manier lokaal in beheer genomen moeten worden (incl. kwaliteitscontroles en mutatieprocessen).
  • Het aggregatieniveau van BGT (watergerelateerde) objecten is voor waterbeheerders te grof. Het kleinste stukje water in de eigen registratie moet ook homogeen zijn wat betreft typering op gebieden als waterkwantiteit, -kwaliteit en categorie (primair, secundair, tertiair). Dat resulteert in  kleinere stukjes water in de eigen registratie dan de bgt_waterdelen, De bgt-waterdelen moeten dus nog verder opgeknipt worden, waarbij de verwijzing naar het oorspronkelijke bgt-object nooit verloren mag gaan.
  • De BGT is inhoudelijk niet altijd juist. Er zitten systematische fouten in, maar ook toevallige fouten. Zie bijvoorbeeld bovenstaande afbeelding: geselecteerd object is zowel waterloop als watervlakte, en dat zijn toch echt verschillende (NEN 3610) watertypen. Dit object voldoet daarom niet aan de definitie van waterdeel en zou daarom opgedeeld moeten worden in kleinere waterdelen.
Nu is de waterbeheerder naast BGT afnemer ook vaak BGT bronhouder voor het thema water. Dat betekent dat de waterbeheerder zelf aan zet is om deze uitdagingen meteen bij de bron aan te pakken. De bronhouder mag vooralsnog naar eigen inzicht haar objecten extra opknippen, maak daar aub gebruik van. Dat scheelt later veel werk bij afnemers.

Maar naast de waterbeheerder er zijn ook nog veel watergerelateerde objecten afkomstig van andere bronhouders, en dan is er geen mogelijkheid objecten op te knippen.

Al met al wordt het nog een flinke puzzel om de BGT te integreren in eigen processen en registraties, maar het is zeker te doen, en het levert zeker baten op.

De volgende keer gaan we door met het object waterdeel.

Geen opmerkingen:

Een reactie posten