bag 2.0
This is an adaptation of the old inspireadressen.zip import. The newest data is now only available in BAG 2.0 format.
The download is now called : lvbag-extract-nl.zip.
installation
nlextract
The nlextract has a bagv2 subdirectory so an attempt might be in order.
First put the passwords from postgres in the config file.
[DEFAULT]
database = bag
schema = test
host = localhost
user = bag
password = bag
port = 5432
This command might gives some more warnings, so possibly do this as well :
stetl
Stetl is software to Extract Transform and Load geographic data.
- ETL : Extract Transform Load
- GDal : Graphic Data Abstraction Layer
- OGR : OpenGis (simple features) Reference implementation
Stetl is used for extracting the bagv2 data see : https://www.stetl.org/en/latest/
debian buster -> bookworm
NOTE : it states multiple times that you need gdal 3.4 or higher so the code below might give you a working stetl, but it still won't convert correctly ! SO ... forget buster, reinstall servert1 with bookworm !!
This chapter was started for buster, but ended upas bookworm. Maybe do a reinstall someday and cleanup all buster references.
An older installation like on servert1 should be installed a bit different. If you just try to pip3 install stetl it will try to compile gdal 3.6.3 and that fails.
First install gdal and libgdal-dev. Then find the gdal version number.
sudo apt-get install gdal-bin libgdal-dev
gdal-config --version
2.4.0
# so now install that version
sudo pip3 install GDAL==2.4.0
sudo pip3 install stetl
I don't know if this is needed, but i also changed the default version of python to python3. If you get in trouble with the previous steps. Here is how you switch:
update-alternatives --install /usr/bin/python python /usr/bin/python3 2
update-alternatives --install /usr/bin/python python /usr/bin/python2 1
python --version
Python 3.7.3
postal code databases
Note that Just vandenbroecke is the expert on this field, and in this slide show
(warning: advertisements) visit
He mentions :
- Dutch National Datasets
- Germany : AFIS-ALKIS-ATKIS
- Uk: OS Mastermap
Investigate these, they might be zipcode databases for two very important countries.
Foss Free and Open Source Software.
Foss is mentioned as a suboptimal solution in the slideshow. I even never heard of that. As open source these tools are mentioned :
- xslt
- GDAL
- PostGIS
- ogr2ogr
Actually stetl is supposed to be an umbrella app for the tools above.
https://gdal.org/drivers/vector/lvbag.html
bullseye generation instruction
Once the bullseye installation is done run make build-bag from the makefile. It will start running but you have no way to follow what happens.
The console will advance from time to time, but to see what's happening use this query.
SELECT
table_name,
pg_size_pretty(total_size) AS total_size
FROM (
SELECT
table_name,
pg_total_relation_size(table_name) AS total_size
FROM (
SELECT ('"' || table_schema || '"."' || table_name || '"') AS table_name
FROM information_schema.tables
) AS all_tables
ORDER BY total_size DESC
) AS pretty_sizes
Now this will produce very long list, with some table that are not very interesting. So to shorten it for test.only :
SELECT
table_name,
pg_size_pretty(total_size) AS total_size
FROM (
SELECT
table_name,
pg_total_relation_size(table_name) AS total_size
FROM (
SELECT ('"' || table_schema || '"."' || table_name || '"') AS table_name
FROM information_schema.tables
WHERE table_schema='test'
) AS all_tables
ORDER BY total_size DESC
) AS pretty_sizes
Producing
table_name | total_size
----------------------------------------+------------
"test"."verblijfsobject" | 5415 MB
"test"."nummeraanduiding" | 2289 MB
"test"."gemeente_woonplaats" | 736 kB
"test"."provincie_gemeente" | 128 kB
"test"."nlx_bag_info" | 16 kB
"test"."ligplaats" | 16 kB
"test"."woonplaats" | 16 kB
"test"."adresseerbaarobjectnevenadres" | 16 kB
"test"."nlx_bag_log" | 16 kB
"test"."standplaats" | 16 kB
"test"."openbareruimte" | 8192 bytes
"test"."verblijfsobjectpand" | 8192 bytes
"test"."verblijfsobjectgebruiksdoel" | 8192 bytes
(13 rows)
Then repeat to see what tables are growing with \g
Note that stetl will first print what zip files it extracts and than an ogr command tries to put it into the database.
2023-06-20 11:05:59,346 fileextractor INFO Extracting /vsizip/{lzip}/9999LIG08062023.zip
2023-06-20 11:05:59,362 fileextractor INFO Extracted /vsizip/{lvip}/9999LIG08062023.zip ok len=1582924 bytes
2023-06-20 11:05:59,407 archiveexpander INFO Expanded temp/baggetemp_dir OK - filecount=2
2023-06-20 11:05:59,407 execoutput INFO executing cmd=ogr2ogr -fdbname=bagimport host=localhost port=5432 user=*** password=*** st" -lco LAUNDER=YES -lco PRECISION=NO -lco FID=gid -lco SPATIALend --config PG_USE_COPY YES -a_srs EPSG:28992 -gt 200000 -oo AID_DATA=NO -oo LEGACY_ID=YES temp/temp_dir
During the ogr2ogr commands some tables will grow. Be sure that no errors happen and that all indices are built !!
During the create indices phase, it will be so busy that the query above won't work. So be patient there.
Sadly it seems that the last steps are
And the first steps already freezes postgres, here is an attempt to time these steps :
11:25:52,103 fileinput INFO Read/parse for start for file=sql/finalize-tables.sql....
12:23:42,500 fileinput INFO Read/parse for start for file=sql/fill-reltables.sql....
12:28:22,877 fileinput INFO Read/parse for start for file=sql/create-views.sql....
12:28:22,934 fileinput INFO Read/parse for start for file=sql/create-indexes.sql....
12:40:51,198 chain INFO DONE -
- So almost an hour for finalizing tables.
- 5 minutes for fill-reltables
- create views instantly
- 12 minutes for indices
docker way
The command is :
docker run --name nlextract --rm -v $(pwd)/work:/work nlextract/nlextract:latest bagv2/etl/etl.sh -a bag_input_file=/work/bag.zip
host.docker.internal is a shortcut for Windows and Mac for reaching the hypervisor from a docker container. But it does not work for linux.
Since the script presume it works, we can make a host entry for that. This address allegedly would do the same thing from any docker container.
``` title = "/etc/hosts" 127.17.0.1 host.docker.internal
No !! that does not weem to work !. So it won't be able to connect to the database. It might be possible to rebuild the docker image with 127.17.0.1 hardcoded into the builder. But this will defeat the purpose of docker anyway.
## postgres database
The database has to be prepared for the import to work.
``` bash title="recreate database" linenums="1"
# of course : change the password to something else
sudo su -c "psql -c \"CREATE ROLE bag LOGIN PASSWORD 'bag'\"" postgres
sudo su -c "createdb --owner bag -E UTF8 bagimport" postgres
# sudo apt-get install postgis if needed
sudo su -c 'psql -d bagimport -c "create extension postgis"' postgres
sudo su -c 'psql -d bagimport -c "create extension postgis_topology"' postgres
For postgis extensions, see their site, and follow the workshop
GDAL Tools like ogr2ogr can be used to reformat standard formats (like shape .shp format) into postgis, and so we can search with SQL in the data for instance the BAG>
A very nice way to visualize the data in postgres is QGIS !!
sudo apt-get install qgis
qgis # start the gui
# go to POSTGIS, connect to your database and browse your objects
Note that the public schema does not contain much data.
bagimport=> \dt
List of relations
Schema | Name | Type | Owner
--------+-----------------+-------+----------
public | spatial_ref_sys | table | postgres
(1 row)
bagimport=> \dn
List of schemas
Name | Owner
----------+----------
public | postgres
test | bag
topology | postgres
(3 rows)
Use the tab to show more tables (or set the search_path)
bagimport=> select count(*) from test. <TAB><TAB>
test.adresseerbaarobjectnevenadres
test.adresseerbaarobjectnevenadresactueel
test.adresseerbaarobjectnevenadresactueelbestaand
test.adresseerbaarobjectnevenadres_gid_seq
test.extract_datum
test.gemeente_woonplaats
test.gemeente_woonplaatsactueelbestaand
test.gemeente_woonplaats_gid_seq
test.gt_pk_metadata
test.ligplaats
test.ligplaatsactueel
test.ligplaatsactueelbestaand
test.ligplaats_gid_seq
test.nlx_bag_info
test.nlx_bag_info_gid_seq
test.nlx_bag_log
test.nlx_bag_log_gid_seq
test.nummeraanduiding
test.nummeraanduidingactueel
test.nummeraanduidingactueelbestaand
test.nummeraanduiding_gid_seq
test.openbareruimte
test.openbareruimteactueel
--More--
indices
The final query used in location.cpp has a number of joins, let's see where the slowest part is.
SELECT postcode,huisnummer,huisnummertoevoeging,opr.openbareruimtenaam,wpl.woonplaatsnaam,ST_X(geopunt),ST_Y(geopunt) FROM test.nummeraanduiding as nr LEFT JOIN test.verblijfsobject AS vbo ON nr.identificatie = vbo.hoofdadres LEFT JOIN test.openbareruimte AS opr ON nr.gerelateerdeopenbareruimte = opr.identificatie LEFT JOIN test.woonplaats AS wpl ON wpl.identificatie=opr.gerelateerdewoonplaats,ST_Distance(ST_geomFromText('POINT(119261 393155)',28992),geopunt) as dist ORDER BY geopunt <-> ST_geomFromText('POINT(119261 393155)',28992) ASC LIMIT 1
But first :
fix does not exist error
First this throws an error in the latest installation on hoek.
So the expression 'POINT(119261 393155)' seems to yield 'unknown' as type.
SELECT ST_geomFromText('POINT(119261 393155)',28992);
ERROR: function st_geomfromtext(unknown, integer) does not exist
LINE 1: select ST_geomFromText('POINT(119261 393155)',28992);
^
HINT: No function matches the given name and argument types. You might need to add explicit type casts.
Note that this al has to do with the schema for which postgis extension was installed. Show the extensions :
\dx;
Name | Version | Schema | Description
------------------+---------+------------+------------------------------------------------------------
plpgsql | 1.0 | pg_catalog | PL/pgSQL procedural language
postgis | 3.3.2 | public | PostGIS geometry and geography spatial types and functions
postgis_topology | 3.3.2 | topology | PostGIS topology spatial types and functions
uuid-ossp | 1.1 | public | generate universally unique identifiers (UUIDs)
(4 rows)
So it seems postgis was installed in schema 'public'. Now try this :
SELECT "public".ST_GeomFromText('POINT(-71.064544 42.28787)');
st_geomfromtext
--------------------------------------------
0101000000CB49287D21C451C0F0BF95ECD8244540
(1 row)
So we need to prepend the schema OR set the searchpath for the command to work.
continued indexes
So now again the query to locate an address from a point :
set search_path=public;
SELECT postcode,huisnummer,huisnummertoevoeging,opr.openbareruimtenaam,wpl.woonplaatsnaam,ST_X(geopunt),ST_Y(geopunt) FROM test.nummeraanduiding as nr LEFT JOIN test.verblijfsobject AS vbo ON nr.identificatie = vbo.hoofdadres LEFT JOIN test.openbareruimte AS opr ON nr.gerelateerdeopenbareruimte = opr.identificatie LEFT JOIN test.woonplaats AS wpl ON wpl.identificatie=opr.gerelateerdewoonplaats,ST_Distance(ST_geomFromText('POINT(119261 393155)',28992),geopunt) as dist ORDER BY geopunt <-> ST_geomFromText('POINT(119261 393155)',28992) ASC LIMIT 1
This complete query takes 12 seconds.
Explained :
We want postcode,huisnummer,toevoeging,woonplaats from x/y.
First we need to find a verblijfsobject, because that has the geopunt as a column.
select identificatie,geopunt,hoofdadres,ST_Distance(ST_geomFromText('POINT(119261 393155)',28992),geopunt) as dist from "test".verblijfsobject ORDER BY geopunt <-> ST_geomFromText('POINT(119261 393155)',28992) ASC LIMIT 10;
Verblijfsobject :
| identificatie | geopunt | hoofdadres | dist |
|---|---|---|---|
| 1723010000002591 | 01010000204071000000000000E018FD400000000000FB1741 | 1723200000002591 | 270.78035379251577 |
| 1723010000002591 | 01010000204071000000000000E018FD400000000000FB1741 | 1723200000002591 | 270.78035379251577 |
| 1723010000002591 | 01010000204071000000000000E018FD400000000000FB1741 | 1723200000002591 | 270.78035379251577 |
| 1723010000004049 | 010100002040710000000000007030FD4000000000E8FF1741 | 1723200000004049 | 303.03300150313663 |
| 1723010000004049 | 010100002040710000000000007030FD4000000000E8FF1741 | 1723200000004049 | 303.03300150313663 |
| 1723010000004049 | 010100002040710000000000007030FD4000000000E8FF1741 | 1723200000004049 | 303.03300150313663 |
| 1723010000002588 | 010100002040710000000000002015FD40000000003CFA1741 | 1723200000002588 | 337.91271062213684 |
| 1723010000002588 | 010100002040710000000000002015FD40000000003CFA1741 | 1723200000002588 | 337.91271062213684 |
| 1723010000002583 | 01010000204071000000000000E019FD400000000094F81741 | 1723200000002583 | 418.7660444687463 |
| 1723010000002583 | 01010000204071000000000000E019FD400000000094F81741 | 1723200000002583 | 418.7660444687463 |
This is rather fast, the first 10 addresses that have the shortest distance to the given coordinate. So the 12 seconds does not come from this part.
select postcode from test.nummeraanduiding as nr left join test.verblijfsobject as vbo ON nr.identificatie = vbo.hoofdadres limit 10;
This is already a 12 second query, so we should be able to speed this up, or don't use a join. Note that using an INNER JOIN does the trick.
- LEFT JOIN: returns all rows from the left table, even if there are no matches in the right table.
- INNER JOIN: returns rows when there is a match in both tables.
(see here ) [https://masterdaweb.com/en/blog/difference-between-inner-join-left-join-right-join-and-full-outer-join]
select postcode from test.nummeraanduiding as nr INNER join test.verblijfsobject as vbo ON nr.identificatie = vbo.hoofdadres limit 10;
This returns almost immediately.
However we still have a slow query with this one even if we do use INNER joins.
SELECT openbareruimtenaam,wpl.woonplaatsnaam,ST_X(geopunt),ST_Y(geopunt) FROM test.nummeraanduiding as nr INNER JOIN test.verblijfsobject AS vbo ON nr.identificatie = vbo.hoofdadres INNER JOIN test.openbareruimte AS opr ON nr.gerelateerdeopenbareruimte = opr.identificatie INNER JOIN test.woonplaats AS wpl ON wpl.identificatie=opr.gerelateerdewoonplaats WHERE postcode='3151AW' AND huisnummer=248
It's 3 seconds, but still too slow in my opinion. Let's hunt down the slowest parts.
Direct result, so this is not the problem. After eliminating woonplaats and openbareruimte, this query takes the longest :
So would indexing it fix our problem :
Now this is a lot quicker and indeed the complete query and also our tests in aivrp/solver/worker/test/test.
geo search
Since the geo search was not the problem, the indices needed are probably already installed, this next part can be read when that query is also slow !!
The mayor part is the geosearch , we can try that with
The indices installed are
Schema | Name | Type | Owner | Table
--------+------------------------------------+-------+-------+-------------------------------
test | adresseerbaarobjectnevenadres_pkey | index | bag | adresseerbaarobjectnevenadres
test | gemeente_woonplaats_pkey | index | bag | gemeente_woonplaats
test | gt_pk_metadata_table_schema_key | index | bag | gt_pk_metadata
test | ligplaats_pkey | index | bag | ligplaats
test | nummeraanduiding_pkey | index | bag | nummeraanduiding
test | openbareruimte_pkey | index | bag | openbareruimte
test | pand_pkey | index | bag | pand
test | provincie_gemeente_pkey | index | bag | provincie_gemeente
test | standplaats_pkey | index | bag | standplaats
test | verblijfsobject_pkey | index | bag | verblijfsobject
test | verblijfsobjectgebruiksdoel_pkey | index | bag | verblijfsobjectgebruiksdoel
test | verblijfsobjectpand_pkey | index | bag | verblijfsobjectpand
test | woonplaats_pkey | index | bag | woonplaats
(13 rows)
There is not a specific geospatial index there, so this next query is not very fast :
SELECT ST_X(geopunt),ST_Y(geopunt),ST_Distance(ST_geomFromText('POINT(119261 393155)',28992),geopunt) as dist FROM test.verblijfsobject ORDER BY geopunt <-> ST_geomFromText('POINT(119261 393155)',28992) ASC LIMIT 10;
This already takes 6 seconds, with 10 results. Limit 1 does not speed it up by the way.
st_x | st_y | dist
------------+-----------+--------------------
119182 | 392896 | 270.78035379251577
119182 | 392896 | 270.78035379251577
119559 | 393210 | 303.03300150313663
119559 | 393210 | 303.03300150313663
119559 | 393210 | 303.03300150313663
119122 | 392847 | 337.91271062213684
119122 | 392847 | 337.91271062213684
119198 | 392741 | 418.7660444687463
119198 | 392741 | 418.7660444687463
119244.916 | 392706.15 | 449.1380829499756
(10 rows)
This index added speeds up things a LOT :
Some installations might still say vob_xy, but that was a typo.
BUT : only this query and NOT the original one :
Find the nummeraanduiding with that identificatie, we need the openbareruimte first.
SELECT nr.postcode,vbo.identificatie,hoofdadres,ST_X(geopunt),ST_Y(geopunt),ST_Distance(ST_geomFromText('POINT(119261 393155)',28992),geopunt) as dist FROM test.verblijfsobject as vbo LEFT JOIN test.nummeraanduiding as nr ON nr.identificatie=hoofdadres ORDER BY geopunt <-> ST_geomFromText('POINT(119261 393155)',28992) ASC LIMIT 10;
new schema
Almost everything was rearranged, but names are still recognizable. In the chapters below all tables and columnames have been printed. But here i will attempt to map our queries onto the new format.
Get the x,y coordinates of a zipcode + number.
The old query :
sql << "SELECT openbareruimtenaam,woonplaatsnaam,ST_X(geopunt),";
sql << "ST_Y(geopunt)";
sql << " FROM test.adres WHERE ";
sql << "postcode='" << this->zip() << "'";
sql << " AND huisnummer=" << this->num();
sql << andwhere.str();
But adress is no longer a table, if yo look for postcode, it is only in the nummeraanduiding table. In the list below we need gerelateerdewoonplaats and gerelateerdeopenbareruimte, and we need x/y coordinates.
The only geopunt references to be found is in adresseerbaarobjectnevenadres and verblijfsobject. geovlak are in ligplaats, pand, and standplaats. It is very probably that we now need geovlak references.
First step is to get the woonplaats and
SELECT identificatie,gerelateerdewoonplaats,gerelateerdeopenbareruimte FROM nummeraanduiding WHERE postcode='3151AW' AND huisnummer='248';
identificatie | gerelateerdewoonplaats | gerelateerdeopenbareruimte
------------------+------------------------+----------------------------
0599200000414862 | | 0599300000003060
We have 2 id's
- 0599300000003060 obviously an openbareruimte (prins hendrikstraat)
- 0599200000414862 this is 'hoofdadress in the 'verblijfsobject' table
Do NOT set searchpath, since it will disable postgis.
\c bag;
SELECT postgis_full_version();
set search_path=test;
SELECT postgis_full_version();
ERROR: function postgis_full_version() does not exist
So you need to stay in the public scheme, and use wildcards to get the tables
\dt test.*;
List of relations
Schema | Name | Type | Owner
--------+-------------------------------+-------+----------
test | adresseerbaarobjectnevenadres | table | postgres
test | gemeente_woonplaats | table | postgres
test | gt_pk_metadata | table | postgres
test | ligplaats | table | postgres
test | nlx_bag_info | table | postgres
test | nlx_bag_log | table | postgres
test | nummeraanduiding | table | postgres
test | openbareruimte | table | postgres
test | pand | table | postgres
test | provincie_gemeente | table | postgres
test | standplaats | table | postgres
test | verblijfsobject | table | postgres
test | verblijfsobjectgebruiksdoel | table | postgres
test | verblijfsobjectpand | table | postgres
test | woonplaats | table | postgres
(15 rows)
select openbareruimtenaam,wpl.woonplaatsnaam,ST_X(geopunt),STY(geopunt) from test.nummeraanduiding as nr left join test.verblijfsobject as vbo on nr.identificatie = vbo.hoofdadres left join test.openbareruimte as opr on nr.gerelateerdeopenbareruimte = opr.identificatie left join test.woonplaats as wpl on wpl.identificatie=opr.gerelateerdewoonplaats where postcode='3151AW' AND huisnummer=248;
We need openbareruimtenaam,woonplaatsnaam,X and Y:
select openbareruimtenaam,woonplaatsnaam from nummeraanduiding as nr left join verblijfsobject as vbo on nr.identificatie = vbo.hoofdadres left join openbareruimte as opr on nr.gerelateerdeopenbareruimte = opr.identificatie where postcode='3151AW' AND huisnummer=248;
It actually yields two entries :
gid | gebruiksdoelverblijfsobject | oppervlakteverblijfsobject | hoofdadres | nevenadressen | gerelateerdepanden | identificatie | verblijfsobjectstatus | geconstateerd | documentdatum | documentnummer | voorkomenidentificatie | begindatumtijdvakgeldigheid | einddatumtijdvakgeldigheid | tijdstipregistratie | eindregistratie | tijdstipinactief | tijdstipregistratielv | tijdstipeindregistratielv | tijdstipinactieflv | tijdstipnietbaglv | geopunt | aanduidingrecordinactief
----------+-----------------------------+----------------------------+------------------+---------------+--------------------+------------------+----------------------------+---------------+---------------+------------------+------------------------+-----------------------------+----------------------------+----------------------------+----------------------------+------------------+----------------------------+----------------------------+--------------------+-------------------+----------------------------------------------------+--------------------------
16834555 | {woonfunctie} | 80 | 0599200000414862 | | {0599100000180840} | 0599010000180840 | Verblijfsobject in gebruik | f | 1975-01-01 | Pandkaart 736817 | 1 | 1984-01-17 00:00:00+01 | 2021-02-05 00:00:00+01 | 2010-08-28 03:30:32+02 | 2021-02-05 10:33:52.431+01 | | 2010-08-28 04:00:27.616+02 | 2021-02-05 13:24:29.874+01 | | | 01010000204071000033333333AFC4F040C3F5285C1F181B41 | f
16834556 | {woonfunctie} | 101 | 0599200000414862 | | {0599100000180840} | 0599010000180840 | Verblijfsobject in gebruik | f | 2021-02-05 | BAGWOZOPP_SYNC5 | 2 | 2021-02-05 00:00:00+01 | | 2021-02-05 10:33:52.431+01 | | | 2021-02-05 13:24:29.874+01 | | | | 01010000204071000033333333AFC4F040C3F5285C1F181B41 | f
Means the postgis extensions can't be found.
Since only some details differ it is probably een mutation or something. geopunt is the same so take the last entry if needed.
Woonplaats stays empty, so it will probably have to come from openbareruimte as well.
We need identificatie, not gid to get the adress.
gid | identificatie | openbareruimtenaam | verkorteopenbareruimtenaam | openbareruimtetype | gerelateerdewoonplaats | openbareruimtestatus | geconstateerd | documentdatum | documentnummer | voorkomenidentificatie | begindatumtijdvakgeldigheid | einddatumtijdvakgeldigheid | tijdstipregistratie | eindregistratie | tijdstipinactief | tijdstipregistratielv | tijdstipeindregistratielv | tijdstipinactieflv | tijdstipnietbaglv | aanduidingrecordinactief
--------+------------------+---------------------+----------------------------+--------------------+------------------------+-----------------------+---------------+---------------+-------------------+------------------------+-----------------------------+----------------------------+------------------------+-----------------+------------------+----------------------------+---------------------------+--------------------+-------------------+--------------------------
280071 | 0599300000003060 | Prins Hendrikstraat | | Weg | 3082 | Naamgeving uitgegeven | f | 1974-07-01 | Gem.blad 1974/361 | 1 | 1983-01-02 00:00:00+01 | | 2010-08-27 16:34:44+02 | | | 2010-08-27 17:01:20.396+02 | | | | f
(1 row)
Gerelateerdewoonplaats is now 3082.
This does indeed give hoek van holland.
3130 | 3082 | Hoek van Holland | Woonplaats aangewezen | f | 2010-02-18 | Corsa nr. 10/532 | 1 | 2010-02-18 00:00:00+01 | | 2010-08-27 16:32:18+02 | | | 2010-08-27 17:01:11.419+02 | | | |
- gid
- huisnummer
- huisletter
- huisnummertoevoeging
- postcode
- typeadresseerbaarobject
- gerelateerdeopenbareruimte
- gerelateerdewoonplaats
- identificatie
- nummeraanduidingstatus
- geconstateerd
- documentdatum
- documentnummer
- voorkomenidentificatie
- begindatumtijdvakgeldigheid
- einddatumtijdvakgeldigheid
- tijdstipregistratie
- eindregistratie
- tijdstipinactief
- tijdstipregistratielv
- tijdstipeindregistratielv
- tijdstipinactieflv
- tijdstipnietbaglv
- aanduidingrecordinactief
adresseerbaarobjectnevenadres
gid | identificatie | nevenadres | hoofdadres | typeadresseerbaarobject | ligplaatsstatus | standplaatsstatus | verblijfsobjectstatus | geconstateerd | documentdatum | documentnummer | voorkomenidentificatie | begindatumtijdvakgeldigheid | einddatumtijdvakgeldigheid | tijdstipregistratie | eindregistratie | tijdstipinactief | tijdstipregistratielv | tijdstipeindregistratielv | tijdstipinactieflv | tijdstipnietbaglv | geopunt | aanduidingrecordinactief
gemeentewoonplaats
gid | begindatumtijdvakgeldigheid | einddatumtijdvakgeldigheid | woonplaatscode | gemeentecode | status
gt_pk_metadata
ligplaats
gid | identificatie | hoofdadres | nevenadressen | ligplaatsstatus | geconstateerd | documentdatum | documentnummer | voorkomenidentificatie | begindatumtijdvakgeldigheid | einddatumtijdvakgeldigheid | tijdstipregistratie | eindregistratie | tijdstipinactief | tijdstipregistratielv | tijdstipeindregistratielv | tijdstipinactieflv | tijdstipnietbaglv | geovlak | aanduidingrecordinactief
nlx_bag_info
nlx_bag_log
nummeraanduiding (adres)
gid | huisnummer | huisletter | huisnummertoevoeging | postcode | typeadresseerbaarobject | gerelateerdeopenbareruimte | gerelateerdewoonplaats | identificatie | nummeraanduidingstatus | geconstateerd | documentdatum | documentnummer | voorkomenidentificatie | begindatumtijdvakgeldigheid | einddatumtijdvakgeldigheid | tijdstipregistratie | eindregistratie | tijdstipinactief | tijdstipregistratielv | tijdstipeindregistratielv | tijdstipinactieflv | tijdstipnietbaglv | aanduidingrecordinactief
openbareruimte (stad)
gid | identificatie | openbareruimtenaam | verkorteopenbareruimtenaam | openbareruimtetype | gerelateerdewoonplaats | openbareruimtestatus | geconstateerd | documentdatum | documentnummer | voorkomenidentificatie | begindatumtijdvakgeldigheid | einddatumtijdvakgeldigheid | tijdstipregistratie | eindregistratie | tijdstipinactief | tijdstipregistratielv | tijdstipeindregistratielv | tijdstipinactieflv | tijdstipnietbaglv | aanduidingrecordinactief
pand
gid | bouwjaar | identificatie | pandstatus | geconstateerd | documentdatum | documentnummer | voorkomenidentificatie | begindatumtijdvakgeldigheid | einddatumtijdvakgeldigheid | tijdstipregistratie | eindregistratie | tijdstipinactief | tijdstipregistratielv | tijdstipeindregistratielv | tijdstipinactieflv | tijdstipnietbaglv | geovlak | aanduidingrecordinactief | geom_valid
provincie_gemeente
standplaats
gid | identificatie | hoofdadres | nevenadressen | standplaatsstatus | geconstateerd | documentdatum | documentnummer | voorkomenidentificatie | begindatumtijdvakgeldigheid | einddatumtijdvakgeldigheid | tijdstipregistratie | eindregistratie | tijdstipinactief | tijdstipregistratielv | tijdstipeindregistratielv | tijdstipinactieflv | tijdstipnietbaglv | geovlak | aanduidingrecordinactief
verblijfsobject
gid | gebruiksdoelverblijfsobject | oppervlakteverblijfsobject | hoofdadres | nevenadressen | gerelateerdepanden | identificatie | verblijfsobjectstatus | geconstateerd | documentdatum | documentnummer | voorkomenidentificatie | begindatumtijdvakgeldigheid | einddatumtijdvakgeldigheid | tijdstipregistratie | eindregistratie | tijdstipinactief | tijdstipregistratielv | tijdstipeindregistratielv | tijdstipinactieflv | tijdstipnietbaglv | geopunt | aanduidingrecordinactief
verblijfsobjectgebruiksdoel
gid | identificatie | aanduidingrecordinactief | tijdstipinactief | voorkomenidentificatie | begindatumtijdvakgeldigheid | einddatumtijdvakgeldigheid | verblijfsobjectstatus | gebruiksdoelverblijfsobject
verblijfsobjectpand
gid | identificatie | aanduidingrecordinactief | tijdstipinactief | voorkomenidentificatie | begindatumtijdvakgeldigheid | einddatumtijdvakgeldigheid | verblijfsobjectstatus | gerelateerdpand
woonplaats
gid | identificatie | woonplaatsnaam | woonplaatsstatus | geconstateerd | documentdatum | documentnummer | voorkomenidentificatie | begindatumtijdvakgeldigheid | einddatumtijdvakgeldigheid | tijdstipregistratie | eindregistratie | tijdstipinactief | tijdstipregistratielv | tijdstipeindregistratielv | tijdstipinactieflv | tijdstipnietbaglv |