Niet meer bestaande/opgeheven adressen in adres-plus meenemen?

[justb4]

Gerelateerd aan #300, maar even nieuw issue om het overzichtelijk te houden.

Er liggen verzoeken om ook "historische" adressen (Nummeraanduidingen, NUM) mee te nemen. Voorbeelden:

NUM=0275200000115000: 
Zwarteweg 25 Rheden is nu NUM=0275200000166250

Hier is gewoon een nieuw adres, mogelijk ook VBO en PND. Via #300 en #288 en PRs in huidige NLExtract versie zou adres dan wel in adres_plus tabel zitten maar met nieuwe NUM. Alleen dan is er een dubbel adres in de in #300 opgestelde definitie.

Gaat vooral om dit soort adressen:

NUM=0275200000105022: Merelstraat 28 Rheden is geheel vervallen 
NUM=0202200000332766: Rhederoordlaan 2H Arnhem is geheel vervallen

Voor alledrie de gevallen vermeldt de BAGViewer dat het Adres 'historisch' is.

Wat we zouden kunnen doen is deze adressen wel in adres_plus opnemen met een extra Boolean kolom 'historisch'.
In ieder geval de laatste twee gevallen. Eerste is twijfelachtig want zou weer dubbelingen betekenen.

Ook @PeeWeeOSM.

[PeeWeeOSM]

@justb4
Even eerste gedachten hierover. Ik snap dat er mensen zijn die behoefte hebben aan "adressen" die niet meer/nog niet bestaan. Dat druist uiteraard in tegen het uitgangspunt van adres-plus. Zie definities. Adres-plus gaat obv de definities verder om met die adressen bv type huis af te leiden. Dat gaat lastig worden als we ook historische adressen meenemen. Wat als bv een hoekhuis is afgebroken (en niet meer bestaat) waardoor het naast gelegen huis een hoekhuis geworden is? Dat lijkt me zo goed als ondoenlijk om in adres plus te verwerken. Ik voel meer voor een aanvullende tabel met adressen (unieke postcode-huisnummer-huisletter-huisnummertoevoeging-openbareruimte_id) ongeacht status NUM, VBO,STA,LIG en die dan helemaal ontdubbelen. Dat dan wel zonder gegevens over type huis etc. Zal best een klusje zijn maar misschien wel te doen. En dan in die tabel aangeven of het adres wel/niet voorkomt in adres_plus. Even eerste gedachten dus misschien nog ff laten bezinken.

[justb4]

@PeeWeeOSM ja kan mij hier eigenlijk ook wel in vinden. Punt is dat de BAG, en dus afgeleide adressen, voor iedere afnemer een andere toepassing heeft, waarbij een heel klein deel niet met de standaard filtering uit de voeten kan. Denk dat voor die niche de gehele BAG (in PostGIS) met alle historie de beste optie is: daaruit dan eigen selecties, of maatwerk laten maken. Laten we eerst maar de huidige adres_plus en daarvan afgeleid adres en adres-full "inweken". Ik sluit deze issue.

[justb4]

We gaan toch weer heropenen @PeeWeeOSM heeft script in de maak....

[PeeWeeOSM]

@justb4 Ik heb een nieuw bestand voorgesteld : adres-tabel-totaal.sql. Hier een toelichting die ook te vinden is als commentaar bovenaan in het script.

Resultaat van dit script is de tabel "adres_totaal"

Het script bevat alle "adressen" van de adres_plus tabel aangevuld met alle adressen uit de BAG die ooit "bestaan" hebben of nog moeten worden gerealiseerd.
Onder een adres wordt verstaan de unieke combinatie van: openbareruimte_id, postcode, huisnummer, huisletter, huisnummertoevoeging
Een adres wordt pas beschouwd als er gerelateerde records zijn in de tabel nummeraanduiding, adresseerbaarobject (VBO,STA,LIG), openbare ruimte, woonplaats, gemeente
Van zo'n adres is maar 1 voorkomen aanwezig in deze tabel.

Hier zitten dan ook adressen tussen waarvan de status van het verblijfsobject "Niet gerealiseerd verblijfsobject" of "Verblijfsobject ingetrokken" kunnen zijn.
Dus adressen die bestaan, hebben bestaan, foutief ingevoerd of wellicht nog gerealiseerd moeten worden maar nooit dubbele adressen.

Het betreft een aanvulling op adres_plus in de zin dat het meer records zijn. Alle records van adres_plus krijgen als kenmerk "actueel" voor het attribuut "adres_status".
Alle adressen die niet voorkomen in adres_plus hebben hiervoor het kenmerk "historisch of toekomstig".

Het aantal attributen van adres_totaal is minder dan van adres_plus omdat bv type huis niet af te leiden is als alle historische/toekomstige data meegenomen wordt.