BAG Adressen - pandstatus 'Bouwvergunning verleend' meenemen?

[justb4]

Deze vraag is al eerder gesteld in #300. Maar er duikt weer een nieuwe situatie op: een identiek/vol adres van zowel een bestaand als een nieuw te bouwen pand. Voorbeeld is "van Hertsbekestraat 23 4311GS Bruinisse", zie screenshots op 11 juni 2021:

Links bestaand/oud rechts nieuw/toekomstig. Twee verschillende adres-locaties. Nummeraanduiding is "uitgegeven" voor beiden. Moeten ze dan toch niet allebei meegenomen? Maar dan zijn de adressen in "Adres-Plus" weer niet uniek...

Dit n.a.v. een vraag van gebruiker.

[DFN-Marcel-Wolf]

Hier de gebruiker. Dit betreft misschien een verkeerd voorbeeld. Zojuist een collega langs gestuurd en het blijkt dat Hertsbekestraat 23 nog bewoond is. Echter op de hoek ligt Deltastraat 5 Bruinisse. De huizen in dit rijtje zijn ergens in maart gesloopt. Staat echter nog steeds in BAG dat pand in gebruik is. Nu is hier de bouw nog niet gestart dus we hebben nog ruimte voldoende de tijd maar we willen graag vroeg van tevoren weten waar er activiteiten gaan plaats vinden zodat we hier de werkvoorbereiding al voor kunnen opstarten.

[justb4]

Inmiddels ook nieuwe aandachts-adressen:

Zie Azalealaan 1 tot en met 15 in Yerseke. Panden 3 tot en met 21a worden gesloopt en 1 tot en met 15 worden nieuw gebouwd. Doordat 3 tot en met 21a nog steeds de status ‘Pand in gebruik’ heeft krijgt deze nu voorrang en zien we niet de ‘bouwvergunning verleend’ meldingen terug. Echter zijn de oude woningen al gesloopt en zijn de huisaansluitingen deels verwijderd.

Dus twee problemen hier m.i:

1) Panden met Bouwvergunning verleend status worden niet meegenomen in adres-tabellen 2) Eenzelfde adres (Openbareruimtenaam-Huisnummer-Postcode) kan meerdere keren voorkomen (meerdere Nummeraanduidingen, VBOs, Panden) bijv als een Pand een eind verderop gebouwd wordt.

ad 1) @PeeWeeOSM we zouden toch in ieder geval Bouwvergunning verleend meenemen in adres-plus? Of heb ik dat mis, is al tijd geleden. EDIT: Vergeet die opmerking 1): Bouwvergunning verleend wordt wel meegenomen. Alleen wanneer adres meerdere keren voorkomt niet, dus geval 2) hierboven...

Staat in commentaar maar in de SQL lijkt dit niet te gebeuren (zowel BAG v1 als v2). ook de pandactueelbestaand VIEW moet dan aangepast, hoewel pandactueelbestaand niet door adres-plus wordt gebruikt (lijkt het).

ad 2) is al vaker opgevoerd. Het hangt ook erg van de use-case (gebruiker) af wat de voorkeur heeft: het merendeel zal unieke adressen willen van bestaande objecten (ground-level truth). Goed om de discussie maar weer op te voeren...

[justb4]

Dit commentaar is ook nog relevant: https://github.com/nlextract/NLExtract/issues/300#issuecomment-769299440

[justb4]

Hieronder alle adressen CSV van de Azalealaan Yerseke zoals in adres-plus (BAG Adressen Woning):

azalealaan-totaal.csv

Alleen Azalealaan 1 heeft Bouwvergunning verleend status. Inderdaad zal voor bijv nummer 3 bij ontdubbelen het Pand met status Bouwvergunning verleend (pand id 0703100000167854) uitgefilterd zijn ten faveure van van Pand in gebruik (pand id 0703100000027511). Zie ook in BAGViewer

[DFN-Marcel-Wolf]

Wederom een issue met 2 statussen voor 1 adres. Betreft Swaanhilstraat 45 in Rilland. Zowel de status Pand in gebruik als Bouwvergunning verleend. De nieuwbouw is al zover dat het dak erop zit. Dus status Pand in gebruik had niet meer voor mogen komen en status Bouwvergunning verleend had eigenlijk al bouw gestart moeten zijn. Ik hoop dat het belang er nu van ingezien wordt dat beide statussen zichtbaar moeten zijn in de export.

[DFN-Marcel-Wolf]

Wederom een voorbeeld. Poortstraat 4 tot en met 18 in Serooskerke is reeds gesloopt. Adressen staan echter nog steeds met status 'Pand in gebruik' in BAG. Poortstraat 4 tot en met 10 staan ook al in BAG met status 'Bouwvergunning verleend'. Hieronder de huidige situatie. Fundering is al gestort.

@justb4 en @PeeWeeOSM. Hoeveel voorbeelden moet ik nog sturen om duidelijk te maken dat dit een issue is?

[PeeWeeOSM]

@DFN-Marcel-Wolf Ik weet niet wat je van me verwacht maar laat ik even wat context geven. Dat de BAG data niet 100% juist is is me al jaren duidelijk. Om die reden moet ik in het script nogal wat acties uitvoeren om adressen te ontdubbelen. Het primaire doel van het script is nl een tabel op te leveren waarvan adressen uniek zijn. Bij dubbele adressen maak ik dus keuzes om te komen tot 1 uniek adres. Uiteraard is dat soms arbitrair maar zoals gezegd is het doel om per adres maar 1 record te krijgen. Ik ben niet verantwoordelijk voor onjuistheden in de BAG. Als BAG data niet juist is kan er een terugmelding gedaan worden. Zie ook https://www.kadaster.nl/zakelijk/registraties/basisregistraties/bag/fout-in-bag-melden

[DFN-Marcel-Wolf]

@PeeWeeOSM , prima dat je zoveel werk verzet om de tabellen te ontdubbelen. Daar zullen heel veel mensen blij mee zijn. Aangezien de data door de gemeentes echter niet goed bijgehouden wordt missen we dingen. Deze situatie bijvoorbeeld komt alleen naar boven omdat er toevallig iemand voorbij rijdt. Dat willen we voor zijn door middel van de statussen in BAG. En wat is het probleem om als de status 'Bouw gestart', 'Bouwvergunning verleend' of 'Verbouwing pand' is deze statussen altijd toe te voegen of er nu andere statussen zijn of niet? Ik weet niet hoeveel afnemers jullie hebben maar het lijkt me sterk dat niet meer partijen tegen dit probleem aan lopen.

@justb4 , ik heb dit al eerder aangegeven. Ik lees nergens dat ik een product heb gekocht waar alleen maar unieke adressen in staan. Ik koop een dataset 'Adressen CSV - Uitgebreid". Ik zou graag een ongecensureerde versie willen hebben. Dan filter ik zelf de data wel.

[PeeWeeOSM]

@DFN-Marcel-Wolf Nog wat context. Ik ben de auteur het sql script "adres_plus" Zie ook https://github.com/nlextract/NLExtract/blob/master/bag/db/script/adres-tabel-plus.sql. Meer dan dat is mijn bijdrage aan NL-Extract niet geweest. Daar ben ik niet voor betaald net zomin als vele anderen die een bijdrage hebben geleverd. Ik heb dan ook geen klanten of afnemers oid. Een ieder mag een kopie van het script maken en er mee doen wat ie wil. Kost niets.

Bovenin dat script staat omschreven wat het doet en vind je ook de definitie die ik hanteer voor een uniek adres. Dat script levert een tabel op met "alle adressen" van NL met een groot aantal kenmerken. Zoals gezegd komt een "adres" daar maar 1x in voor. Voornaamste reden hiervoor is de volgende. De tabel kan nu worden gebruikt om eigen adresbestanden te verrijken en/of te corrigeren. Denk aan correcties van straatnamen of het geocoderen (waar ligt het op de kaart). Daarbij moet je dus je eigen data matchen met deze tabel. Als daarin een adres meer dan 1x voorkomt levert dat logischerwijs problemen op en dat wil je uiteraard voorkomen.

Het script sluit geen pandstatussen uit maar als er van een adres 2 voorkomens zijn in de BAG zal ik er 1 niet meenemen en die overweging gebeurt dan bv o.b.v. de status van de 2 panden. Ik ben nog nooit benaderd door iemand om het script aan te passen zodat van een adres meerdere voorkomens mee te nemen. Mocht dat gebeuren dan zou ik dat hoe dan ook niet doen voor dit script en antwoorden dat het script wel een goede basis zou zijn maar dat ik het niet ga doen.

Mocht je van mening zijn dat adressen (zie definitie in het script) ontbreken in de tabel adres_plus dan hou ik me aanbevolen voor feedback.

[DFN-Marcel-Wolf]

@PeeWeeOSM , ik snap dat in veel voorkomende gevallen er alleen gebruik gemaakt wordt van de adressen. Wij hebben dit bestand echter gekocht vanwege de extra velden die voor komen. Zoals 'pandstatus'. Door de manier van uniek filteren vallen sommige adressen nu onterecht weg. En dat neem ik jou niet kwalijk want ik heb geen overeenkomst met jou maar met @justb4 en nergens op www.geotoko.nl staat vermeld dat deze tabel unieke adressen bevat. Het verbaast met wel dat ik feedback moet geven als ik van mening ben dat er adressen ontbreken. Oke, ik heb inderdaad niet aangegeven dat er adressen ontbreken maar ik denk dat ik genoeg heb aangekaart dat er essentiële data ontbreekt, maar jij bekijkt het alleen vanuit het perspectief om de adressen uniek te maken. Ik heb hele andere bedoelingen met de tabel. Misschien moet je je daar eens voor openstellen. @justb4 , het blijf stil vanaf jouw kant. Hoe gaan we dit oplossen?

[wbijster]

@PeeWeeOSM, de voorbeelden die je noemt zijn inderdaad precies waar ik de unieke adressen voor gebruik (lijst unieke adressen per regio in Nederland maken en adresdata geocoderen). Mijn dank is groot! En dat doe ik dan 2 keer per jaar met de CSV downloads van @justb4 waar ik zeer tevreden mee ben. Ik heb op zich geen interesse in de dubbele adressen zoals @DFN-Marcel-Wolf aangeeft, echter als de hoeveelheid data werkbaar blijft (ik weet niet hoeveel extra rijen er zouden ontstaan) dan zou ik een lijst met niet unieke adressen ook op criteria kunnen filteren, idealiter zou er een kolom kunnen zijn die aangeeft welke rij als leidend wordt beschouwd (en tot nu toe als uniek adres werd gekozen) en welke als extra.

[justb4]

De issues hier en in #300 zijn een soort Catch-22: bij elke oplossing word je weer in de staart gebeten. Er is m.i. geen oplossing die iedereen tevreden kan stellen. Veel BAG-afnemers gebruiken dan ook de BAG PostGIS Dump, ook beschikbaar op geotoko.nl of zelf met NLExtract genereren, dus de volledige BAG in meerdere database tabellen en maken daarop hun eigen software/scripts. Of men huurt iemand in om maatwerk te maken, zelfs met NLExtract.

Ik heb de BAG weleens een Veelkoppig Monster (zie slide 20) genoemd. Ik denk dat de basis voor veel problemen de relatie, "dichotomie", tussen adressen en gebouwen/panden is. Ook vanuit afnemers gezien: voor het ene deel zijn de Panden leidend, voor het andere deel van afnemers de Adressen. Er zitten daarnaast ook ingewikkelde ontwerp-regels/veel-naar-veel relaties, ook bijv "nevenadressen", tussen objecten in de BAG. En uiteraard zit ook nog eens de complete historie in de BAG a.d.h.v. "statussen", een stuk of zes velden. Hadden ze niet gewoon beter 2 Basisregistraties kunnen maken?

Wanneer we BAG-data gaan "platslaan" in een CSV zoals voor een adres-tabel, moeten meerdere afwegingen worden gemaakt: welke status wel/niet, wat te doen bij veelvoudige relaties (ook bijv gebruiksfuncties, opgelost in meerdere kolommen), meerdere Panden aan VBO gekoppeld, wat indien geen Postcode etc etc. Ook hier is er geen "catch-all" oplossing die iedereen tevreden stelt. Bijv het meest gehoorde commentaar in de geotoko helpdesk is dat er adressen zonder postcode zijn...Ook hier: wat is leidend: de Panden of de Adressen (Nummeraanduidingen).

Ik weet in ieder geval zeker, dat als er nu dubbele adressen in de BAG Adressen CSV komen, de helpdesk "roodgloeiend" zal staan. Ik wil proberen om maatwerk te vermijden maar een opdracht uitzetten kan altijd. Ik kan mij bijvoorbeeld voorstellen dat we 2 adres-plus bestanden genereren: "Adressen Ruw" en "Adressen Geraffineerd". In de eerste zitten dan alle adressen en panden, met soms meerdere voorkomens, met of zonder postcode, met ook niet-bestaande statussen , mogelijk ook niet-actuele (historische) rijen. In "Adressen Geraffineerd" is daarover dan een filter gelegd, ahw een VIEW. Maar ook hier kan weer discussie ontstaan: neem je dan wel/niet adressen zonder postcode mee.... Er zitten natuurlijk ook weer nadelen aan: er moet steeds uitgelegd worden wat/wat is, waarom iets wel/niet in de Raffinerings-filter (Postcodes!) zit...

[PeeWeeOSM]

@DFN-Marcel-Wolf OK nog even wat meer context. Ik heb geen commercieel belang bij Geotoko en werk ook niet in opdracht van Geotoko. Ik heb de eerste versie van dit script gemaakt (lang voordat Geotoko ontstond ) omdat ik daar zelf behoefte aan had en het vervolgens belangeloos beschikbaar gesteld aan NL-Extract (deze Github dus). Het script maakt een tabel genaamd "ADRES_PLUS". Als daar fouten in zitten obv wat de bedoeling van de tabel was dan is het gebruikelijk dat er feedback gegeven wordt bv door het aanmaken van een issue op github. In dat geval ga ik er naar kijken. Tot op heden heb ik niet gezien dat dit het geval was. Jij hebt bij Geotoko een tabel afgenomen die waarschijnlijk is afgeleid van ADRES_PLUS. Het lijkt erop dat jouw behoefte hier niet volledig mee wordt afgedekt. Dat is jammer maar voor mij geen reden het script en daarmee ADRES_PLUS aan te passen. De reden daarvoor heb ik eerder gegeven. Dat heeft helemaal niets te maken met "me openstellen" maar is een gevolg van conflicteren van belangen. Onze beiden wensen zijn niet verenigbaar.

Ik kan me voorstellen dat je het script niet bekeken hebt want het is nogal lang en SQL en BAG kennis is niet bij iedereen aanwezig. Maar ik kan je vertellen dat ik niet op het eind pas ga ontdubbelen maar al in blok 1 (van de 5 blokken). Het is dus niet zo dat ik op het eind een aantal adressen verwijder. Dat ontdubbelen moet aan het begin omdat ik bv obv geometrie van panden tov andere panden ga vaststellen welk type pand het is.(hoekwoning,tussenwoning etc) . En dat dan alleen nog maar voor adressen met een Woonfunctie. Als ik dan 2 panden op elkaar heb liggen omdat er meerdere pandstatussen/woonfuncties zijn dan gaat die afleiding helemaal verkeerd. En vergis je niet in het aantal fouten dat er in de BAG zat (en waarschijnlijk nog steeds zit). Als ik dubbele adressen zou laten staan ga je waarschijnlijk tegen adressen aanlopen die voor jou volledig onterecht in het bestand staan. Dan beland je van de regen in de drup.

@wbijster Fijn dat je zeer tevreden bent met de Geotoko geleverde data. Ik begrijp je voorstel maar ik heb hierboven hopelijk voldoende uitgelegd dat het niet heel eenvoudig is.

Ik heb het vermoeden dat hetgeen @DFN-Marcel-Wolf wil hebben wellicht wel uit de BAG te halen is maar dat is heel cru gezegd niet mijn probleem. En zoals gezegd sluit ik zeker niet uit dat het resultaat dan weer gevallen voor gaan komen waarvan hij terecht zegt dat het niet klopt. Daar ga ik uiteraard niet aan beginnen.

@justb4 Ik begrijp je toelichting. Een ieder heeft zijn eigen behoefte. Dat is helaas niet altijd verenigbaar en door de complexiteit en onjuistheid ook nooit op te lossen. Als de BAG eenvoudig en perfect zou zijn was ik niet honderden uren bezig geweest met het script. En zoals zo vaak … the devil is in the details.

[DFN-Marcel-Wolf]

@justb4 , ik sta open voor een 'adressen ruw' bestand. Het bestand 'adressen geraffineerd' zou dan het huidige bestand kunnen zijn. @PeeWeeOSM , ik wist tot voor kort niet wat jou rol was binnen het geheel. Aangezien @justb4 je weleens noemde heb ik je meegenomen. Nee, ik heb niet je script bekeken. Ik wist geeneens af van een script. Ik koop een kant en klaar product. Althans dat was mij idee. Eigenlijk begint heel de ellende bij de gemeente. Als zij sneller zijn met vernieuwen van de data hadden we heel dit gesprek niet.