Inlezen BAG Extract en/of BAG-mutaties [Documentatie]

Deze pagina is alleen-lezen. Je kan de broncode bekijken maar niet veranderen. Neem contact op met de beheerder als je denkt dat dit niet klopt.
====== Inlezen BAG Extract en/of BAG-mutaties ======

Voor Opvragen BAG-gegevens via Stuf BG-vraagbericht zie: [[openwave:1.34:applicatiebeheer:probleemoplossing:programmablokken:bag_bevraging]]. 

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

<adm warning>
Dit zijn zeer geheugen intensieve processen. 
We raden aan deze alleen na reguliere werktijd uit te voeren.
</adm>

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:
  * de viercijferige gemeentecode volgens GBA tabel 33, 
  * gevolgd door een tweecijferige objecttypering: 
    * 01 - verblijfsobject 
    * 02 - ligplaats 
    * 03 - standplaats 
    * 10 - pand
    * 20 - nummeraanduiding
    * 30 - openbare ruimte 
  * en een voor de registrerende gemeente 10-cijferig uniek volgnummer (met voorloopnullen). 


===== 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:
  * 0385WPL06052019-01052019.zip  
  * 0385OPR06052019-01052019.zip
  * 0385NUM06052019-01052019.zip
  * 0385PND06052019-01052019.zip
  * 0385VBO06052019-01052019.zip
  * 0385LIG06052019-01052019.zip
  * 0385STA06052019-01052019.zip

Het uitpakken van deze zipfile resulteer in de xml's:
  * 0385WPL06052019-01052019-000001.xml   (woonplaatsen)
  * 0385OPR06052019-01052019-000001.xml   (openbare ruimtes)
  * 0385NUM06052019-01052019-000001.xml   (nummeraanduidingen)
  * 0385NUM06052019-01052019-000002.xml    
  * 0385PND06052019-01052019-000001.xml   (panden)
  * 0385PND06052019-01052019-000002.xml
  * 0385VBO06052019-01052019-000001.xml   (verblijfsobjecten)
  * 0385VBO06052019-01052019-000002.xml
  * 0385LIG06052019-01052019-000001.xml   (ligplaatsen)
  * 0385STA06052019-01052019-000001.xml   (standplaatsen)

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: 
  * een regel aangemaakt in de tabel tboperationslog (ook in portaal //Operations//) met codering **BAG-Extract** en het moment van starten
  * wordt de //Datum// van de instelling //Sectie: Operations// //Item: InlezenBAG// gevuld met timestamp. De kolom //Tekst// met medewerkerscode en //Getal1// met 1. Hiermee wordt voorkomen dat een tweede persoon ook een importproces BAG start.

Tijdens het verwerkingsproces wordt:
  * de kolom **Aantalverwerkt** van de tabel tboperationslog om de 100 items ververst
  * worden in de kolom **log** per ingelezen xml-file de gelukte en mislukte aantallen geschreven (met oorzaak).

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: 
  * de einddatum/tijd op de tboperationslog-kaart gezet
  * de status op de tboperationslog-kaart gevuld met 'Klaar'
  * //Getal1// van de instelling //Sectie: Operations// //Item: InlezenBAG// weer op 0 gezet: de tegel wordt hiermee weer vrijgegeven.

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: 
  * een unieke kaart gevonden dan wordt deze gewijzigd
  * geen kaart gevonden dan wordt een insert gedaan
  * anders een foutmelding in de kolom tboperationslog.dvlog.

<adm warning>
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.
</adm>

==== 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: 
  * een unieke kaart gevonden dan wordt deze gewijzigd
  * geen kaart gevonden dan wordt een insert gedaan
  * anders een foutmelding in de kolom tboperationslog.dvlog.

==== 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: 
  * een unieke kaart gevonden dan wordt deze gewijzigd met dvbagidentcode_3 = nummeraanduiding-identificatie
  * geen kaart gevonden dan wordt een insert gedaan
  * anders een foutmelding in de kolom tboperationslog.dvlog.

==== Verblijfsobject of ligplaats of standplaats ====

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

Indien: 
  * een unieke kaart gevonden dan wordt deze gewijzigd met dvidentificatiecode = verblijfsobject-, c.q. ligplaats-, c.q. standplaatsidentifier. Bij verblijfsobject wordt de pandidentificatie in kolom dvbagidentcode_2 gezet
  * geen kaart gevonden dan een foutmelding in de kolom tboperationslog.dvlog
  * anders een foutmelding in de kolom tboperationslog.dvlog.


===== Import BAG-mutaties =====

Voor het geautomatiseerd verwerken 0- via de scheduler - van maandelijkse BAG-mutaties per gemeente: zie [[openwave:1.34:applicatiebeheer:probleemoplossing:programmablokken: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:
  * in de tabel tbopenbareruimte voor de "BAG-straten" de kolom dvopruimteid gevuld is met de Openbare ruimte-identifier
  * in de tabel tbperceeladressen de kolom:
    * dvidentificatiecode gevuld is met een verblijfsobject-identifier (of met een ligplaats- of standplaatsidentifier). De kolom kan ook leeg zijn als de locatie geen BAG-adres is
    * dvbagidentcode_2 gevuld kan zijn met een pand-identifier (dat is het geval wanneer dvidentificatiecode een verblijfsobject betreft)
    * dvbagidentcode_3 gevuld kan zijn met een nummeraanduiding-identifier. Dat is sowieso het geval wanneer dvidentificatiecode een gevulde waarde heeft, maar kan leeg zijn indien de locatie geen BAG-adres is.

==== 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:
  * 1740MUT15092020-15102020-000001.xml
  * 1740MUT15092020-15102020-000002.xml


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: 
  * een regel aangemaakt in de tabel tboperationslog (ook in portaal Operations) met codering **BAG-Mutatie** en het moment van starten
  * wordt de //Datum// van de instelling //Sectie: InlezenBAG// //Item: benbezig// gevuld met timestamp. De kolom //Tekst//  met medewerkerscode en //Getal1// met 1. Hiermee wordt voorkomen dat een tweede persoon ook een importproces BAG start.

Tijdens het verwerkingsproces wordt:
  * de kolom **Aantalverwerkt** van de tabel tboperationslog om de 100 items ververst
  * worden in de kolom log per ingelezen xml-file de gelukte en mislukte aantallen geschreven (met oorzaak).

Indien klaar dan wordt: 
  * de einddatum/tijd op de tboperationslog-kaart gezet
  * de status op de tboperationslog-kaart gevuld met 'Klaar'
  * //Getal1// van de instelling //Sectie: InlezenBAG// //Item: benbezig// weer op 0 gezet: de tegel wordt hiermee weer vrijgegeven.

==== 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**
  * Openbare ruimte: zoek woonplaatsidentifier in tbwoonplaats (dvidentificatiecode).
    * Indien gevonden zoek openbare ruimte identifier in tbopenbareruimte (dvopruimteid) bij woonplaats: 
      * indien Gevonden: Wijzig openbare ruimte-kaart
      * niet gevonden: foutmelding in tboperationslog.
    * Niet gevonden: foutmelding in tboperationslog.
  * Nummeraanduiding: zoek openbare Ruimte identifier in tbopenbareruimte (dvopruimteid).
    * Indien gevonden zoek nummeraanduiding-identifier in tbperceeladressen (dvbagidentcode_3):
      * indien gevonden: Wijzig perceeladreskaart
      * niet gevonden: foutmelding in tboperationslog.
    * Niet gevonden: foutmelding in tboperationslog.
  * Pand: wordt niets mee gedaan. 
  * Verblijfsobject of ligplaats of standplaats: zoek verblijfsobject-identifier c.q. ligplaatsidentifier c.q. standplaatsidentifier in tbperceeladressen (dvidentificatiecode): 
    * indien Gevonden: Wijzig perceeladreskaart
    * indien Niet gevonden: foutmelding in tboperationslog.
**Nieuw**
  * Openbare Ruimte zoek woonplaatsidentifier in tbwoonplaats (dvidentificatiecode).
    * Indien gevonden zoek openbare ruimte identifier in tbopenbareruimte (dvopruimteid): 
      * indien gevonden (jawel dat kan!!) wijzig openbare ruimte-kaart
      * niet gevonden: Insert openbare ruimtekaart bij woonplaats.
    * Niet gevonden: foutmelding in tboperationslog.
  * Nummeraanduiding zoek openbare Ruimte identifier in tbopenbareruimte (dvopruimteid).
    * Indien gevonden zoek nummeraanduiding-identifier in tbperceeladressen (dvbagidentcode_3):
      * indien gevonden: (jawel dat kan!!): Wijzig perceeladreskaart
      * niet gevonden: insert perceeladreskaart bij openbare ruimte.
    * Niet gevonden: foutmelding in tboperationslog.
  * Pand wordt niets mee gedaan.
  * Verblijfsobject of ligplaats of standplaats: zoek nummeraanduiding-identifier in tbperceeladressen (dvbagidentcode_3). 
    * Indien gevonden:
      * indien tbperceeladressen.dvidentifier leeg: wijzig perceeladreskaart (en vul dvidentifier met vbo-, lig- of sta-identifier)
      * indien tbperceeladressen.dvidentifier = verblijfsobjectidentifier c.q. ligplaatsidentifier c.q. standplaatsidentifier: wijzig perceeladreskaart 
      * indien tbperceeladressen.dvidentifier gevuld met andere identifier: foutmelding in tboperationslog.
    * Niet gevonden: foutmelding in tboperationslog.

==== Rapport ====

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

Deze ziet er als volgt uit:

<code sql>
  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
</code>
en bij SQL2: a.ddcontrolebag = %datum% .

{{:openwave:applicatiebeheer:probleemoplossing:programmablokken:variabele.jpg?600|variabele}}
  
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.x.x uitgeleverd door de BAG. Zowel van de volledige BAG als de BAG mutaties.

In de Configuratie is een  instelling: //Sectie: Operations// en //Item: Inlezenbag// waarbij //Getal2// de waarde 2 zou moeten hebben.

//Getal2// geeft aan welke versie. 2.0 = versie 2.1.0

Omdat OpenWave maar één versie ondersteunt wordt niet naar //Getal2// van deze instelling gekeken.

{{tag>openwave:1.34:applicatiebeheer:functionaliteiten:bag}}