Alternatieve BAG Python parser

[janderk]

Aangezien ik de NLextract te ingewikkeld vond, heb ik al jaren mijn eigen Python BAG parser om de BAG om te zetten in een gebruiksvriendelijke, file base, SQLite database. Voor geïnteresseerden staat deze nu als open source op github.

Er zijn geen dependencies, je hoeft ook geen database te installeren. Parsen is 1 Python commando die ongeveer 1 uur draait. Daarna kan de data geëxporteerd worden naar b.v. een *.csv bestand. Dat duurt 30 tot 75 seconden.

Op dit moment is de data die uitgelezen wordt veel beperkter dan b.v. NLextract. Alleen adressen, bouwjaar, coördinaten, vloeroppervlakte en gebruiksdoel.

De BAG in SQLite en csv formaat zijn ook beschikbaar voor directe download in the releases sectie.

Als er iemand meer wil weten dan hoor ik het wel.

[raymondnijssen]

Leuk project, simpel en kennelijk snel! Maar wel belangrijk om hier op het geoforum op te merken dat er geen geometrie wordt meegenomen.

[remvee]

Oh, interessant! Zelf heb ik ook iets geknutseld:

~jomco/straatnaam - BAG Extract data postcode opzoek dingen - sourcehut git

Steekwoorden: Clojure, PostgreSQL API en een beetje PostGIS.

Hier ook weinig geometrie in meegenomen, alleen om lat/lon uit te rekenen voor objecten en middelpunt van lig- en standplaatsen.

[janderk]

Maar wel belangrijk om hier op het geoforum op te merken dat er geen geometrie wordt meegenomen.

Daar had ik al een issue van gemaakt op github. Is nog niet geïmplementeerd, omdat ik het zelf nooit nodig had. Alleen de eerste coördinaat wordt uitgelezen voor de lengte- en breedtegraad. Zal kijken of ik het binnenkort als optie kan toevoegen. Nevenadressen gebeurt ook nog niets mee.

[raymondnijssen]

Ja ik zag het. Ik vond deze tekst ook wel grappig:
“It also does not include municipalities or provinces and provides coordinates using an obscure system named Rijksdriehoekscoördinaten”

Hier zijn vast mensen die je hiermee kunnen helpen!

[janderk]

De laatste versie heeft nu een parse_geometries optie in congif.py.

De data wordt opgeslagen als geojson polygon in een geometry veld. Vraag aan de experts: is geojson handig of is een ander formaat beter?

Parsing duurt dan 2 uur ipv 1.

[janderk]

@raymondnijssen

“It also does not include municipalities or provinces and provides coordinates using an obscure system named Rijksdriehoekscoördinaten”

Hier zijn vast mensen die je hiermee kunnen helpen!

De parser converteert alle coordinaten al van Rijksdriehoekscoördinaten naar WGS 84.

[geotiles]

Op die ‘conversie’ is wel meer dan een beetje af te dingen. Een variatie is al eens eerder opgedoken. In dat licht is dit topic interessant. De oplossing is m.i. eenvoudig: naast de benadering ook de bron opslaan, zodat de gebruiker kan kiezen.

[raymondnijssen]

Mooi dat het is toegevoegd!

Twee kolommen, bijvoorbeeld rd_x en rd_y, zouden ook heel handig zijn. Ik denk dat veel mensen graag “obscure” RD-coordinaten gebruiken. Of eventueel een echte Point kolom met spatialite geometrieen. Maar dan heb je waarschijnlijk weer een dependency om je script te draaien.

[janderk]

@geotiles

Op die ‘conversie’ is wel meer dan een beetje af te dingen. Een variatie is al eens eerder opgedoken. In dat licht is dit topic interessant. De oplossing is m.i. eenvoudig: naast de benadering ook de bron opslaan, zodat de gebruiker kan kiezen.

Wow. Goed dat ik dit open source maak. Leer er veel van. Dat is zeker een reden om de originele RD coördinaten er ook bij doen. Misschien maar eens een echte conversie als optie toe te voegen. Die PHP versie is wel om te zetten naar Python.

[janderk]

@raymondnijssen

Twee kolommen, bijvoorbeeld rd_x en rd_y, zouden ook heel handig zijn. Ik denk dat veel mensen graag “obscure” RD-coordinaten gebruiken.

Staat op mijn lijstje.

@raymondnijssen

Of eventueel een echte Point kolom met spatialite geometrieen. Maar dan heb je waarschijnlijk weer een dependency om je script te draaien.

Klopt, mijn doel is in eerste instantie om geen dependencies te hebben voor het parsen van de originele BAG. De SQLite database kan dan gebruikt worden om andere databases te vullen of om csv te genereren. Zat al wel te kijken naar SpatiaLite. Zou het als optie kunnen toevoegen zodat mensen Spatial SQL kunnen gebruiken. SQLite is best gebruiksvriendelijk en snel als je met data aan het stoeien bent.

[Jochem]

@janderk

Die PHP versie is wel om te zetten naar Python.

Voor het onderhoud van de code op de lange termijn lijkt het me handiger om PYPROJ te gebruiken dan om zelf python-code op basis van de PHP-code te maken. Sowieso adviseert de NSGI om niet in iedere programmeertaal een eigen RDNAPTRANS-implementatie te maken maar om energie te steken in het maken van een interface met PROJ-bibliotheek vanuit de gewenste programmeertaal. Dat is niet alleen handiger voor onderhoud (o.a. bigfixes), maar geeft je meteen ook de mogelijkheid om vrijwel elke andere coördinaattransformatie uit te voeren.

“It also does not include municipalities or provinces and provides coordinates using an obscure system named Rijksdriehoekscoördinaten”

De transformatie van en naar RD is sinds RDNAPTRANS™2018 gewoon gestandaardiseerd opgenomen in EPSG.org, dus dat is niet uitzonderlijker dan de honderden andere nationale coördinatensystemen van de meeste andere landen ter wereld.

[janderk]

Ik was me niet bewust van thet PyProj. Dank. Ik heb in eerste instantie maar de onnauwkeurigheid van de conversie opgenomen in de readme als limitatie.

Het paper van de benaderingsformules heeft het over sub decimeter afwijking, maar lees hier dat je meer aan een meter moet denken bij RD > WGS84. Klopt dat?

[Jochem]

Het paper vermeldt een standaardafwijking van 9 cm en een maximale afwijking van 25 cm. Deze waarden gelden alleen op land binnen de rijksgrens. Bovendien verplaatst Europa met 2.4 cm/jaar in WGS84. Voor de meeste toepassingen zijn tijdsafhankelijke coördinaten erg onpraktisch. Daarom is het advies (Handreiking CRS van Geonovum) voor dergelijke toepassingen om het in Europa afgesproken referentietijdstip 1989 te gebruiken door WGS84 gelijk te stellen aan ETRS89. De coëfficiënten van de reeksontwikkeling zijn berekend voor 2001. Daardoor is de fout altijd groter dan 0.2 meter voor ETRS89 (zie hieronder) en voor actuele tijdsafhankelijke WGS84-coördinaten is de fout inmiddels zelfs nog groter.

Fout in transformatie van RD naar WGS84 met de reeksontwikkeling van Schreutelkamp en Strang van Hees in vergelijking met RDNAPTRANS™2018 en nultransformatie van ETRS89 naar WGS84.

• 1.2 meter binnen de rechthoek ruim om Nederland (50-56°NB, 2-8°OL)
• 0.9 meter binnen de Nederlandse EEZ van de Noordzee
• 0.5 meter op land binnen de Nederlandse rijksgrens

 
De transformatie de andere kant op gaat iets beter op zee.

Fout in transformatie van WGS84 naar RD met de reeksontwikkeling van Schreutelkamp en Strang van Hees in vergelijking met nultransformatie van WGS84 naar ETRS89 en RDNAPTRANS™2018.

• 0.5 meter binnen de rechthoek ruim om Nederland (50-56°NB, 2-8°OL)
• 0.5 meter binnen de Nederlandse EEZ van de Noordzee
• 0.5 meter op land binnen de Nederlandse rijksgrens

[janderk]

Er is een nieuwe versie die ook rd_x en rd_y exporteert. En nevenadressen worden nu ook uitgelezen. Deze worden in een aparte tijdelijke nevenadressen tabel opgeslagen. In de adressen tabel is nu een hoofd_nummer_id veld. Een adres is een nevenadres indien dit gevuld is.

[janderk]

Nog een update. De BAG parser gebruikt nu multi-processing waardoor de BAG in 10 minuten wordt omgezet ipv 35 op een AMD 7700X. Verder is er ook een nieuwe optie om historische data in te lezen.