KwetsbaarGebouw aanpassen aan BAG

PB-GNM commented 1 year ago

Aanleiding wijziging

Het gewenste proces voor het bijwerken van kwetsbare gebouwen en locaties (KGL) in het REV is niet helemaal in lijn met het IMEV.

Voorgestelde wijziging

Informatie die al in de BAG zit moet uit het IMEV gehaald worden, behalve de ID's waarmee een koppeling gelegd kan worden naar de BAG-objecten. Dat betekent verwijderen van de volgende attributen bij het object KwetsbaarGebouw:

geometrie
gebruiksdoeleinden
oppervlakte

En toevoegen:

pandidentificatie: IdentificatieBAG {0..1}
gebruiksdoeleindenInDetail: CharacterString {0..*}

Het attribuut adresseebaarObjectIdentificatie kan blijven want dat gaat over het adres en niet over het pand. Een pand kan meerdere adresseerbare objecten bevatten. De kardinaliteit moet daarom naar {0..*}. Als een kinderdagverblijf in een pand zit waar ook andere adressen in zitten wil je wel weten welk adres bij dit specifieke kwetsbare object hoort. Omdat onbekend is waar in het pand dit kinderdagverblijf zit, is ook de geometrie van het pand nodig. Die kan dan gevonden worden met het BAGPandID. Volgens de definitie van een KwetsbaarGebouw in het BKL kan het ook om een woonwagen of woonschip gaan. In dat geval is er geen sprake van een BAG-pand en daarom is de kardinaliteit {0..1}. Het attribuut "gebruiksdoeleindenInDetail" wordt toegevoegd omdat de gebruiksdoeleinden in de BAG ontoereikend zijn om de kwetsbaarheid aan te geven. Dit laatste komt voort uit helpdesk vraag SDIMEV-77.

Impactanalyse

Geef hier een indicatie van de impact van de wijziging:

Wie gaat er wat van merken? Dataleveranciers, Softwareleveranciers
Veranderen definities van objecten in de standaard zodanig dat de wijziging impact heeft op de uit te wisselen gegevens? Nee
Heeft het impact op het json-schema? Ja
Is het backwardscompatibel? Nee
X-, Y- of Z-wijziging: X

Prioriteit

hoog

Toelichting

Vooralsnog is er van uitgegaan dat de overige attributen als populatie en kadastraleAanduiding kunnen blijven bestaan, omdat deze niet uit de BAG gehaald kunnen worden. Het Objecttype KwetsbareLocatie is in dit voorstel niet aangepast, omdat deze niet duidelijk uit 1 basisregistratie komt. Het kan overeenkomen met een object uit de BRT, BGT of BKR, maar dat hoeft niet. Het kan ook een zelf getekend gebied zijn.

PeterFrans commented 1 year ago

Wanneer een aantal velden vervallen, behoeven ze ook geen verduidelijking. De scope van https://github.com/Geonovum/imev-werkomgeving/issues/85 zou hiermee kleiner worden.

PeterFrans commented 1 year ago

Het lijkt mij goed om de 'kadastraleAanduiding' te handhaven. Dit is een id (vergelijkbaar aan de 'idBAG') die gebruikt kan worden om via de geometrie van het bijbehorende perceel andere gegevens zoals bv 'adres exploitant' en 'kvkNummerExploitant' geautomatiseerd uit de Basisregistratie Kadaster (BRK) of het handelsregister (NHR) te halen.

PB-GNM commented 1 year ago

Ik dacht nog even "Wat dan in het bijzondere geval dat bv een kinderdagverblijf op een standplaats zit, of op een ligplaats (misschien niet zo veilig, maar theoretisch mogelijk)?", maar dan kan dit ook wel geregistreerd worden via een KwetsbareLocatie i.p.v. via een KwetsbaarGebouw. Dus het lijkt mij een goed voorstel 'idVerblijfsobjectBAG' te gaan gebruiken.

PeterFrans commented 1 year ago

Ik deed de aanname dat een 'kwetsbaarGebouw' een deel van de 'BAG panden' betreft. Maar de definitie van een 'kwetsbaarGebouw' is anders volgens het BKL (bijlage VI A):

A. Beperkt kwetsbare gebouwen

_Een gebouw met een van de volgende gebruiksfuncties, alleen voor zover het gaat om die gebruiksfunctie: a. een woonfunctie, met uitzondering van een woonfunctie in een woongebouw en een woonfunctie voor 24-uurszorg, als het gaat om een woonfunctie: 1°. op een locatie met een dichtheid van ten hoogste twee woningen, woonschepen of woonwagens per ha;__

Hieruit blijkt dat een 'kwetsbaarGebouw' wel degelijk een ligplaats of standplaats kan zijn. Het is dus het beste om 'idAdresseerbaarObjectBAG' te handhaven, en mijn eerdere suggestie niet door te voeren.

PeterFrans commented 1 year ago

Hoewel het in theorie mogelijk is dat een 'Kwetsbaar gebouw' (bijvoorbeeld een kinderdagverblijf) zich bevindt in een ruimte die bestaat uit twee BAG panden (zie bijvoorbeeld de relatie tussen een 'Verblijfsobject' en een 'Pand' in de BAG in de tabel hieronder):

lijkt het me in dit geval het beste om dit als twee kwetsbare locaties op te voeren. Op deze manier:

hoeft de kardinaliteit van het idPandBAG niet te worden aangepast (van [0 ..1] naar [0 ..*]);
zijn er geen implicaties voor de geometrie van het kwetsbare gebouw: deze blijft hetzelfde als de geometrie van het BAG pand (Anders zou deze in theorie kunnen bestaan uit de geometrie van twee panden samen. Dit is zou dan een andere geometrie opleveren in het REV dan de geometrie zoals deze is opgenomen in de BAG (1 geometrie per pand)). Gevolg is wel dat een 'Kwetsbaar Gebouw' niet verdeeld kan zijn over meerdere BAG panden: hiervoor zullen meerdere 'Kwetsbare Gebouwen' moeten worden opgevoerd in het REV.

PeterFrans commented 1 year ago

Bij een 'Kwetsbaar Gebouw' moet verplicht een 'idAdresseerbaarobjectBAG' en/of een 'idPandBAG' worden toegevoegd

Wanneer een kinderdagverblijf zich op een ligplaats bevindt, is er geen BAG pand, maar wel een adresseerbaar object. Wanneer een kwetsbare locatie zich in een BAG pand bevindt zonder adres, moet dit ook opgevoerd kunnen worden. Op deze manier is er altijd een bijbehorende geometrie in de BAG.

PeterFrans commented 1 year ago

Van een 'Kwetsbaar Gebouw' wordt hier voorgesteld het attribuut 'geometrie' te verwijderen uit het REV. De redenatie hierachter is dat deze geometrie al in de BAG zit en daaruit op te halen is via de API dmv het attribuut 'BAGid'.

Analoog hieraan kan hetzelfde worden voorgesteld voor het attribuut 'geometrie' van een 'Kwetsbare Locatie':

De geometrie van een 'Kwetsbare Locatie' zit al in de Basisregistratie Kadaster (BRK) in de vorm van de perceelgrenzen van een kadastraal onroerende zaak (wanneer deze hetzelfde is). Deze geometrie is uit de BRK op te halen via de API dmv het attribuut 'kadastraleAanduiding'.

Ik stel dus voor om bij een 'Kwetsbare Locatie':

ook het attribuut 'geometrie' te verwijderen (cf het voorstel voor Kwetsbaar Gebouw);
de kardinaliteit van het attribuut 'kadastraleAanduiding' aan te passen van [0 .. *] naar [1]. Op deze manier heeft een 'Kwetsbare Locatie' altijd een link naar de perceelgrenzen (geometrie). Gevolg is wel dat een 'Kwetsbare Locatie' niet verdeeld kan zijn over meerdere kadastraal onroerende zaken (percelen): hiervoor zullen meerdere 'Kwetsbare Locatie' moeten worden opgevoerd in het REV.

PB-GNM commented 1 year ago

Voor mij was nog niet duidelijk dat een KwetsbareLocatie altijd overeen komt met een kadastraal perceel, zoals je ook kan opmaken uit mijn eerdere toelichting in https://github.com/Geonovum/imev-werkomgeving/issues/92#issue-1593704089 Als dat inderdaad zo is, lijkt mij dit een goed voorstel, en denk ik dat we dat ook in de definitie moeten toevoegen of evt. in een toelichting.

Maar waaruit blijkt dat KwetsbareLocatie altijd overeen komt met een kadastraal perceel en dat je bv niet zelf een afbakening mag bedenken?

PeterFrans commented 1 year ago

Maar waaruit blijkt dat KwetsbareLocatie altijd overeen komt met een kadastraal perceel en dat je bv niet zelf een afbakening mag bedenken?

Dit is een goede en terechte vraag. Enig speurwerk heeft me tot de conclusie gebracht dat dit nergens uit blijkt. Niet doorvoeren dus.

PB-GNM commented 1 year ago

Er is een nieuw verzoek van Geodan binnen gekomen in de helpdesk (SDIMEV-77) om het mogelijk te maken extra gebruiksdoelinformatie toe te voegen bovenop de gebruiksdoelen die al in de BAG zitten.

PalmJanssen commented 1 year ago

Alle bovenstaande verzoeken leiden tot dit veranderde UML model:

KwetsbareLocatie: verwijderd: attribuut geometrie attribuut kadastraleAanduiding van 0..* naar 1
KwetsbaarGebouw: verwijderd attribuut geometrie verwijderd attribuut oppervlakte verwijderd attribuut gebruiksdoeleinden toegevoegd attribuut gebruiksdoeleindenInDetail toegevoegd attribuut pandIdentificatie

De motivatie hierachter is dat de relatie naar respectievelijk het KadastralePerceel uit BRK of het Pand in BAG de geometrie en oppervlaktegegevens leveren.

Was:

Wordt:

PalmJanssen commented 1 year ago

Een UML oplossing voor deze constructie is het gebruik van de UML indicatie 'afgeleid gegeven'. In analogie met andere IM modellen geven we met een / voor het attribuut aan dat het gegeven afgeleid is uit andere gegevens. In de toelichting van het attribuut wordt opgenomen hoe het wordt afgeleid, of waar het vandaan komt. In dit geval gaat het om gegevens uit de BAG die via de pandIdentificatie zijn op te vragen.

In het proces van aanleveren aan het REV wordt een afgeleid gegeven niet door de bronhouder aangeleverd aan het koppelvlak. Het REV genereert het afgeleid gegeven op basis van de pandIdentificatie die is meegeleverd.

Het afgeleid gegeven zit dus niet in het model (en JSON) schema voor het aanleverkoppelvlak.

Het model ziet er dan zo uit:

Met als tekst bij bijvoorbeeld '/gebruiksdoeleinden': Definitie: Het vergunde gebruiksdoel of de vergunde gebruiksdoelen zoals geregistreerd in de BAG. Toelichting: Dit gegeven wordt niet door de bronhouder aangeleverd maar wordt door het REV gegenereerd op basis van de pandIdentificatie

PB-GNM commented 1 year ago

Aanleiding wijziging

Het gewenste proces voor het bijwerken van kwetsbare gebouwen en locaties (KGL) in het REV is niet helemaal in lijn met het IMEV.

Daarnaast is het BAG-attribuut voor gebruiksdoeleinden niet specifiek genoeg. Er is behoefte aan een gedetailleerdere mogelijkheid om het gebruik aan te geven.

Voorgestelde wijziging

Was:

Wordt:

Met een / wordt aangegeven dat het attribuut afgeleid is uit andere gegevens en dat het door bronhouders dus niet hoeft worden aangeleverd. In de toelichting van het attribuut wordt opgenomen hoe het wordt afgeleid, of waar het vandaan komt. In dit geval gaat het om gegevens uit de BAG die via de pandIdentificatie zijn op te vragen.

Met als tekst bij bijvoorbeeld '/gebruiksdoeleinden': Definitie: Het vergunde gebruiksdoel of de vergunde gebruiksdoelen zoals geregistreerd in de BAG. Toelichting: Dit gegeven wordt niet door de bronhouder aangeleverd maar wordt door het REV gegenereerd op basis van de pandIdentificatie. Daarnaast wordt het attribuut “gebruiksdoeleindenDetail“ toegevoegd, omdat de gebruiksdoleinden zoals in de BAG staan niet toereikend zijn.

Impactanalyse

Geef hier een indicatie van de impact van de wijziging:

Wie gaat er wat van merken? Dataleveranciers, Softwareleveranciers
Veranderen definities van objecten in de standaard zodanig dat de wijziging impact heeft op de uit te wisselen gegevens? Nee
Heeft het impact op het json-schema? Ja
Is het backwardscompatibel? Nee
X-, Y- of Z-wijziging: X

Prioriteit

hoog

Toelichting

Vooralsnog is er van uitgegaan dat de overige attributen als populatie en kadastraleAanduiding kunnen blijven bestaan, omdat deze niet uit de BAG gehaald kunnen worden. Het Objecttype KwetsbareLocatie is in dit voorstel niet aangepast, omdat deze niet duidelijk uit 1 basisregistratie komt. Het kan overeenkomen met een object uit de BRT, BGT of BKR, maar dat hoeft niet. Het kan ook een zelf getekend gebied zijn.

JanCasSmitGeonovum commented 1 year ago

Expert overleg IMEV 16 MEI 2023, thema aansluiten op andere registraties

Voorgestelde wijziging inhoudelijk akkoord? Ja

1) Wat adviseren we de adviesgroep: doen 2) Wat is de prioriteit (hoog) 3) Klopt de beschreven impact (Ja)

PB-GNM commented 1 year ago

Voorbeeld hoe je met een WFS op de BAG de gegevens van één pand kunt opvragen voor pandidentificatie=0003100000119847: https://service.pdok.nl/lv/bag/wfs/v2_0?service=WFS&version=1.0.0&request=GetFeature&typename=pand&filter=%3CFilter+xmlns=%22http://www.opengis.net/ogc%22%3E%3CPropertyIsEqualTo%3E%3CPropertyName%3Eidentificatie%3C/PropertyName%3E%3CLiteral%3E0003100000119847%3C/Literal%3E%3C/PropertyIsEqualTo%3E%3C/Filter%3E

Of via Linked data voor een pand: https://bag.basisregistraties.overheid.nl/resource?subject=https://bag.basisregistraties.overheid.nl/bag/doc/3/pand/0003100000119847 En daarin ligt oa het verblijfsobject: https://bag.basisregistraties.overheid.nl/resource?subject=https://bag.basisregistraties.overheid.nl/bag/doc/2/verblijfsobject/0003010000133698 of https://bag.basisregistraties.overheid.nl/resource?subject=https://bag.basisregistraties.overheid.nl/bag/doc/1/ligplaats/0503020000118292

PB-GNM commented 1 year ago

Tijdens het softwareleveranciersoverleg van 7 juni is er geen bezwaar geuit tegen het doorvoeren van deze wijziging.

PB-GNM commented 9 months ago

Opgelost in versie 2.0.

Geonovum / imev-werkomgeving