Inhoud

Inlezen BAG Extract en/of BAG-mutaties

Voor Opvragen BAG-gegevens via Stuf BG-vraagbericht zie: BAG bevraging via StUF BG vraagbericht.

In de kolom Import op het portaal Operations staan twee ingangen voor verwerken van BAG-gegevens per gemeente:

Waarschuwing

LET OP: dit zijn zeer geheugen intensieve processen. We raden aan deze alleen na reguliere werktijd uit te voeren.

De uitleg hieronder richt zich op de BAG-identifiers voor de verschillende objecten. De identifier zelf geeft al aan om wat voor soort object het gaat. Deze identificatiecode bestaat uit:

Import BAG-extract

OpenWave probeert rekening te houden met bestaande locatieadressen die niet voorzien zijn van BAG-identifcaties. Met de importroutine worden de woonplaatsen en straten en adressen - waar mogelijk - voorzien van BAG-identificatiecodes en worden nieuwe adressen aangemaakt.

In de tabel locaties (tbperceeladresen) ontstaan unieke adressen (op dnkeyopenbareruimte + huisnummer + huisletter + huisnummertoevoeging).

De BAG nummeraanduiding-identificatie in OpenWave kan maar op één adreskaart van tbperceeladressen worden toegevoegd. Een verblijfsobject (of standplaats of ligplaats) kan ook maar bij één nummeraanduiding dus één adreskaart worden toegevoegd. Dit verklaart voor een deel de mogelijke uitval in de operationslog. De BAG-registratie is zelf natuurlijk ook behept met anomalies (geldende nummeraanduidingen bij vervallen openbare ruimtes e.d.), die tot uitval kunnen leiden in de operationslog.

Structuur files

De inlogger dient een zipfile aan te wijzen op zijn of haar device met daarin het volledige BAG-extract van één gemeente. Een volledig uitgepakte zipfile (genest: de zipfile kan zelf ook weer zipfiles bevatten ) bestaat uit een of meer xml-files met daarin gegevens van de woonplaatsen, openbare ruimtes, nummeraanduidingen, verblijfsobjecten, panden, ligplaatsen en standplaatsen. Hieronder een voorbeeld voor gemeente-id 0385:

Het uitpakken (dat doet OpenWave dus) van de gemeentelijke zipfile: 0385GEM06052019-01052019.zip resulteert in:

Het uitpakken van deze zipfile resulteer in de xml's:

OpenWave verwerkt deze files in de volgorde wpL, opr, num, vbo, lig en sta (en daarbinnen op alfabetische volgorde). Pand-informatie wordt NIET opgenomen in OpenWave, behalve het pandidentificatienummer zelf (bij een verblijfsobject wordt deze code opgeslagen in tbperceeladressen.dvbagidentcode_2).

Om zeker te zijn dat het om een BAG-Extract gaat wordt elke xml-file gecontroleerd op de begintag. Deze moet de waarde BAG-Extract-Deelbestand-LVC hebben.

Verwerking

Als het verwerkingsproces (wordt gedaan met een runnable) start wordt:

Tijdens het verwerkingsproces wordt:

Voor wat betreft ingetrokken en vervallen objecten redeneert het programma als volgt:

Indien een BAG-object is beëindigd of de status is ingetrokken EN dat object bestaat nog niet in OpenWave dan wordt dat gegeven genegeerd.

Indien een BAG-object is beëindigd of status is ingetrokken EN dat object bestaat wel in OpenWave dan wordt de vervaldatum toegevoegd in OpenWave (tbperceeladressen, tbwoonplaatsen of tbopenbareruimte).

De inleesactie wordt uitgevoerd in een separaat proces zonder userinterface. De gebruiker kan met het ververs-icoontje linksonder op het lijstscherm van de operationslog toch de voortgang in beeld hebben, omdat dan de kolom verwerkt (aantal verwerkte items) bij die actie wordt ververst.

Indien klaar dan wordt:

In het operations logboek staat na een inleesactie in de memo het verslag.

Met name bij de kopjes inlezen verblijfsobjecten kunnen veel meldingen staan zoals bijvoorbeeld:

Verblijfsobjecten Inlezen 0106VBO15012021-000001.xml Nummeraanduiding-identifier 0106200000000084 bij Verblijfsobjectidentificatie 0106010000000084 onbekend in tbperceeladressen

Dat wil niet zeggen dat het algoritme zijn werk niet goed heeft gedaan.. In de aangeleverde BAG xml-file van verblijfsobjecten kan een verblijfsobject opgevoerd worden op een Nummeraanduiding die reeds is ingetrokken. OpenWave genereert dan bovenstaande foutmelding. Verderop in die xml-file is het waarschijnlijk dat ook het betreffende verblijfsobject wordt ingetrokken.

Woonplaatsen

OpenWave zoekt de woonplaatsidentificatie in tbwoonplaats op (dvidentificatiecode) bij de niet vervallen kaarten, die horen bij de gemeente die wordt ingelezen (tbwoonplaats.dvwoonplaatsid). Indien niet gevonden dat wordt op woonplaatsnaam gezocht.

Indien:

Waarschuwing

Er kan sprake zijn van een uitzonderlijke situatie dat dezelfde woonplaats voorkomt in twee gemeentes. Een voorbeeld is de woonplaats Oudkarsspel waarvan de straat Ambachtsdijk ligt in de gemeente Schagen en de overige straten in de gemeente Dijk en Waard. Dat levert de eerste keer problemen op met de verwerking van het BAG extract.
Is die situatie van toepassing dan moet de betreffende woonplaats VOORDAT het BAG extract wordt ingelezen al aanwezig zijn in OpenWave met de juiste BAG-identificatiecodes. Voor de situatie Oudkarspel betekent dit dat er twee kaarten moeten zijn in de tabel tb33gemeente, namelijk Schagen met dvgemeentecode = 0441 en Dijk en Waard met dvgemeentecode = 1980. Voorts moeten een kaart bestaan in tbwoonplaats met dvidenticatiecode = '3290' en dvwoonplaatsid = 0441 en woonplaatsnaam = Oudkarspel. Zo ook een kaart in tbwoonplaats met dvidenticatiecode = '1119' en dvwoonplaatsid = 1980 en woonplaatsnaam = Oudkarspel.

Openbare Ruimtes

OpenWave zoekt de OpenbareRuimte-identificatie in tbopenbareRuimte op (dvopruimteid) bij de niet vervallen kaarten, die gekoppeld zijn aan tbwoonplaats met de woonplaatsidentifier (tbwoonplaats.dvidentificatiecode). Indien niet gevonden dat wordt op straatnaam gezocht.

Indien:

Nummeraanduiding

OpenWave zoekt de Nummeraanduiding-identificatie in tbperceeladressen op (dvbagidentcode_3) bij de niet vervallen kaarten, die gekoppeld zijn aan tbopenbareruimte met de openbare ruimte-identifier (tbopenbareruimte.dvopruimteid). Indien niet gevonden dat wordt respectievelijk ook nog in dvbagidentcode_2 en dvidentifiercode gezocht. Nog niet gevonden dan wordt op huisnummer, huisletter en huisnummertoevoeging gezocht.

Indien:

Verblijfsobject of ligplaats of standplaats

OpenWave zoekt de Nummeraanduiding-identificatie op in tbperceeladressen op (dvbagidentcode_3) bij de niet vervallen kaarten.

Indien:

Import BAG-mutaties

Voor het geautomatiseerd verwerken 0- via de scheduler - van maandelijkse BAG-mutaties per gemeente: zie Automatisch inlezen BAG- mutaties

Dit kan alleen maar gedaan worden wanneer ooit een volledig BAG-Extract is ingelezen. Vanaf die tijd zou het inlezen van Mutaties voldoende moeten zijn.

OpenWave gaat er namelijk vanuit dat:

Structuur files

De inlogger dient een zipfile aan te wijzen op zijn of haar device met daarin de BAG-mutaties van één gemeente. Een uitgepakte zipfile bestaat uit een of meer xml-files met daarin mutaties op openbare ruimtes, nummeraanduidingen, verblijfsobjecten, panden, ligplaatsen en standplaatsen.

Hieronder een voorbeeld voor gemeente-id 1740:

Het uitpakken (dat doet OpenWave dus) van de gemeentelijke zipfile: 1740MUT15092020-15102020.zip resulteert in:

OpenWave verwerkt deze files in alfabetische volgorde. Pand-informatie wordt NIET opgenomen in OpenWave, behalve het pandidentificatienummer zelf (bij een verblijfsobject wordt deze code opgeslagen in tbperceeladressen.dvbagidentcode_2).

Om zeker te zijn dat het om een BAG-Mutaties gaat wordt elke xml-file gecontroleerd op de begintag. Deze moet de waarde BAG-Mutaties-Deelbestand-LVC hebben.

Verwerking

Als het verwerkingsproces (wordt gedaan met een runnable) start wordt:

Tijdens het verwerkingsproces wordt:

Indien klaar dan wordt:

Mutaties BAG-objecten

Een xml-file wordt verwerkt in een LOOP. Per product-tag wordt in de xml aangegeven of het om een wijziging gaat of om een nieuw object en om welkt type het gaat. OpenWave redeneert als volgt.

Wijzigen

Nieuw

Rapport

Er is een rapportage gemaakt om in te zien welke locaties gewijzigd, c.q. nieuw aangemaakt zijn:

Deze ziet er als volgt uit: 

select c.dvwoonplaatsnaam,b.dvopruimtenaam,a.dvhuisnummer, a.dvhuisnummertoevoeging,a.dvhuisletter,a.dvpostcode,
  a.dvidentificatiecode,a.ddcontrolebag
  from tbperceeladressen a
  inner join TbOpenbareRuimte b
  on(a.dnkeyopenbruimte=b.dnkey)
  inner join tbwoonplaats c
  on(b.dnkeywoonplaats=c.dnkey)
  where a.ddcontrolebag is not null and %where%
  order by 1,2,3,4
en bij SQL2: a.ddcontrolebag = %datum% .

Bij het starten van de rapportage, vult de gebruiker de datum in waarop de BAG mutatie is ingelezen. Het veld ddcontrolebag wordt immers met deze datum gevuld.

Versie 2.0

Vanaf oktober 2021 wordt alleen nog maar versie 2.0 uitgeleverd door de BAG. Zowel van de volledige BAG als de BAG mutaties.

De werking is identiek als hierboven beschreven. Alleen in de Configuratie is een nieuwe instelling noodzakelijk:

Sectie: Operations en Item: Inlezenbag waarbij Getal2 krijgt waarde 2.

Getal2 geeft aan welke versie. 2.0 = versie 2.1.0, in alle andere gevallen versie 1.4.