Enumeraties voor status BAG-objecten niet compleet

Ik kan dit eerlijk gezegd niet volgen. Als een pand nog niet is opgenomen in de BAG dan bestaat er m.i. toch ook geen pand met een pandidentificatie? M.a.w. er kan dan nooit een status 'nog niet opgenomen in BAG' worden toegekend aan een niet in de BAG voorkomend pand. Hetzelfde geldt voor verblijfsobject. Graag nadere toelichting. Verder hebben we het hier over een koppelvlak specifiek gegeven. En dat moet dan  in het koppelvlak informatiemodel gedefinieerd worden en niet in het RSGB.

Direct na vergunningverlening wordt een Nummeraanduiding, Verblijfsobject en Pand toegevoegd aan de BAG (de BAG is een 'vergunde toestand'-registratie, geen fysieke werkelijkheid-registratie). Het genoemde probleem speelt dus alleen in de periode dat de vergunningaanvraag behandeld wordt. Voor wie (welke taakvelden) is in die fase een 'voorlopige' Nummeraanduiding e.d. van belang? Zijn er zoveel belanghebbenden dat die 'voorlopige' Nummeraanduiding e.d. een kerngegeven rechtvaardigt (pas na registratie in de BAG wordt het een basisgegeven)? Oftewel, moet dit in het RSGB opgelost worden, of elders? 

Is een mogelijkheid, het RSGB, maar dan moeten daar goede, functionele, inhoudelijke redenen voor zijn. Wat is de (functionele, inhoudelijke) argumentatie van de StUF-Expertgroep om dit in het RSGB op te nemen? En, als dat niet mogelijk is, wat is dan die andere plek? Niet StUF-BG lijkt me, want dan zou StUF-BG semantisch afwijken van RSGB en dat kan niet de bedoeling zijn.  

Wij zijn groot voorstander van het toevoegen van een extra status.  Wanneer gekeken wordt naar de werkprocessen voorafgaand aan de vergunning-verlening of het nemen van een huisnummerbesluit of een straatnaambesluit, dan kan wellicht zelfs besloten worden om meer dan één status toe te voegen.

Juist in de fase dat er nog geen omgevingsvergunning is, kan er sprake zijn van intensieve behoefte aan op elkaar afgestemde registraties. Iemand koopt een kavel met het doel een huis te gaan bouwen. In de periode dat de aanvraag voor een vergunning in behandeling is, ontvangt hij van de gemeente een WOZ-beschikking en aanslag, moet hij bij het energiebedrijf een aansluiting regelen en moet het project bij zijn aannemer goed in de administratie komen. Groot voordeel, wanneer dat allemaal kan op basis van de toekomstige nummeraanduiding. In de WOZ wordt daarom de "verwachte nummeraanduiding" al vaak gebruikt als aanduiding van het WOZ-object, voordat dit officieel in de BAG staat.

Overigens lijkt het ons zuiverder om de status niet te noemen "nog niet opgenomen in BAG", maar bijvoorbeeld "vergunning in voorbereiding" en "huisnummerbesluit in voorbereiding". Zelfs kan overwogen worden om een status toe te voegen "object gereserveerd", zodat bij het opstellen van een verkavelingsplan al toekomstige "adressen" bekend zijn, terwijl nog geen aanvragen voor een omgevingsvergunning zijn ingediend.

De voorbeelden overtuigen mij niet. Dat er in het BAG-beheerproces al een BAG-object gecreeerd is dat nog geen officiele status heeft (en dus nog niet bekend is in de LVBAG en dus nog geen deel uit maakt van een basisregistratie) wil nog niet zeggen dat dit buiten het BAG-beheerproces bekend zou moeten  zijn. Als het bijvoorbeeld een adres (nummeraanduiding) betreft, dan is dat nog geen basisgegeven en mag dus (nog) niet gebruikt worden. Een kavel met het doel een huis te bouwen waarvoor nog geen vergunning verleend is, blijft een onbebouwde kavel waarover in de BAG nog niets bekend is over eventuele bebouwing en bijbehorend adres. De WOZ-beschikking voor die kavel kan dus geen BAG-adres hebben (dat zou strijdig zijn met het verplicht gebruik van basisregistraties). Dat is er eenvoudigweg niet want niet te vinden in de (LV)BAG (geen andere adressen gebruiken dan dat er in de BAG staan). Een aansluiting regelen voor een nog niet (in de BAG) bestaand adres? Die wordt afgewezen want bij controle, door het energiebedrijf, in de BAG blijkt het een fake-adres te zijn. En die aannemer, die heeft niet zozeer met de BAG te maken maar met de opdrachtgever die een vergunningaanvraag heeft lopen bij de gemeente. De verbindende factor is de behandeling van die aanvraag, niet het BAG-beheerproces. Vanuit dat behandelproces kan desgewenst het voornemen tot toewijzing van een adres gecommuniceerd worden naar de aanvrager. Dat komt beschikbaar dmv het daarop gerichte koppelvlak Wabo-BAG waarin het BAG-beheerproces en het vergunningverleningproces op elkaar afgestemd zijn. Als de WOZ iets als een ‘verwachte nummeraanduiding’ zou willen (wel graag binnen het WOZ-beheerproces houden dus niet in beschikkingen en aanslagen vermelden want geen basisgegeven), dan moeten ze dat afstemmen met degene die in die verwachting voorziet: het vergunningverleningproces of het huisnummertoewijzingsproces. Al dan niet dmv een daarop gericht koppelvlak.

Motto: stem daar waar zinvol processen op elkaar af, desgewenst met daarop gerichte koppelvlakken. Maar ga geen potentiele basisregistratieobjecten breed bekend maken die er officieel nog niet zijn. Dat zou verwarring geven en is strijdig met het verplichte gebruik van basisregistraties.

Het toevoegen van toch een extra status aan de voorkant van de tijdlijn van een BAG-object, was een goed onderwerp geweest voor een discussie in de Expertgroep informatiemodellen. Nu deze niet doorgaat toch nog een poging om deze discussie via het Forum verder te brengen.

Het klopt dat voorafgaand aan de verlening van de vergunning het object nog geen object is in een basisregistratie en dus nog geen formele externe betekenis kan hebben. Maar in de RSGB staan meer objecten en gegevens waarvoor dat geldt. Denk aan de overige gebouwde objecten etc.

Voorafgaand aan de vergunningverlening kan al wel sprake zijn van diverse betrokkenen die eenduidig met elkaar moeten kunnen communiceren, juist in het proces van vergunningverlening. Bijvoorbeeld bij de beoordeling van de bouw aspecten kan een regionale omgevingsdienst betrokken zijn, terwijl het huisnummerbesluit een binnengemeentelijke aangelegenheid is. Daarom zou in een horizontaal koppelvlak over de BAG een extra status voor een verblijfsobject betekenis kunnen hebben, terwijl het object pas in het verticale koppelvlak naar de LV BAG mag voorkomen, wanneer de status "vergunning verleend" is bereikt. 

Het is een wezenlijk verschil of we het hier hebben over een object uit een basisregistratie en dus een wettelijke grondslag heeft  of objecten die in RSGB zijn opgenomen maar geen br-objecten zijn. Bij een  niet br- object is het heel makkelijk een extra status toe te voegen.

Maar bij een br object ligt dat wezenlijk anders. Zo is een bag object altijd gebaseerd op een besluit met de daarbij vereiste documenten.  Om dan nu een bag object te creeeren zonder een besluit is m.i. in strijd met  de bag wet en lijkt me dus niet de oplossing. En hoe ga je dan om met zo'n bag-object zonder zo'n wettelijke status, ga je daarover ook binnengemeentelijk gegevens uitwisselen?

Ik begrijp dat eenduidige communicatie van betrokkenen voorafgaand aan de vergunningverlening belangrijk is. Maar moeten we dan niet gebruik maken van standaarden die daarvoor ter beschikking staan zoals BIM (en VISI)? 

We hebben het hier over het RSGB. Dit is toch het model voor de binnengemeentelijke informatie? Omdat een pand voor de BAG pas bestaat op het moment dat de vergunning is verleend, betekent niet dat dat pand binnengemeentelijk al eerder bestaat en daarbij toch echt hetzelfde pand is als dat later in de BAG wordt opgevoerd.

Ik dacht dat het RSGB bedoeld was om een binnengemeentelijk gemeenschappelijk informatiemodel te creëren, waarmee de binnengemeentelijke uitwisseling van gegevens eenduidig kan worden voorzien van semantiek. Wat ik hierboven lees, lijkt er meer op dat we vooral kiezen voor heel formele ('buitengemeentelijke') standpunten die uiteindelijk de binnengemeentelijke uitwisseling van gegevens behoorlijk in de weg zullen gaan staan.

Moeten we nu opeens in andere uitwisselingsformaten gaan communiceren, omdat we niet willen erkennen dat er binnengemeentelijk een andere informatiebehoefte bestaat dan we in de landelijke basisregistratie hebben erkend? 
Ik vind dit erg jammer...

Klinkt op zijn minst tegenstrijdig: een object opnemen in de registratie en tegelijk zeggen dat dit object nog niet geregistreerd is. Het is mij niet geheel duidelijk wat nu de informatiebehoefte is, maar ik stel voor om het zuiver te houden. Tijdens de aanvraag is er nog geen (besluit voor een) Pand en dus kan ik het ook niet registreren. Het eerste feit dat je over een object registreert voordat je iets anders kunt registreren is dat er een object is, iets in de trant van "er bestaat een object met object-id 123445".

Overigens vind ik het volstrekt onlogisch om over een Pand te praten als er nog geen steen te zien is, maar ja, zo is dat in de BAG bedacht.

Poging om de informatiebehoefte te verwoorden: Het te bouwen pand op KADASTRAAL OBJECT met kadobj-id 879876 krijgt aan de OPENBARE RUIMTE met openbare ruimte-id 876865 waarschijnlijk HUISNUMMER 12.

Nog even over de verhouding informatiemodel en StUF: ALLE semantiek over de geregistreerde objecten ligt besloten in het informatiemodel, StUF kan daar niets aan toevoegen.

@SiD:Moeten we nu opeens in andere uitwisselingsformaten gaan communiceren, omdat we niet willen erkennen dat er binnengemeentelijk een andere informatiebehoefte bestaat dan we in de landelijke basisregistratie hebben erkend? 

Misschien hierin niet helemaal duidelijk geweest met mijn antwoord maar ik bedoel dat er een Bouw informatiemodel is waarin bouwprojecten en ik neem aan te bouwen objecten zijn opgenomen. In een domeinmodel vergunningen kan dan gerefereerd worden naar het te bouwen object (of het bouwproject) via de unieke aanduiding van dat object (of project) zoals opgenomen in het BIM als men gegevens daarover wilt uitwisselen met andere betrokken partijen. Dat kan dus via StUF. 

@Rindert: "Klinkt op zijn minst tegenstrijdig: een object opnemen in de registratie en tegelijk zeggen dat dit object nog niet geregistreerd is." Dat klopt helemaal. Maar ik zeg ook niet dat het object moet worden opgenomen in de BAG (de registratie), maar dat het wél al binnengemeentelijk van belang is. Daarom ook het voorstel om het waardebereik van de status uit te breiden, waarmee impliciet ook de definitie van het object wordt uitgebreid.

Als StUF niets kan toevoegen aan de semantiek die in de informatiemodellen is gedefinieerd, dan is het juist van belang dit in het RSGB op te lossen.

@Ellen: door te kijken naar een ander informatiemodel los je nog niet op (ook al zou je dat dan wel via StUF uit kunnen wisselen). Dat zou immers betekenen dat voor het uitwisselen van 'BAG-objecten in voorbereiding' andere typen gebruikt moeten worden dan voor de uiteindelijke BAG-objecten. Voor de informatiehuishouding binnen de gemeente is dit niet bepaald praktisch. Het adres in voorbereiding is in de praktijk hetzelfde adres als wat na vergunningverlening wordt gebruikt. Zou je hiervoor weer nieuwe typen introduceren, dan zou je op het moment van vergunningverlening de oude entiteiten moeten afsluiten en de relaties ernaar moeten verleggen naar de nieuwe entiteiten. Daarbij moet je waarschijnlijk ook nog de verbinding registreren tussen de voorgenomen nummeraanduiding en de BAG-nummeraanduiding. 
Een vergelijkbaar voorbeeld is dat in de BAG bij een woonplaatswijziging of bij enkele wijzigingen in openbare ruimten de identificaties van de oude voorkomens verdwijnen en veel gegevens moeten worden 'omgehangen'. Daar is ook niemand blij van geworden en in BAG 2.0 is/wordt dit dan ook gewijzigd. Het lijkt me niet verstandig om nu in RSGB/BG alsnog een vergelijkbare constructie toe te gaan passen (waarbij, erger nog, zelfs het type van het object wijzigt).

Dit is natuurlijk allemaal mogelijk en (heel) formeel gezien misschien wel juister, maar ik betwijfel of er ook maar iemand (buiten de groep van informatiemodel-opstellers) gelukkig van zal worden.

@Sid

Het feit blijft dat er geen object (van bijvoorbeeld het type PAND) is. Als je dan dus ergens anders over praat dan is dat zo. Benoem dat ding, identificeer het. En misschien is dat ding er al, maar niet binnen de BAG. Ik krijg een slecht gevoel bij de suggestie om de definitie dan maar uit te breiden.

Ik krijg de indruk dat je redeneert vanuit het logische (relationele) BAG-model. Ik praat liever over het conceptuele model voor de informatiebehoefte van de gemeente en daarbij zijn de grenzen van submodellen zoals de BAG niet zo relevant. Misschien hebben we het hier wel over een kenmerk van een Kadastraal Object. 

Dat voorbeeld van het 'omhangen van gegevens' komt mij erg vreemd over maar ik ken de concrete gevallen niet.

In ben ervan overtuigd dat als de modellering juist is dit in de toekomst heel veel ellende voorkomt. Je laatste opmerking valt me tegen.

Ik wil toch nog even nadrukkelijk de visie van Sid onderstrepen. Je wil dat de informatie-uitwisseling zoveel mogelijk stabiel blijft.

Een pand is natuurlijk vooral een "fysiek gebouw". Maar in de BAG hebben we er voor gekozen om ook over een pand te spreken als er nog geen fysiek object is en "alleen nog maar" een bouwvergunning voor dit pand. Dat was een belangrijk winstpunt bij de invoering van de BAG.

De uitbreiding om het pand als object nog een stap eerder te kunnen uitwisselen, waar Sid ook voorstander van is, namelijk op het moment dat de vergunningaanvraag in behandeling is, lijkt mij daarbij weer een grote stap voorwaarts.

Dit onderwerp raakt natuurlijk ook nauw aan de ontwikkeling van het Digitaal Stelsel Omgevingswet (DSO). Wanneer wij nu "blokkeren" dat in de fase van behandeling vergunningsaanvraag gewerkt kan worden met StUF bg berichten, dan stimuleren wel erg duidelijk dat bij DSO StUF geen rol meer gaat spelen en dat gemeenten binnenkort voor de invoering van de Omgevingswet naast StUF ook andere uitwisselingsformaten zullen moeten gaan ondersteunen. Ik zou dat erg betreuren.

Dit is een mooie illustratie van wat er gebeurt als je niet goed modelleert. Ik vind die keuze van de BAG destijds om al van een Pand te spreken als er alleen nog maar een Besluit (bouwvergunning) is helemaal geen belangrijk winstpunt. En je ziet waar het nu toe leidt. Een Pand is een concreet ding, een Besluit is een concept, en die zijn op een hoop gegooid.

Je wilt geen Pand uitwisselen zoals Ruud zegt, maar je wilt gegevens uitwisselen. Voor mijn part breiden we het RSGB uit met die gegevenstypen, maar laten we dat dan wel goed doen. RSGB is meer dan basisgegevens en als dit kerngegevens zijn passen ze er prima in. Ook geen enkel probleem voor StUF.

Ik vind een goed informatiemodel (en daarvan afgeleide berichten) belangrijker dan een berichtformat, dat moge duidelijk zijn.

Ik sluit me van harte aan bij de laatste zin van Rindert. En derhalve bij alle argumentatie die daaraan voorafgaat.

Ik heb enkele maanden geleden in de discussie de vraag gesteld, vanuit de constatering dat 'het genoemde probleem [alleen] speelt [...] in de periode dat de vergunningaanvraag behandeld wordt': "Voor wie (welke taakvelden) is in die fase een 'voorlopige' Nummeraanduiding e.d. van belang? Zijn er zoveel belanghebbenden dat die 'voorlopige' Nummeraanduiding e.d. een kerngegeven rechtvaardigt (pas na registratie in de BAG wordt het een basisgegeven)? Oftewel, moet dit in het RSGB opgelost worden, of elders?"
In de discussie tref ik niet meer aan dan dat het relevant is voor het vergunningverleningsproces. Dan kan er geen sprake zijn van bijvoorbeeld een voorlopig huisnummer als kerngegeven. Dat huisnummer is dan niet meer dan een procesgegeven van het vergunningverleningsproces i.v.m. een BAG-beheerproces. En dat 'tacklen' we in een processpecifiek koppelvlak (i.c. het Wabo-BAG-koppelvlak).

Wat zou er gebeuren als we een dergelijk gegeven wel als kerngegeven zouden bestempelen? Dan gaat dat de hele organisatie in. Eenieder kan en mag (en moet?) er van gebruik maken. Het kan dus ook naar extern gecommuniceerd worden, in een brief oid. Terwijl dat huisnummer niet in de (landelijke) BAG voor komt. Dat leidt toch tot verwarring?

Er is blijkbaar een behoefte aan voorlopige adressen, verblijfsobjecten en panden. Die behoefte bestaat in ieder geval bij het vergunningverleningsproces. Dat is opgelost met genoemd koppelvlak. Wat hebben we dan nog niet opgelost, waar de behoefte wel te rechtvaardigen is (dus m.i. niet bij een bouwkavel)? Ruud voert aan "dat bij DSO StUF geen rol meer gaat spelen en dat gemeenten binnenkort voor de invoering van de Omgevingswet naast StUF ook andere uitwisselingsformaten zullen moeten gaan ondersteunen." Waar zou het probleem kunnen zitten? De gemeente ontvangt de aanvraag vanuit het DSO met een op die ontvangst gericht bericht (en haalt details over die aanvraag met specifieke services op). Daarin is van een voorlopig adres geen sprake, de aanvrager kan en mag dat niet zelf verzinnen. En dan? Wat is er in het DSO te zien van die aanvraag? En past een voorlopig huisnummer daarin? Zou kunnen maar is dan vergunningverlening-specifiek en laat zich toch prima oplossen in op dat proces gerichte berichten en services? Ik zie daarin geen rol van StUF-BG.
Ik blijf dus benieuwd naar de onderbouwing van de behoefte als kerngegeven.