Op 1 juli 2018 is de vernieuwde wetgeving voor de BAG ingegaan. Onder meer is een nieuwe versie van de BAG-catalogus (waarin IMBAG 2.0 is opgenomen) en van het koppelvlak met de landelijke voorziening BAG (StUF-LVBAG) uitgebracht. Zie voor meer informatie de websites van BZK en Kadaster. Een en ander heeft consequenties voor StUF-BAG cq. de BAG-berichtencatalogus (en voor StUF-BG i.h.a., zie deze discussie). De wijzigingen als gevolg van BAG 2018 worden in StUF-BAG verwerkt door het ‘terugvertalen’ naar BAG 2009 en extraElementen (d.w.z. niet in een nieuwe versie). De consequenties zijn geanalyseerd en beschreven in het bijgevoegde document ‘Consequenties BAG 2018 voor StUF-koppelvlakken VNG Realisatie’. Deze zijn voor StUF-BAG uitgewerkt naar specificaties van extraElementen en transformatieregels, zie bijgaand wijzigingsvoorstel op de beschrijving van de berichtencatalogus.
Wij, VNG Realisatie, zijn voornemens deze wijzigingen uit te brengen in een patch op StUF-BAG cq. de BAG-berichtencatalogus. Mochten hierover vragen of opmerkingen zijn dan zien we die graag hieronder, binnen 1,5 maand. Mocht dat tot discussie leiden over de aanpassingen dan zullen we de StUF-expertgroep vragen om een oordeel en besluitvorming.
In het document met de analyse van consequenties is in tabel 2 een foutje geslopen. Abusievelijk worden enkele extraElementen daar nog aangeduid met bag2_... terwijl dat bag18_... moet zijn. Bijgaand het gecorrigeerde document.
Bijlage
Gezien eerdere gesprekken die hierover (ook buiten dit forum) zijn gevoerd, gaat Centric akkoord met de voorgestelde oplossingsrichting.
In de tabel 'Mapping BAG-gebeurtenissen 2018 op enumeratie van CodeGebeurtenis' (hoofdstuk 7 van 'Berichtencatalogus bg0310-BAG v1.16 voorstel') staat op de vierde rij in de opmerking kolom "2018-gebeurtenis 'mapt' op BAG-MUT, niet op BAG-COR" terwijl de eerste kolom (voor de code 2018) leeg is.
Waar slaat deze opmerking op?
In de tabel 'Mapping BAG-gebeurtenissen 2018 op enumeratie van CodeGebeurtenis' (hoofdstuk 7 van 'Berichtencatalogus bg0310-BAG v1.16 voorstel') staat bij de 2018 code BGR-HMO dat deze 'mapt' op BAG-AOC.
Volgens de gebeurtenisbeschrijving 2018 heeft kan een BGR-HMO gebeurtenis betrekking hebben op een pand, verblijfsobject, nummeraanduiding, openbare ruimte, woonplaats, standplaats en ligplaats.
In de StUF xsd bagOAC_Lk03 ontbreken echter de elementen voor een woonplaats, openbare ruimte, ligplaats en standplaats.
In de tabel 'Mapping BAG-gebeurtenissen 2018 op enumeratie van CodeGebeurtenis' (hoofdstuk 7 van 'Berichtencatalogus bg0310-BAG v1.16 voorstel') staat bij de 2018 codes BRA-SAW en BRA-SPW dat deze beide 'mappen' op BRA-BWP
Volgens de gebeurtenisbeschrijving 2018 heeft kan een BRA-SAW gebeurtenis en een BRA-SPW betrekking hebben op een woonplaats, nummeraanduiding en openbare ruimte.
In de StUF xsd bagBWP_Lk03 ontbreken echter de elementen voor een nummeraanduiding en openbare ruimte.
Oscar, je legt de vinger op een aantal zere plekken. Neem je laatste bericht over Splitsen Woonplaats.
Deze ene gebeurtenis heeft zeker 2 woonplaats berichten richting LV: voor een nieuwe woonplaats, en voor een woonplaats wijziging. En omdat in de LV berichten voor openbare ruimte het BAG-ID is opgenomen van de gerelateerde woonplaats, krijg je voor die openbare ruimtes ook weer wijzig berichten voor hen.
De tabel behoeft uitbreiding, in de zin dat benoemd wordt dat er Lk03 voor een nieuwe woonplaats komt (BRA-BWP), én een Lk03 voor een woonplaats wiziging (BRA-WGW), en x Lk03's voor openbare ruimte wijzigingen. Welke die laatste dan moeten zijn? Ik zou denken BAG-MUT.
Berichten catalogus, pagina 16, extraElement bag18_codeGebeurtenis. Bij de opsomming van de entiteittypen ontbreekt NUM. Immers, bij de (nieuwe) gebeurtenis splitsen openbare ruimte (BRA-SOR) kunnen ook nummeraanduidingen worden getroffen. De berichten daarvoor moeten ook voorzien worden van dit extra element.
Hiermee wordt bedoeld dat er wel een 2018-gebeurtenis is die BAG-COR heet maar dat die niet mapt op de gelijknamige 2009-gebeurtenis maar op BAG-MUT.
Op de andere reacties van Oscar Dekker en ook Joop van Buul zijn we aan het zoeken naar een oplossing. Ideeen zijn welkom.
In het voorstel staat bij de beschrijving van de (al bestaande) extraElementen begindatumTijdvakGeldigheidBAG en einddatumTijdvakGeldigheidBAG :
De in het IMBAG 2.0 toegevoegde metagegeven over het onderzoek van een kenmerk is, volgens het informatiemodel, geen onderdeel van de objectkenmerken.
Kan dit metagegeven van een object worden beschouwd als een de in de beschrijving bedoelde 'extra attributen' ?
Het in-onderzoek extraElement stond abusievelijk in de opsomming van extraElementen en is cq. wordt daaruit verwijderd. Het speel dus geen rol meer wat de vraag niet van toepassing maakt.
Overigens, was dit extraElement gebleven, dan was het weliswaar een BAG-gegeven maar met een eigen historie in de BAG, onafhankelijk van de BAG-inhoudelijke gegevens maar ook onafhankelijk van de BAG+ -gegevens.
De vraag is mijns inziens wel van toepassing.
De vraag gaat namelijk niet over het in-onderzoek extraElement maar over een metagegeven van een bag object in combinatie met de beschrijving van de (al bestaande) extraElementen begindatumTijdvakGeldigheidBAG en einddatumTijdvakGeldigheidBAG.
.. dan was het weliswaar een BAG-gegeven maar met een eigen historie in de BAG, onafhankelijk van de BAG-inhoudelijke gegevens maar ook onafhankelijk van de BAG+ -gegevens.
En is een BAG-gegeven met een eigen historie, onafhankelijk van de BAG-inhoudelijke gegevens en ook onafhankelijk van de BAG+ gegevens, te beschouwen als een in de beschrijving bedoeld 'extra attribuut' ?
'extra attributen' ken ik niet, wel extraElementen. Ik neem aan dat je daarop doelt. Een dergelijk element is of een BAG-gegeven of een BAG+ - gegeven. De toegevoegde elementen zijn, m.u.v. codeGebeurtenis, te beschouwen als BAG-elementen. Ze worden immers genoemd in de BAG-catalogus. Een twijfelgeval is versienummer: geen authentiek gegeven maar wel genoemd in de BAG-catalogus. Wat mij betreft daarom beschouwen als BAG-gegeven.
In het document "Berichtencatalogus bg0310-BAG -v1.16 voorstel - met renvooi.pdf" wordt in paragraaf 6.2 en paragraaf 6.3 de term 'extra attributen' gebruikt.
Dit onderhoudsverzoek is opgevoerd in de onderhoudsverzoeken als ERR0516.
De lijst met onderhoudsverzoeken vind je op:
gemmaonline.nl/index.php/StUF-Expertgroep#Documenten
@Oscar, post #5. Goede opmerking. Voor het mappen van de gebeurtenis BGR-HMO is BAG-AOC niet de geschikte kandidaat omdat in het bagOAC_Lk03 (en Lk04) bericht inderdaad niet alle relevante BAG-objecten kunnen worden opgenomen. Dit kunnen we oplossen door het te mappen op de generieke gebeurtenis BAG-COR. Immers het historisch maken van een ten onrechte opgevoerd object kan gezien worden als een correctie. In het bijbehorende bagCOR_Lk03 (en Lk04) bericht kunnen wel alle genoemde objecten worden opgenomen.
@Oscar, post #6. Terechte opmerking. Voor het mappen BRA-SAW en BRA-SPW is BRA-BWP inderdaad niet geschikt. De oplossing is om te mappen naar de generieke gebeurtenis BAG-MUT. Immers het splitsen en samenvoegen van woonplaatsen kan ook worden uitgedrukt met generieke mutaties. Er is dan echter nog één resterend probleem: de bagMUT_Lk03 (en ook bagCOR_Lk03) berichten kunnen geen toevoegingen communiceren omdat in het schema van deze berichten voor elke mutatie zowel het was- als het wordt-voorkomen verplicht is. Dit is een bug omdat toevoegingen met slechts alleen een wordt-voorkomen worden gecommuniceerd. Deze bug zal hersteld moeten worden in dezelfde patch. De fix (minimaal 1 voorkomen in plaats van minimaal twee voorkomens) is gelukkig wel backwards compatible.
Bijgaand de patch op het schema betreffende de berichten bagMUT_Lk03, bagMUT_Lk04, bagCOR_Lk03 en bagCOR_Lk04. De minOccurs van de object-elementen is van 2 naar 1 verlaagd zodat er ook toevoeg-mutaties mogelijk zijn.
Bijlage
@Oscar, post #15. Volgens mij wordt met de term "extra attributen" de BAG+ attributen van het RSGB bedoeld. Het zijn extra attributen bovenop de authentieke attributen uit de BAG voor binnengemeentelijk gebruik. Het zijn dus wel gewoon volwaardige attributen in het RSGB.
N.a.v. de hiervoor geconstateerde mappingproblemen van BAG2018-gebeurtenissen hebben we, VNG Realisatie, ons gebogen over de mapping van alle BAG2018-gebeurtenissen die niet voorkomen in de BAG-berichtencatalogus cq. dit koppelvlak. Bijgaand het resultaat. Van een aantal BAG2018-gebeurtenissen moet de mapping dus gewijzigd worden. We verwerken dit in de koppelvlakbeschrijving.
Bijlage
@Henri, post #19. Hebben <patch> en <patchdatum> in <appinfo> wel de correcte waarden ?
Klopt Oscar, voordat we het patch bestand publiceren passen we dat aan.
Dat geldt overigens ook voor schemaversie die 1 opgehoogd moet worden en het 'version' attribute op het 'schema' element wijzigen we dan ook in '031006'.
In het document "gebeurtenissenbeschrijving 2018" staat in scenario 1.19 Intrekken nevenadres dat alleen de nummeraanduiding wordt gemuteerd en dat het adresseerbare object niet wordt gemuteerd.
Volgens de StUF definitie bevat een BAGIN-Lk03 bericht een aoaLk01 samen met een vboLk01 of en ligStaLk01.
In documentatie over de mapping tussen oude en nieuwe gebeurtenissencodes ontbreekt de mapping voor de BAG-IN gebeurtenis.
Oscar, hetgeen vermeld staat in de "gebeurtenis beschrijving 2018" klopt, richting de LV. Als een nevenadres wordt ingetrokken, gaat er een bericht naar de LV dat alleen een mutatie van het nevenadres is met de status wijziging. Aan het vbo, lig of standplaats wijzigt niets. (De relatie adresseerbaar object naar NVA blijft dus gewoon bestaan).
Voor BG kan dat er anders uitzien.Daar moet vaker een heel circus worden opgetuigd. Neem een naamswijziging van een openbare ruimte. Richting LV is dat één bericht met alleen die naamswijziging. Voor BG zijn dat daarnaast ook nog aoa's en dan ook nog de vbo's, lig- en standplaatsen vanwege de adresaanduidingGroep.
Zo te zien heeft Arjan alleen de relevante gebeurtenissen opgenomen, relevant in de zin dat er iets gemapt moest worden. Zo staan BGR-MGB BGR-MGS BGR- SVSPLITS (noem ze maar op) er niet in omdat er niets gemapt hoeft te worden: Oud = Nieuw.
Vraag over het gebruik van de extra elementen bag18_statusVerblijfsobject, bag18_statusPand, bag18_codeGebeurtenis.
Nemen we deze elementen alléén op indien er spraken is van een nieuwe niet eerder ondersteunde status c.q. gebeurtenis?
Of nemen we die altijd op (in veel gevallen dan gevuld met oude reeds lang ondersteunde statussen of gebeurtenis code)?
Joop, Duidelijk, dank voor je reactie.
@VNG, post #24 kan vervallen
Het gaat om extraElementen conform BAG2018. De specificatie van deze extraElementen vermeld dat het om de enumeratie conform BAG2018 gaat. Het lijkt mij dan dat ze altijd gevuld moeten zijn. Indien geen tegenwerpingen tegen dit voorstel dan nemen we, VNG, dit op in de beschrijving.
Voor de volledigheid de volledige mapping van gebeurtenissen, met de doorgevoerde wijzigingen gemarkeerd.
Dit wordt opgenomen in de koppelvlakbeschrijving.
Bijlage
Er lijkt wat onduidelijkheid te zijn over de bovengenoemde patch. Zoals afgesproken wijzigen daarin de schema's cq. XSD's NIET. De patch is tekstueel (koppelvlakbeschrijving) en voegt enkele extraElementen toe.
CORRECTIE. Een kleine wijziging wordt wel doorgevoerd in de schema's, zie reactie #19 hierboven.
In de beschrijving van de mapping (document uit post #29) staat dat de 2018 code BAG-VG 'mapt' op BGR-MGB.
Volgens de gebeurtenisbeschrijving 2018 kan bij een BAG-VG gebeurtenis ook een nummeraanduiding (samen met het bijhorende verblijfsobject) worden ingetrokken.
In de StUF xsd bgrMGB_Lk03 ontbreekt echter een element voor een nummeraanduiding/AOA.
Hoi Oscar, bedankt voor de correcte observatie! We zullen BAG-VG mappen op het meer generieke BAG-MUT waarmee de nummeraanduidingen en verblijfsobjecten wel kunnen worden ingetrokken.
Bijgaand de aanpassingen in de berichtcatalogus-specificatie naar aanleiding van post #28 en post #33.
Bijlage
Als gevolg van post #28 is ook het verstuffingsdocument RSGB aangepast, zie deze post.
Henri, Het voorstel in post #34 is wel heel erg kort :) 1 blanco pagina.
Oscar, bedankt voor het attenderen. Ik probeer het nog een keer, maar nu in een gezipte-versie (zie bijlage).
Bijlage
Bijgaand nog een kleine verbetering doorgevoerd in bijlage 1 van het document.
Bijlage
In het document, hoofdstuk 7, is in de tabel op pagina 23 wel de mapping van BAG-VG op BGR_MGB gewijzigd naar BAG-MUT. Alleen niet de omschrijving in de 4e kolom.
Dank Joop voor de terechte observatie. Zie bijlage voor de verbetering.
Bijlage
In het document "BAG2 - Consequenties StUF-koppelvlakken 20180731.pdf" in de bijlage bij de eerste post van deze discussie staat expliciet dat de toekomstige mutaties niet worden meegenomen in het koppelvlak (pagina 2, onderaan). In de bijlage van post 21 staat bij de gebeurtenis BAG-ITM de tekst:
Ook bij BAG-OTM staat iets vergelijkbaars in het document. Voor volgende versies van het document geldt hetzelfde.
Begrijp ik het goed dat het de bedoeling is dat binnengemeentelijk toekomstmutaties moeten worden uitgewisseld? In de discussie hierboven vind ik daar niets over terug (behalve dus in de documenten in de bijlagen).
Zo ja, is deze keuze bewust gemaakt? Het kan een behoorlijk ingrijpende wijziging zijn voor ontvangende systemen (en tussenliggende systemen). Als deze momenteel nog geen behoefte hebben aan historie van gegevens (en die dus niet opslaan), dan wordt het moeten kunnen omgaan met toekomstige mutaties/gegevens een heel ingrijpende wijziging. Aangezien hiervoor Lk01/Lk02 berichten gebruikt moeten gaan worden, kan het ook nog zijn dat ontvangers, op basis van de StUF-onderlaag, deze berichten zullen afkeuren. De hele keten moet hierop (mogelijk) worden aangepast.
In het verleden is besloten om de toekomstige mutaties niet binnengemeentelijk te verspreiden en deze door de BAG-applicatie te laten opsparen tot het moment dat de ingangsdatum is aangebroken. Hiermee worden ontvangende systemen ontlast voor wat betreft het kunnen omgaan met historie/toekomst. Dit heeft tot nog toe (naar mijn weten) niet tot problemen geleid.
De initiële opzet van deze patch had als groot voordeel dat ontvangers met de nieuwe berichten om zouden kunnen gaan zonder wijzigingen (zolang ze de nieuwe gegevens niet zouden hoeven gebruiken), waarmee een overgang vrij geruisloos zou kunnen plaatsvinden. Met het toestaan van toekomstmutaties komt dit te vervallen. Zodra een BAG een toekomstmutaties gaat versturen moeten alle afnemers hierop zijn voorbereid om problemen te voorkomen.
Daarom zou ik willen voorstellen om de werkwijze van het opsparen van toekomstmutaties in de BAG te behouden. De BAG-applicaties kennen dit principe al, dus daarvoor zou het geen groot probleem moeten zijn. Ontvangende systemen hoeven niets aan te passen op dit vlak en kunnen dus nog steeds in eigen tempo over op de verwerking van de nieuwe berichten vanuit de BAG. Dit voorkomt de noodzaak van een 'big-bangimplementatie'.
Sid, bedankt voor je zeer heldere en terechte reactie! Ik heb de mapping van de gebeurtenissen BAG-ITM en BAG-OTM aangepast (zie bijlage). Ik hoop dat het nu goed is.
Bijlage
Mijns inziens is de mapping voor de gebeurtenis BRA-WGW niet correct. In het voorstel staat dat die niet is gewijzigd. De huidige xsd's ondersteunen NIET de gang van zaken zoals Kadaster het nu voorstelt.
In BAG2018 worden n.l. geen WPL's ingetrokken en nieuwe WPL's aangemaakt, zoals in de vorige versie wel het geval was.
Nu krijgen de bestaande WPL's een nieuw voorkomen (versie), met daarin de nieuwe geometrie. Het XSD schrijft echter voor dat de WPL's worden ingetrokken (wplLk01-intrekken) en nieuwe worden aangemaakt (wplLk01-opvoeren).
In het XSD staat een choice-constructie waardoor je niet verplicht bent om woonplaatsen in te trekken en/of op te voeren. Je kunt ook kiezen voor "wplLk01-inmetenGrens" waarmee je de grens van een woonplaats kunt wijzigen (zonder de identificatie van de woonplaats te veranderen).
<choice>
<element name="wplLk01-inmetenGrens" type="BG:WPL-Lk01-bag-wijzigenGrens"/>
<sequence>
<element name="wplLk01-intrekken" type="BG:WPL-Lk01-bag-intrekken"/>
<element name="wplLk01-opvoeren" type="BG:WPL-Lk01-bag-toevoegen"/>
</sequence>
</choice>
In post #18 schrijft Henri dat het toestaan van toevoegingen in bagMUT_Lk03 en bagCOR_Lk03 kan worden hersteld in de patch omdat dit backwards compatible zou zijn ("De fix (minimaal 1 voorkomen in plaats van minimaal twee voorkomens) is gelukkig wel backwards compatible.").
Dit is mijns inziens met deze wijziging niet meer het geval. Met de aanpassing zoals beschreven in post #6 zal een nieuw bericht met daarin een toevoeging niet door de schemavalidatie komen in een ongewijzigde ontvanger. Een ontvanger die op basis van de koppelvlakbeschrijving ook logica heeft ontwikkeld met betrekking tot de afhandeling, kan ook nog in de problemen komen doordat er een soort mutatie wordt aangeleverd die volgens de (oude) specs niet is toegestaan. Allels een ontvanger hier strikt mee om gaat, zou deze het bericht kunnen afkeuren of misschien zelfs verkeerd verwerken (toegegeven; dit is niet erg robuust, maar onverwachte invoer kan tot onverwachte resultaten leiden).
Alle (overige) wijzigingen in de patch zijn erop gericht dat afnemers zonder softwareaanpassingen de nieuwe berichten moeten kunnen verwerken (onbekende extraElements kunnen/moeten immers worden genegeerd). Deze intentie is ook uitgesproken tijdens het bronhoudersleveranciersoverleg van 29 juni vorig jaar: "Arjen legt uit dat STuF BAG 3.10 niet wordt aangepast, dat houdt in dat er voor de afnemende applicaties niets verandert.".
Dit is een prima uitgangspunt, zeker omdat er een overgangsperiode is waarin gemeenten één voor één over zullen gaan op de nieuwe versie van de BAG. Loslaten van dit uitgangspunt zou betekenen dat afnemende systemen binnen de gemeenten klaar moeten zijn voor de nieuwe berichten op het moment dat de BAG over gaat op de nieuwe berichtenstandaard. Ofwel: een big bang implementatie of extra zorg aan de kant van de ontvangende systemen om tijdelijk zowel oud als nieuw te kunnen verwerken.
De kans dat het fout gaat (dat er een nieuw bericht wordt verstuurd met een toevoeging vóórdat de afnemers over zijn op de nieuwe versie) kan ik momenteel niet goed inschatten. Het risico dat we lopen daarmee dus ook niet. Maar strikt genomen kunnen we deze wijziging niet doorvoeren. In ieder geval niet zonder risico's op fouten.
Daarom pleit ik voor een heroverweging van deze wijziging en zo mogelijk een andere oplossing. Als er geen andere oplossing is, dan zal in ieder geval de impact en het risico moeten worden bepaald voor de implementatie van de patch. Bij doorvoeren van de oplossing zullen de afnemers zo snel mogelijk aan de slag moeten om de invoering van de patch probleemloos te laten verlopen.
@Sid, ik begrijp het probleem nog niet helemaal. Indien de ontvanger het schema nog niet heeft aangepast zal die inderdaad bagMUT_Lk03 en bagCOR_Lk03 berichten afkeuren in geval van bepaalde BAG 2018 gebeurtenissen waarin toevoegingen zijn opgenomen met één voorkomen. Maar in alle andere bestaande gevallen zal de ontvanger deze berichten wel correct verwerken. Het afkeuren van een bericht is niet werkelijk iets anders dan het negeren van extraElementen zolang er maar geen berichten worden afgekeurd die vroeger wel werden goedgekeurd.
@Henri, het lijkt mij wel degelijk een probleem als een bericht uit de cyclus wordt gemist. Als de toevoeging niet wordt verwerkt door de ontvanger, hoe moet de ontvanger dan weten dat er een nieuw object is en wat moet de ontvanger doen met eventuele mutaties op het object die volgen? Deze kunnen dan ook niet worden verwerkt.
Het niet verwerken van informatie waarmee je niets doet (het negeren van de extra elementen) is van een heel andere orde dan het niet verwerken van een heel bericht. De informatie in de 'reguliere' elementen wil je natuurlijk als ontvanger wel degelijk kunnen verwerken, ook als je de extra elementen niet ondersteunt. Dat zal niet lukken als het bericht niet valideert.
@Sid, bedankt voor de toelichting. Ik ben het met je eens dat het missen van berichten van een andere orde is dan het negeren van extra elementen. Gelukkig is er gisteren in het BAG Leveranciers overleg een nieuwe oplossing gevonden om het probleem te tackelen. Die zal hier zo snel mogelijk gepost worden.
Zoals toegezegd op het leveranciersoverleg hieronder mijn voorstel voor een aangepast mapping.
Voorstel aanpassing mapping tussen BAG 2018 (en 2013) gebeurtenissen en de BAG berichtencatalogus.
Voor de succesvolle implementatie van BAG 2.0 is het vereist dat de XSD’s voor het binnengemeentelijke berichtenverkeer niet wijzigen. Hieronder een voorstel voor een aangepaste mapping die geen aanpassing van de XSD’s met zich meebrengt. De consequentie hiervan is dat sommige gebeurtenissen opgedeeld moeten worden. Er is in dit voorstel rekening gehouden met de functionele inhoud van de gebeurtenissen.
Een deel van de gebeurtenissen die ontbreken in de BAG berichtencatalogus zijn afkomstig uit het BAG processenhandboek van 2013. De mapping van deze gebeurtenissen is geen gevolg van BAG 2.0.
BAG 2013 gebeurtenissen.
BAG-VTP (Verblijfsobject toevoegen aan pand)
Voorgestelde mapping:
BGR-COG (Constatering nieuw object) in de variant dat indicatie geconstateerd op ‘N’ staat.
BAG-WG (Wijzigen gebruiksdoel)
Voorgestelde mapping:
BAG-MUT Mutatie naar aanleiding van signalering. Inhoudelijk komt BAG-MUT meer overeen met deze gebeurtenis dan BGR-KVO kleine verbouwing
Inhoudelijke wijzigingen gebeurtenissen 2018
BRA-GHO (Gedeeltelijk hernoemen openbare ruimte)
Voorgestelde mapping:
BRA-HOR (Hernoemen openbare ruimte)
+Eventueel BAG-MUT voor het muteren van de nummeraanduiding(en)
BRA-GOR (Het verlengen, inkorten of verleggen van een openbare ruimte)
Voorgestelde mapping:
BRA-HOR (Hernoemen openbare ruimte)
+Eventueel BAG-MUT voor het muteren van de nummeraanduiding(en)
BRA-SAW (Samenvoegen woonplaatsen)
Voorgestelde mapping:
BAG-BWP (Benoemen woonplaats) +BAG-KWGW (Kleine wijziging grens woonplaats) + BRA-IWP (Intrekken woonplaats)
BRA-SOR (Splitsen van een openbare ruimte)
Voorgestelde mapping:
BRA-BOR (Benoemen openbare ruimte)
+Eventueel BAG-MUT voor het muteren van de nummeraanduiding
BRA-SPW (Splitsen van een woonplaats)
Voorgestelde mapping:
BRA-BWP (Benoemen woonplaats)
+Eventueel BAG-MUT voor het muteren van de objecten
BRA-WGW (Wijzigen woonplaatsgrens)
Voorgestelde mapping:
BAG-KWGW (Kleine wijziging grens woonplaats)
De in post #49 voorgestelde mapping voor BRA-SAW en BRA-WGW is niet mogelijk : er is geen bericht voor BAG-KWGW.
De voorgestelde mapping voor BRA-GHO is miz niet nodig, het BRA-GHO bericht bevat alle entiteiten die in de gebeurtenis voorkomen.
@Oscar:
Bedankt voor je reactie. Het was mij niet bekend dat er geen bericht voor BAG-KWGW is. Voor de mapping is dit overigens geen probleem. Ik zie dat ik bij BRA-SAW ten onrechte de gebeurtenis BAG-BWP (Benoemen woonplaats) had toegevoegd. Bij het samenvoegen van twee woonplaatsen ontstaat geen nieuwe woonplaats; het bestaande ID wordt hergebruikt.
Uit je bericht leid ik verder af dat BRA-WGW niet gemapt hoeft te worden. Het lijkt mogelijk te zijn deze gebeurtenis binnengemeentelijk te verwerken zonder nieuwe woonplaatscodes. Klopt dat?
Goed om te lezen dat BRA-GHO niet gemapt hoeft te worden. Daar wordt het weer iets eenvoudiger van.
Dan blijven volgens mij onderstaande aanpassing over:
BAG 2013 gebeurtenissen.
BAG-VTP (Verblijfsobject toevoegen aan pand)
Voorgestelde mapping:
BGR-COG (Constatering nieuw object) in de variant dat indicatie geconstateerd op ‘N’ staat.
BAG-WG (Wijzigen gebruiksdoel)
Voorgestelde mapping:
BAG-MUT Mutatie naar aanleiding van signalering. Inhoudelijk komt BAG-MUT meer overeen met deze gebeurtenis dan BGR-KVO kleine verbouwing
Inhoudelijke wijzigingen gebeurtenissen 2018
BRA-SAW (Samenvoegen woonplaatsen)
Voorgestelde mapping:
BRA-IWP (Intrekken woonplaats) + BAG-MUT
BRA-SOR (Splitsen van een openbare ruimte)
Voorgestelde mapping:
BRA-BOR (Benoemen openbare ruimte)
+Eventueel BAG-MUT voor het muteren van de nummeraanduiding
BRA-SPW (Splitsen van een woonplaats)
Voorgestelde mapping:
BRA-BWP (Benoemen woonplaats)
+Eventueel BAG-MUT voor het muteren van de objecten
Pagina's