digitaldutch/bag_parser

Turns Dutch addresses database (BAG or Basisregistratie Adressen en Gebouwen) into a user friendly SQLite database.

bag_parser's Issues

Store rijksdriehoekscoördinaten when parsing BAG

Currently only WGS 84 coordinates are stored when parsing BAG. These values contain a small error. Add the original RD coordinates in the SQLite database for those who need them.

Make fields that may contain multiple values plural

Adressen: gebruiksdoel
pand_id

verblijfsobjecten:
pand_id
nevenadressen is al meervoud

Parse nevenadres info

Voeg verblijfsobject nevenadres info toe aan adressen tabel toe

Het binnenhof 1a is een mooi voorbeeld van verblijfsobject met veel nevenadressen.

Handleiding BAG: Hoe adresseer ik objecten die aan meerdere openbare ruimten liggen?

Date imports

Option to import dates:
Nummer ID, pand:

• Begin geldigheid, eind geldigheid, Documentdatum

Implement high accuracy RD > WGS84 conversion

Currently the conversion to WGS84 coordinates is done using approximation equations.

We should use the more accurate conversions instead.

Options:
PROJ using PyProj
GDAL

Improved support for geo spatial data

WoonplaatsRef wordt niet uitgelezen uit nummeraanduiding

Sommige nummeraanduidingen hebben een gerelateerdewoonplaats veld wat de woonplaats van de openbare ruimte overruled. Dit komt omdat een weg door twee woonplaatsen kan lopen.

De Kalfjeslaan 1 - 1181BN ligt in Amstelveen (1050) en niet Amsterdam (3594)

https://bagviewer.kadaster.nl/lvbag/bag-viewer/index.html#?searchQuery=0362010002079586&objectId=0362010002079586&geometry.x=118931.093&geometry.y=481660.716&zoomlevel=6&detailsObjectId=0362010002079586

Option to for cleaner DB setup

Verblijfsobjecten has several fields that can contain multiple values that are separated by commas.

• pand_id
• nevenadressen
• gebruiksdoel

This is bad database design and leads to unexpected results in queries with joins.

Standplaatsen inlezen

Standplaatsen tabel bevat de coördinaten. Deze worden nu nog niet ingelezen.

Complete population of gebruiksdoel field

Currently the 'gebruiksdoel' field (purpose of the address) contains just one purpose, for example 'woonfunctie'. But for many addresses there are multiple purposes. For example for zipcode 5109 RK with house number 8, this address has purpose 'Woonfunctie' and 'Industriefunctie'.

See https://bagviewer.kadaster.nl/lvbag/bag-viewer/?searchQuery=5109RK&objectId=0766200000003982&theme=BRT%20Achtergrond&geometry.x=124555.95000000001&geometry.y=407896.92000000004&zoomlevel=15

Another example, zipcode 9145 CG with house number 2 has these purposes: Bijeenkomstfunctie, Gezondheidszorgfunctie, Industriefunctie, Kantoorfunctie, Logiesfunctie, Sportfunctie, Winkelfunctie, Overige gebruiksfunctie.
See https://bagviewer.kadaster.nl/lvbag/bag-viewer/?searchQuery=9145CG&objectId=0058200000245128&theme=BRT%20Achtergrond&geometry.x=193663.91700000002&geometry.y=599703.0519999999&zoomlevel=14.849100227337871

Parse all BAG fields

Some fields that are more administrative are currently not parsed. Add an option to parse all BAG fields.

*.cvs output genereren

Allow output as a single *.cvs file

Speed things up

Speed things up by using multi threading of processes for unzipping and XML parsing. Running the parser now takes 35 minutes in a single thread.

Add coordinate system choice for geometries

The geometries are now store in approximated WGS84. There should be an option to store them in the original RD coordinate system.

Option to read geometries

Geometries are not read yet. Make it an option in config.py.

Remove database fields which are not parsed

Option to select coordinate system for parsed geometry data