Closed PB-GNM closed 9 months 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.
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.
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.
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.
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:
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.
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':
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?
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.
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.
Alle bovenstaande verzoeken leiden tot dit veranderde UML model:
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:
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
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.
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.
Geef hier een indicatie van de impact van de wijziging:
hoog
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.
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)
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
Tijdens het softwareleveranciersoverleg van 7 juni is er geen bezwaar geuit tegen het doorvoeren van deze wijziging.
Opgelost in versie 2.0.
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.![image](https://user-images.githubusercontent.com/80040145/220386405-9b24e2d1-8beb-4f88-969e-57d03af34339.png)
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:
En toevoegen:
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:
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.