Gebruiksoppervlakte in BAG-gebeurtenis Beschikbaar komen ingemeten geometrie

[evanzuiden]

Dit is voor mij de eerste keer dat ik een bericht op dit forum plaats. Mijn naam is Edwin van Zuiden en ik ben coördinator van team Gegevensbeheer bij de Gemeenschappelijke Regeling A2 Gemeenten. Inhoudelijk houd ik me al heel lang bezig met Datadistributie en StUF-BG. Vandaar onderstaande vraag. Ik hoop dat iemand mij kan adviseren.

De StUF-BG standaard en de Praktijkhandleiding zijn naar mijn idee niet in overeenstemming met elkaar als het gaat om het wijzigen van de gebruiksoppervlakte bij de gebeurtenis 'Beschikbaar komen ingemeten geometrie'.

De StUF-BG 3.10 standaard stelt dat de volgende elementen worden opgenomen in een bericht op basis van deze gebeurtenis: `

</complexType>`

Hierin is de gebruiksoppervlakte dus geen onderdeel van het bericht. In de praktijkhandleiding BAG staat echter bij dezelfde gebeurtenis:

De definitieve geometrie van het pand(en) is geregistreerd in de BAG. Het pand(en) krijgt de status Pand in gebruik. De definitieve gebruiksoppervlakte van het betrokken verblijfsobject(en) is opgevoerd in de BAG. Het verblijfsobject(en) krijgt de status Verblijfsobject in gebruik.

De praktijkhandleiding stelt dus dat bij het beschikbaar komen van ingemeten geometrie de gebruiksoppervlakte wél kan worden aangepast, de StUF-BG standaard neemt het echter niet op in het bericht. Dit levert de vervelende situatie op dat in de BAG applicatie de gebruiksoppervlakte wordt aangepast, maar de afnemers hiervan niet op de hoogte worden gebracht.

Is mijn aanname correct dat er sprake is van een discrepantie?

met vriendelijke groet, Edwin van Zuiden

[melsk-r]

Edwin,

Ik vermoed dat het BGR-BIG bericht niet bedoeld is voor de door jou gewenste functionaliteit. Het is puur bedoeld om mee aan te geven dat de geometrie is ingemeten en dat deze beschikbaar is gesteld. De gebruiksoppervlakte kan daarna met een ander StUF-BG bericht worden opgehaald.

@sbrouwer71 Hoe kijk jij hier tegenaan? Heeft Edwin een punt?

[sbrouwer71]

Die berichten zijn (inmiddels al ruim 10 jaar geleden!) gebaseerd op het processenhandboek versie 2009 van de BAG. Daarin staan bij de gebeurtenis BGR-BIG de volgende te wijzigen attributen opgenomen: PAND: Pandgeometrie: Opname definitieve pandgeometrie Pandstatus: Toekenning status “Pand in gebruik” Datum begin geldigheid pandgegevens: Opname ingangsdatum Documentdatum mutatie pand: Opname datum verwerking meetgegevens Documentnummer mutatie pand: Opname uniek kenmerk meetbestand VERBLIJFSOBJECT (optioneel): Verblijfsobjectgeometrie: Opname definitieve verblijfsobjectgeometrie Verblijfsobjectstatus: Toekenning status “Verblijfsobject in gebruik” Datum begin geldigheid verblijfsobjectgegevens: Opname ingangsdatum Documentdatum mutatie verblijfsobject: Opname datum verwerking meetgegevens Documentnummer mutatie verblijfsobject: Opname nummer document meetgegevens

Ik kan me heel goed voorstellen dat je op zo'n moment ook constateert dat de oppervlakte bijgesteld moet worden en misschien is dat in latere versies van de BAG ook wel aangepast (ik houd me al lang niet meer met de BAG bezig). Een wijziging van de oppervlakte zal dus in een ander bericht moeten worden doorgegeven, lijkt mij. In ieder geval volgens het ontwerp van het koppelvlak.

[evanzuiden]

Hallo Sid,

Dank je wel voor de reacties. Conform StUF heb je inderdaad gelijk @sbrouwer71. Mijn punt is vooral dat de praktijkhandleiding stelt dat bij het beschikbaar komen van ingemeten geometrie de gebruiksoppervlakte wél kan worden aangepast. Dat zou suggereren dat het StUF-bericht wel de gebruiksoppervlakte zou moeten bevatten. Op dit moment doen we dit inderdaad in twee verschillende berichten.

[sbrouwer71]

Hallo Edwin (@evanzuiden), Niet alleen conform StUF kan het niet, maar ook conform het processenhandboek BAG (van die tijd, dus versie 2009, maar ook nog in de versie van 2012).

Probleem is dat er geen wijzigingen meer zijn doorgevoerd in StUF, waar dat aan de kant van de BAG blijkbaar wél het geval is geweest. Blijkbaar heb je dus (in antwoord op de vraag van @melsk-r) een punt. De vraag die rest is dus of de kosten van het aanpassen (in een onbekend aantal implementaties) opwegen tegen de winst van het in één bericht doorgeven.

[melsk-r]

Hoi Edwin,

Jij geeft aan dat naar de tekst

De definitieve geometrie van het pand(en) is geregistreerd in de BAG. Het pand(en) krijgt de status Pand in gebruik. De definitieve gebruiksoppervlakte van het betrokken verblijfsobject(en) is opgevoerd in de BAG. Het verblijfsobject(en) krijgt de status Verblijfsobject in gebruik.

naar jouw mening suggereert dat het StUF bericht de gebruiksoppervlakte zou moeten bevatten. Eerlijk gezegd zie ik geen grond voor die suggestie wat niet betekent dat ik me niet kan voorstellen dat de behoefte er is.

Het onderhoud op de StUF onderlaag en StUF sectormodellen en StUF koppelvlakken die in beheer zijn bij VNG Realisatie staat echter op een laag pitje sinds VNG Realisatie vol inzet op API standaarden. Dat betekent dat we alleen wijzigingen aanbrengen op deze standaarden als daar vanuit wet- en regelgeving redenen voor zijn, als aanpassingen in het LO van een van de basisregistraties gevolgen hebben voor het gemeentelijke berichtenverkeer of als er fouten geconstateerd worden in deze standaarden die belemmerend werken voor gemeenten. Het komt er op neer dat we er voor zorgen dat Gemeenten hun werk kunnen blijven doen. Ik twijfel er aan of dit probleem daar onder valt.

[evanzuiden]

@melsk-r Het is inderdaad een interpretatie dat dit betekent dat het in een handeling moet kunnen.

Ik lees het als volgt: Het uitvoeren van het proces "beschikbaar komen ingemeten geometrie" leidt tot de volgende 3 resultaten:

1. De definitieve geometrie is opgenomen in de BAG;
2. De definitieve gebruiksoppervlakte is opgenomen in de BAG;
3. De status van het verblijfsobject wijzigt in 'Verblijfsobject in gebruik'.

Naar mijn mening zou punt 2 hier conform StUF niet mogen staan, of moet de StUF-standaard worden aangepast. Nu is er de situatie dat je binnen het proces "beschikbaar komen ingemeten geometrie" de gebruiksoppervlakte kunt wijzigen, maar dat deze niet wordt opgenomen in het bericht.

Reden waarom ik het graag wil weten is dat wij hebben geconstateerd dat er afwijkingen tussen BAG en WOZ zijn ontstaan door het muteren van de gebruiksoppervlakte in het proces BGR-BIG, waardoor de oppervlakte niet is gewijzigd in de WOZ. Op dat moment constateerden we dat de oppervlakte niet in de berichten is opgenomen. Het feit is dus dat je gegevens kunt wijzigen in het proces die niet worden opgenomen in het berichtenverkeer.

[melsk-r]

Edwin,

Ik denk dat punt 2 een toevoeging aan de Praktijkhandleiding (en dus ook aan de Gebeurtenisbeschrijving BAG 2018) is t.o.v. de 2009 en 2013 versies van het Processenhandboek. Ik verwacht niet dat dat een fout is. Bij nader inzien denk ik dat het StUF BAG koppelvlak hier dus op aangepast had moeten worden. De workaround hier is, zoals Sid al aangeeft, het sturen van een StUF-BG 3.10 tgoLk01 bericht waarmee de oppervlakte van het verblijfsobject alsnog kan worden doorgegeven.

[RuudKathmann]

Ik ben erg voor de interpretatie van Sid. Wanneer de gebruiksoppervlakte wijzigt is dat een andere "gebeurtenis". Daarbij zou ik dat niet willen zien als een workaround, maar als de beoogde werkwijze.

Immers de gebeurtenissen zijn bedoeld om afnemers te ondersteunen bij het verwerken van BAG-mutaties. In de BAG is de wijziging van de gebruiksoppervlakte iets fundamenteel anders dan de wijziging van de geometrie. Immers de gebruiksoppervlakte komt in beginsel uit een brondocument (vergunning oid), terwijl de geometrie uit een inmeetproces komt van de gemeente. Die twee wijzigingen (definitieve geometrie en wijziging gebruiksoppervlakte) onderbrengen in één gebeurtenis verplicht een afnemer die alleen geïnteresseerd is in de gebruiksoppervlakte om ook alle berichten over definitieve geometrie te gaan beoordelen.

Ik zou dus BZK verzoek om de formulering van punt 2 aan te passen. Daar staat nu: "De definitieve gebruiksoppervlakte is opgenomen in de BAG;" Dat zou dan bijvoorbeeld kunnen worden: "De definitieve gebruiksoppervlakte is mogelijk ook aangepast. Indien dit het geval is wordt dit als afzonderlijke gebeurtenis aangeleverd "Correctie naar aanleiding van signalering;"

[melsk-r]

Het Kadaster heeft aangegeven hierover contact op te gaan nemen met BZK en het verder met hen af te handelen.