BAG berichtencatalogus en Omdraaien Hoofd en Nevenadres

Dit is een statische kopie van het eerdere discussie.kinggemeenten.nl.
Nieuwe discussies kunnen in de GitHub repository 'StUF standaarden' als issue worden opgevoerd.

9 reacties / 0 nieuw
Han Welmer
BAG berichtencatalogus en Omdraaien Hoofd en Nevenadres

Volgens de XSD van de BAG berichtencatalogus mogen in een braHNO_Lk03 bericht in het was en wordt voorkomen NIET de elementen opr.identificatie en gor.straatnaam voorkomen.

Volgens het BAG processenhandboek (zie pagina 61) kan de identificatie bijbehorende openbare ruimte wel degelijk wijzigen.

Daarnaast is voor een correcte mapping naar 0204 en ontvangende applicaties die werken volgens 0204 de aanwezigheid van gor.straatnaam gewenst.

We hebben het vermoeden dat de verkeerde restrictie TGO-Lk01-bag-VBO-wijzigenAanduiding is gebruikt. Wij stellen dus voor dit via een erratum op de BAG berichtencatalogus te corrigeren.

Robert Melskens

Han, ik neem aan dat je braHNU_Lk03 bedoeld?

Ik heb even naar het processenhandboek gekeken maar of ik kijk naar een andere versie van het handboek (ik kijk naar 'http://www.kadaster.nl/BAG/docs/processenhandboek.pdf', de versie van 2009) of jij vergist je in de pagina.

Op pagina 61 van de versie waar ik naar heb gekeken staan gegevens die verband houden met BGR-SSV. 2 pagina's verder wordt er wel iets gezegd over BRA-HNU. Daar zie je dat bij de gebeurtenis 'Muteren gegevens nummeraanduiding' inderdaad gebruik gemaakt zou moeten worden van 'Identificatiecode bijbehorende openbare ruimte'. In het voorbeeld dat op de volgende pagina (64) volgt zie je dat gegeven echter niet meer terug.

Misschien kijk ik echter helemaal verkeerd vandaar mijn vraag of je even exact aan kunt geven waar we moeten kijken?

Han Welmer

Wij gebruikten versie 1.12 dd augustus 2007. Jouw link wijst naar versie 2009 dd juli 2009. Daarin staat op pagina 66 op de 5e regel van onderen hetyzelfde als in de oude versie op pagina 61: Identificatiecode bijbehorende openbare ruimte  98  96

Robert Melskens

Uit het processenhandboek blijkt inderdaad dat 'opr.identificatie' voor moet komen. Ook zie ik nu dat je niet braHNO_Lk03 of braHNU_lk03 bedoeld maar braOHN_Lk03.

In het door complexType 'TGO-Lk01-bag-VBO-wijzigenAanduiding' gebruikte complexType 'TGO-bag-VBO-wijzigenAanduiding' zie ik in echter dat het element 'adresAandudingGrp' de elementen 'opr.identificatie' en 'gor.straatnaam' ter beschikking stelt. Volgens mij is er dus geen probleem.

Han Welmer

Robert, het gaat inderdaad om bericht braOHN_Lk03. Onderstaande details komen uit de BAG berichtencatalogus als onderdeel van patch 15 van bg0310.

Daarin staat in bestand bg0310\bag\bg0310_msg_bag.xsd bij het braOHN_Lk03 bericht een element aoaLk01 van het type AOA-Lk01-bag-wijzigAanduiding. Dat is een restrictie van AOA-Lk01, waarbij de was/wordt voorkomens van de AOA objecten van het type AOA-bag-wijzigAanduiding zijn. Deze worden op hun beurt gedefinieerd in bestand bg0310_ent_bag.xsd.

In bestand bg0310\bag\bg0310_ent_bag.xsd wordt AOA-bag-wijzigAanduiding gedefineerd als een restrictie van AOA-kennisgeving, waarbij ondermeer wel de elementen identificatie (van het AOA object) en gor.openbareRuimteNaam worden toegestaan, maar niet opr.identificatie en gor.straatnaam (welke wel voorkomen in AOA-kennisgeving).

Merk op dat deze post gaat over het ontbreken van de elementen opr.identificatie en gor.straatnaam in de restrictie AOA-bag-wijzigAanduiding. Tijdens het koppelen met pakketten van derden zijn wij nog geen problemen tegengekomen met betrekking tot andere elementen die wel in AOA-kennisgeving voorkomen maar niet in deze restrictie. Maar mijn gevoel zegt dat we soortgelijke problemen kunnen verwachten met ondermeer wpl.identificatie en wpl.woonplaatsNaamNen in het geval van de gebeurtenissen Hernoemen woonplaats (bericht braBWP), Wijzigen grens woonplaats (bericht braWGW) en Gemeentelijke herindeling/grenscorrectie (bericht bagHER).

Robert Melskens

Han,

Het is me duidelijk nu.

In de complexType 'AOA-bag-wijzigAanduiding' moet ik dus opr.identificatie en gor.straatnaam optioneel maken. Dit kan zonder problemen aangezien deze complexType nergens anders gebruikt wordt.

Met de andere door jou genoemde elementen (wpl.identificatie en wpl.woonplaatsNaamNen) zou ik hetzelfde kunnen doen.

Ik hoor graag van anderen of hier bezwaren tegen zijn?

Robert Melskens

Dit probleem is opgenomen in de onderhoudsverzoeken als ERR261.

Robert Melskens

Door overleg met Han is meer duidelijkheid verkregen met betrekking tot de berichten Hernoemen woonplaats (bericht braBWP), Wijzigen grens woonplaats (bericht braWGW) en Gemeentelijke herindeling/grenscorrectie (bericht bagHER).

Han bedoelt niet braBWP maar braHWP. Daar dienen in het complexType 'AOA-bag-hernoemenWoonplaats' de elementen 'wpl.identificatie' en 'wpl.woonplaatsNaamNen' optioneel gemaakt te worden.

Betreffende braWGW en bagHER geeft Han de volgende toelichting:

Wat braWGW betreft, daarbij kan, naar mijn mening, een nummeraanduiding in een andere woonplaats of aan een andere straate te komen liggen. Dat zou betekenen dat in de aoaLk01 van de restrictie AOA-Lk01-bag-grenswijzigingWoonplaats de opr, gor en wpl attributen optioneel aanwezig moeten zijn om wijzigingen in deze platgeslagen gegevens door te kunnen geven. De drie wpl attributen zitten erin, ook de gor.openbareRuimteNaam maar de gor.straatnaam en opr.identificatie ontbreken in deze restrictie.

Tenslotte bagHER. Dat is een beetje een manusje van alles, waarmee alle wijzigingen naar aanleiding van een complete gemeentelijke herindeling doorgegeven moeten kunnen worden. In dit bericht is dan ook voor zo’n beetje elke entiteit een wijzigkennisgeving opgenomen. Alleen ontbreken, naar mijn mening, de aoaLk01 en oprLk01 kennisgevingen. Vergelijk dit maar eens met braWGW, waar een restrictie op deze wijzigkennisgevingen wel in zitten. Volgens mij zouden de restricties AOA-Lk01-herindeling en OPR-Lk01-herindeling hetzelfde moeten zijn als respectievelijk de bestaande restricties AOA-Lk01-bag-grenswijzigingWoonplaats en OPR-Lk01-bag-grenswijzigingWoonplaats. Je kunt natuurlijk nieuwe restricties XXX-Lk01-herindeling toevoegen of de bestaande restricties XXX-Lk01-bag-grenswijzigingWoonplaats hergebruiken (waarbij de naam dan wellicht verwarring kan opleveren). Ik zou kiezen voor het eerste, mede omdat in AOA-LK01 de platgeslagen attributen gem.gemeenteCode en gem.gemeenteNaam ontbreken, wat wij al eens eerder gemeld hebben bij het VROM BAG koppelvlak overleg toen deze spec tot stand is gekomen maar wat blijkbaar nog niet verwerkt is. Ach, dat probleem komen we later in de praktijk wel weer tegen. Hoe dan ook, als je ervoor kiest nieuwe restricties XXX-Lk01-herindeling aan te maken kunnen je in de toekomst deze wijziging gemakkelijk exclusief daarin opnemen zonder dat dit ongewenste neveneffecten heeft voor de restricties in het braWGW bericht.

Robert Melskens

In de complexType 'AOA-bag-wijzigAanduiding' dat wordt gebruikt in aoaLk01 zijn de elementen 'opr.identificatie en gor.straatnaam' optioneel gemaakt. T.b.v. de braHWP zijn in het complexType 'AOA-bag-hernoemenWoonplaats' de elementen 'wpl.identificatie' en 'wpl.woonplaatsNaamNen' optioneel gemaakt. T.b.v. braWGW is in de aoaLk01 van de restrictie AOA-Lk01-bag-grenswijzigingWoonplaats de gor.straatnaam en opr.identificatie toegevoegd. T.b.v. de bagHER zijn in de aoaLk01 van de restrictie AOA-Lk01-bag-grenswijzigingWoonplaats de gor.straatnaam en opr.identificatie toegevoegd.

Discussie gesloten.