adressen dubbel in BAGEXTRACT
Peter van Gastel
Just van den Broecke
Kun je specifieker zijn? i.e.
- waar heb je adressen uit geselecteerd, welke query?
uit: tabel, view, CSV, ?
- "actueel" of "actueelbestaand"?
- data: welke BAG datum (jaar, maand)?
- "Eindhoven" woonplaats of gemeente?
- etc
NLExtract-BAG (heet niet "BAGEXTRACT") is afhankelijk van BAG data zoals
aangeleverd door Kadaster/PDOK, die weer afhankelijk is van gemeenten.
Met vriendelijke groet,
--Just
> --
> Dit is een bericht van de Google Groups "nlextract" group.
> Home pagina: http://www.nlextract.nl
> Groep mailen: nlex...@googlegroups.com
> Afmelden: nlextract+...@googlegroups.com
> Meer opties: http://groups.google.com/group/nlextract?hl=en
>
> ---
> Je hebt dit bericht ontvangen omdat je bent geabonneerd op de groep
> "nlextract" van Google Discussiegroepen.
> Als je je wilt afmelden bij deze groep en geen e-mails van de groep meer
> wilt ontvangen, stuur je een e-mail naar
> nlextract+...@googlegroups.com
> <mailto:nlextract+...@googlegroups.com>.
> Ga naar https://groups.google.com/d/optout voor meer opties.
Peter van Gastel
Op maandag 18 december 2017 09:45:20 UTC+1 schreef Just van den Broecke:
Pee Wee
Groet
Peter
Op woensdag 20 december 2017 17:31:25 UTC+1 schreef Peter van Gastel:
Peter van Gastel
Op zondag 17 december 2017 21:57:18 UTC+1 schreef Peter van Gastel:
Just van den Broecke
Inderdaad: proef op actuele BAG CSV, bijv Kloosterdreef 34 Eindhoven,
geeft 2 VBO's : 772010001061368 en 772010000801387:
$ grep Kloosterdreef bagadres.csv | grep Eindhoven | grep ';34;'
Kloosterdreef;34;;;5622AA;Eindhoven;Eindhoven;Noord-Brabant;772010001061368;VBO;f;160783.345;385190.017;5.47040965030766;51.4557589717701
Kloosterdreef;34;;;5622AA;Eindhoven;Eindhoven;Noord-Brabant;772010000801387;VBO;f;160783.561;385186.509;5.47041270031131;51.4557274373327
dus 2 VBO's op 1 adres.
op NLExtract BAG database dec 2017:
SELECT
"gid","identificatie","aanduidingrecordinactief","aanduidingrecordcorrectie","officieel","inonderzoek","documentnummer","documentdatum","hoofdadres","verblijfsobjectstatus","oppervlakteverblijfsobject","begindatumtijdvakgeldigheid","einddatumtijdvakgeldigheid"
FROM "bagactueel"."verblijfsobjectactueelbestaand" WHERE "identificatie"
= '772010001061368' or "identificatie" = '772010000801387'
geeft 2 records:
772010000801387 met "verblijfsobjectstatus": "Verblijfsobject in
gebruik" en bij 772010001061368 "Verblijfsobject gevormd"
De definitie in NLExtract-BAG van de VIEW
"verblijfsobjectactueelbestaand" is (Zie
https://github.com/nlextract/NLExtract/blob/master/bag/db/script/bag-view-actueel-bestaand.sql#L272):
SELECT verblijfsobject.gid, verblijfsobject.identificatie,
verblijfsobject.aanduidingrecordinactief,
verblijfsobject.aanduidingrecordcorrectie, verblijfsobject.officieel,
verblijfsobject.inonderzoek, verblijfsobject.documentnummer,
verblijfsobject.documentdatum, verblijfsobject.hoofdadres,
verblijfsobject.verblijfsobjectstatus,
verblijfsobject.oppervlakteverblijfsobject,
verblijfsobject.begindatumtijdvakgeldigheid,
verblijfsobject.einddatumtijdvakgeldigheid, verblijfsobject.geopunt,
verblijfsobject.geovlak
FROM verblijfsobject
WHERE verblijfsobject.begindatumtijdvakgeldigheid <=
'now'::text::timestamp without time zone AND
(verblijfsobject.einddatumtijdvakgeldigheid IS NULL OR
verblijfsobject.einddatumtijdvakgeldigheid >= 'now'::text::timestamp
without time zone) AND verblijfsobject.aanduidingrecordinactief = false
AND (verblijfsobject.geom_valid IS NULL OR verblijfsobject.geom_valid =
true) AND verblijfsobject.verblijfsobjectstatus <> 'Niet gerealiseerd
verblijfsobject'::verblijfsobjectstatus AND
verblijfsobject.verblijfsobjectstatus <> 'Verblijfsobject
ingetrokken'::verblijfsobjectstatus;
Dus de status "Verblijfsobject gevormd" wordt niet meegenomen in de
verblijfsobjectactueelbestaand VIEW, dus niet uitgefilterd en komt dus
terecht in CSV.
Mogelijk ook andere VBO-statussen hierbij van belang, zie ook:
https://www.amsterdam.nl/stelselpedia/bag-index/catalogus-bag/status/
Kun je een issue hiervoor openen via
https://github.com/nlextract/NLExtract/issues met copy/paste deze mails?
Bedankt,
Met vriendelijke groet,
--Just
On 20-12-17 17:31, Peter van Gastel wrote:
> Hoi Just,
>
> Ik heb van https://data.nlextract.nl/bag/csv/oud/ het
> > Afmelden: nlextract+...@googlegroups.com <javascript:>
> > Meer opties: http://groups.google.com/group/nlextract?hl=en
> >
> > ---
> > Je hebt dit bericht ontvangen omdat je bent geabonneerd op de groep
> > "nlextract" van Google Discussiegroepen.
> > Als je je wilt afmelden bij deze groep en geen e-mails van de
> groep meer
> > wilt ontvangen, stuur je een e-mail naar
> > <mailto:nlextract+...@googlegroups.com <javascript:>>.
Pee Wee
Hoi Peter
Ik hoop dat jet lukt met deze link. Anders even zoeken met de zoekfunctie van dit forum.
https://groups.google.com/forum/embed/?parenturl=http%3A%2F%2Fwww.nlextract.nl%2Fissues&service=jotspot&ul=1&theme=default&place=forum%2Fnlextract&showpopout=true#!topic/nlextract/DKc8j80UFYI
Groet
Peter
Op woensdag 20 december 2017 22:47:11 UTC+1 schreef Peter van Gastel:
Pee Wee
Groet
Peter
Op donderdag 21 december 2017 01:16:34 UTC+1 schreef Just van den Broecke:
Just van den Broecke
eerder een issue [2] was waarbij uiteindelijk "Verblijfsobject gevormd"
meegenomen wordt, omdat er anders adressen ontbraken. De redenaties kun
je volgen op [2]...
Hoe verder? Alleen bij dubbele adressen "Verblijfsobject gevormd"
uitfilteren? Ik weet 't ff niet, kan gebeuren :-).
[1]
https://github.com/nlextract/NLExtract/blob/master/bag/db/script/bag-view-actueel-bestaand.sql#L294
[2] https://github.com/nlextract/NLExtract/issues/173
Just
Pee Wee
Dank voor de toelichting Just.
Bij nader inzien misschien toch niet verstandig om VBO status "Verblijfsobject gevormd" uit te sluiten. Welke records opgenomen worden in een adreslijst hangt uiteraard ook af van het doel van de adreslijst . NL-extract heeft bv de keuze gemaakt om alleen adressen met een postcode te laten zien. Om die reden heb ik ooit een eigen sql script gemaakt (met NL-extract sql als basis) die adressen zonder postcode wel meeneemt. En verder hangt het (zoals in dit geval) van de definitie af van wat je als actueelbestaand ziet en of je vindt dat dit voor alle entiteiten (NAD, VBO, LIG, STA, PND , OBR ) moet gelden. Daarnaast heb je met bron vervuiling te maken die niet altijd op te lossen is.
N.a.v. de melding van Peter van Gastel (handig 2 Peters in 1 post ;) ) ben ik nog even in de adres_full tabel gedoken van de laatste postgis dump. Daar zitten inderdaad ook echt dubbele records in. Alle kolommen zijn identiek (behalve de gid).
De volgende query levert alle records op die een nummeraanduiding hebben die meer dan 1x voorkomt in de tabel. Dat lijkt mij niet logisch.
Select a.* FROM bagactueel.adres_full A
inner join
(
Select count(*), nummeraanduiding FROM bagactueel.adres_full
group by nummeraanduiding
having count(*) > 1
) B on A.nummeraanduiding = b.nummeraanduiding
order by a.nummeraanduiding;
Als we het eens zijn dat dit een issue is wil ik nog wel een keer een issue aanmaken ;) (en uitzoeken hoe dat komt.) In mijn eigen gemaakte adres tabel komt dit niet voor nl.
Eén van de doelen van mijn eigen adreslijst was om deze aan te kunnen houden tegen adressen in klantbestanden van mijn werkgever om bv foute adressen op te sporen. Daarbij wilde ik ook rekening houden met het “iets achter lopen “ van de BAG (of mijn afslag daarvan) en dus ook statussen meenemen die later zouden kunnen leiden toch een “echt adres”. (bv "Verblijfsobject gevormd" ) Verder wilde ik voor de volledigheid ook adressen zonder postcode.
In de bijlage heb ik een overzicht gemaakt van de voorkomende statussen van NAD, VBO, LIG,STA en PND. De groene statussen zijn geldig voor de definitie actueelbestaand en zijn zo ook door de huidige views gebruikt. Lijkt mij prima al zouden we VBO status “verblijfsobject buiten gebruik” wellicht moeten uitsluiten wat is jullie idee?) .
Hieronder een poging te komen tot een definitie van wanneer een adres in de tabel zou moeten komen:
1. Een NAD komt maximaal 1x voor in de lijst.
2. Een NAD komt alleen voor als zowel de NAD als de gerelateerd VBO,LIG,STA voorkomen in de actueelbestaand views.
3. Er worden dus geen VBO’s uitgesloten wegens het ontbreken van een gerelateerd pand in de actueelbestaand view van het pand. Als er pandgegevens opgenomen worden in de adrestabel dan kunnen we de actueel view pakken waarbij de status van het pand wordt weergegeven in de tabel.
Een gevolg van deze definitie is dat er in de adrestabel combinaties van postcode, huisnummer, huisletter, huisnummertoevoeging (PCHNHLTV)zullen zijn die niet uniek zijn. In adres_full zijn dat nog 62570 records. Voor een groot deel veroorzaakt doordat nummeraanduidingen meer dan 1x voor komen. In mijn tabel komt het nog 18996x voor. Die hebben echter wel allen een unieke nummeraanduiding. We kunnen dit accepteren als een fout in de bron of we wagen nog een poging deze op te schonen door de volgende actie.
Als een PCHNHLTV 2x voorkomt waarvan 1x met VBO status "Verblijfsobject gevormd" verwijder dan dat record. In dat geval hou ik van de 18996 records nog maar 2974 records over. Wellicht is dat ook nog te reduceren. Ik zoek nog ff verder.
Is dit werkbaar?
Peter van Gastel
Het gaat in bijna alle gevallen om sloop en nieuwbouw.
In de BAG wordt het nummer pas ingetrokken als de sloop voltooid is. Voor die sloop wordt in de meeste gevallen al een omgevingsvergunning voor nieuwbouw afgegeven en stellen we voor diezelfde locatie al nieuwe nummers vast. Vaak wordt dat hetzelfde nummer als in het te slopen pand. In dat geval komt het nummer 2 keer voor.
Dus bijvoorbeeld je wilt jouw huis slopen en op dezelfde plek nieuwbouw plaatsen. Je krijgt een vergunning voor de nieuwbouw, wij stellen het nieuwe huisnummer vast, en dat wordt dan hetzelfde huisnummer. Maar het oude pand staat er nog. Dan komt het huisnummer even 2x voor(meestal oud pand met status “sloopvergunning afgegeven”, en nieuw pand met status “vergunning verleend”). Pas als het oude pand volledig is gesloopt wordt het oude nummer ingetrokken.
----
Pee Wee
Hoi Peter
Ik denk dat
het manco van het huidige adresbestand is dat er per combinatie van openbareruimte
(=straat) id, postcode, huisnummer,
huisletter, huisnummertoevoeging meerdere records zijn. Dat zou denk ik niet
moeten kunnen zodat filteren obv van een pandstatus of verblijfsobjectstatus niet nodig is. Ik heb mijn eigen script aangepast zodat dit niet meer voorkomt.
In deze link https://1drv.ms/u/s!AvPAszrzDmdOmmZg0_z95qdTG7pF (ik hoop dat het werkt) vind je de adressen van Eindhoven. Ik hoop dat dit is wat je
zoekt. Zo niet laat maar weten wat je anders zou willen. Hieronder nog een toelichting
op wat ik heb gedaan en wat mijn uitgangspunten waren.
Groet
Peter
Conventies:
1 Het betreft adressen met en zonder postcode.
2 Doel is dat een adres uniek is volgens de volgende definitie. :
De combinatie van openbareruimte_id, postcode, huisnummer, huisletter, huisnummertoevoeging is uniek. In eerste instantie zijn deze niet uniek. Door een aantal sequentiele statements wordt er ontdubbeld waardoor de adres tabel alleen unieke records heeft.
3 Omdat BAG historisch is en we eigenlijk alleen de "actuele" gegevens willen zien moeten we besluiten onder welke condities een adres als "actueel" wordt gezien.
De hier gehanteerde definitie is dat een adresrecord actueel is als er een gerelateerd record is in de "actueelbestaand" view van de volgende 2 combinaties van tabellen:
A Woonplaats EN Openbareruimte EN Nummeraanduiding EN (Verblijfsobject OF Standplaats OF Ligplaats )
B Woonplaats EN Openbareruimte EN Nummeraanduiding EN adresseerbaarobjectnevenadres EN (Verblijfsobject OF Standplaats OF Ligplaats )
De adres tabel vertoond veel gelijkenis met de adres_full van NL extract. De voornaamste verschillen zijn:
1 Er zitten adressen is zonder
postcode bv sommige garages)
2 Een nummeraanduiding id komt slechts 1x voor (vermoedelijk was dat bij adres_full ook bedoeling)
3 De combinatie van postcode, huisnummer, huisletter, huisnummertoevoeging ,openbareruimte_id is uniek. (uniq_key) (NB de openbare ruimte_id is nodig voor adressen zonder postcode maar ook een aantal adressen met Postcode maakt het nog niet uniek.
voorbeeld: 7572BP 8. komt voor met OBR_id "173300000124785" en "173300000125027")
4 Van ieder adres is aangegeven of de combinatie van Postcode/huisnummer uniek is.
5 Van ieder adres is aangegeven of de combinatie van Postcode/huisnummer/huisletter/huisnummertoevoegin uniek is.
6 Voor iedere gebruiksdoel is een kolom met een waarde 1 of null die aangeeft of het van toepassing is.
7 Indien het "adres" toe te wijzen is aan 1 pand met een woonfunctie dan wordt het woontype aangegeven (Hoekhuis, 2onder1kap, vrijstaande woning etc. )
8 Per openbareruimte ID, postcode en huisnummer wordt een rangorde bepaald. Deze is nodig om een view te kunnen maken waarbij per postcode/huisnummer combinatie het "belangrijkste" adres vast te stellen is.
Dit laatste is weer nodig om te koppelen met externe adrestabellen die geen BAG conventie aanhouden (postcode, huisnummer, huisletter, huisnummertoevoeging) en veelal wel te koppelen zijn op alleen postcode/huisnummer.
Mijn ervaring is dat externe adrestabellen vaak wel een huisnummertoeving hebben maar dat deze van dermate slechte kwaliteit is dat ook dat niet te gebruiken is.