BAG Adressen niet te vinden in bagviewer

Datasets BAG
#1

Hoi,

Wij hebben een website waar mensen hun postcode en huisnummer kunnen invullen om gegevens van een analyse op te vragen.

We houden bij welke adressen er niet gevonden worden. De adressen komen uit de BAG. De lijst met niet gevonden adressen controleer ik zo nu en dan met https://bagviewer.kadaster.nl/. Nu valt het mij op dat er relatief veel postcode-huisnumer combinaties worden ingevuld die ongeldig zijn. Postcode klopt bijvoorbeeld wel, maar het huisnummer niet.

Tot nu toe dacht ik dat het aan de gebruikers lag. Maar ik begin me nu toch af te vragen of de oorzaak niet in de bag zit.

Kan het voorkomen dat een postcode en huisnummer wel bestaan, maar niet in de BAG (en bagviewer) voorkomen?

#2

Zijn die combinaties wel in “andere” (onofficiele) bronnen terug te vinden? Zoals bij postnl?

#3

Goeie! Ik heb een steekproef gedaan. Ook daar komen ze niet voor. Lijkt er toch op dat mensen niet zo goed op de hoogte zijn van hun postcode en huisnummer.

#4

Op welke wijze controleer je die adressen? Niet alle BAG-raadpleeg-endpoints geven alle adressen weer. Als je bijvoorbeeld de WFS zou gebruiken, kun je neven-adressen en dergelijke missen.

En zijn het meerendeel misschien adressen met dingen als huisletters, toevoegingen en zo? Kan ook nog een en ander misgaan. Nog afgezien van typefouten…

Bovendien merk ik dat er ondanks de BAG toch nog steeds aardig wat schaduw-adresregistraties bestaan. COllega’s die bij hoog en laag bezweren dat een adres bestaat, omdat de energieleverancier het zo heeft doorgegeven bijvoorbeeld… zelf een tweede brievenbus neerzetten, een A-tje achter het nummer plakken: Maar de postbode bezorgt daar al jaren de post! En als ik dan onze administratie confronteer met de BAG is men verbaasd dat ik vraag hoe ze aan dat adres komen.
Zomaar twee voorbeeldjes…

#5

Inmiddels ruime ervaring met het fenomeen “Ontbrekende Adressen in BAG”. Ik kan alleen zeggen, dat daar niet 1 reden voor is. De BAGViewer zou leidend moeten zijn, neem aan met dagelijkse mutaties ververst (?). Bijna elk ander (ETL) product dat ik heb gezien dat BAG verwerkt, ook NLExtract, mist (aanvankelijk) adressen, o.a. door:

  • niet meenemen “Nevenadressen” (boven genoemd), misten ook (vroeger?) in PDOK BAG WFS, Torentje is goed voorbeeld om te checken.
  • adressen zonder Postcode worden weggelaten (maar bestaan gewoon en zijn geldig in BAG)
  • Pand of VBO status is “Niet bestaand”, bijv “Bouwvergunning verleend” terwijl Pand fysiek al bestaat
  • een VBO dat gekoppeld is aan meerdere Panden kan sommige software zich in verslikken
  • Postbus adressen zitten sowieso niet in BAG
  • Pand wordt afgebroken en op andere locatie gebouwd, met zelfde adres
  • versie van de BAG (bijv maandelijkse dump) is niet actueel, inmiddels status-veranderingen
  • niet meenemen huisletter, huisnummertoevoeging
  • soms is Woonplaats direct gekoppeld aan Nummeraanduiding (ipv via Openbareruimte), zie NLExtract DB Schema. ==> Adres dan in verkeerde Woonplaats.

Een die een klant aandiende was nog geheimzinniger: een lijst Postcodes/adressen die niet in BAGViewer vindbaar zijn, wel bijv via zoekmachines. Ik vermoed geheime adressen (?)…Ga ik hier niet delen.

Binnen het NLExtract project en gerelateerde outlet geotoko.nl, proberen we zo volledig mogelijk te zijn, maar “wat is een adres?” wordt een soms bijna filosofische discussie. Hangt ook sterk van de toepassing af. Bijv een leverancier van, zeg glasvezel, wil ook adressen van huizen in niet-bestaande (“Bouwvergunning verleend”) status. Historici willen ook adressen waarvan “Pand gesloopt”…

Zie ook deze, soms nog steeds “open”, issues:

#6

Ik heb een hele lijst van Verblijfsobjecten die in gebruik zijn, die wel te vinden zijn via een lookup via het VBO id maar niet via de suggest service.

Zo is Waterhoenstraat 14 in Aalsmeer wel te vinden via

BAG Viewer maar niet via
BAG Viewer

Ook niet via suggest service van het pdok (https://geodata.nationaalgeoregister.nl/locatieserver/v3/suggest?q=1431VZ) en ook niet via het WOZwaardeloket.

#7

Interessant, de Postcode 1431VZ zou 12 Panden/Adressen moeten beslaan: Waterhoenstraat 6-28 even, inclusief 14. Die vind ik ook allen in NLExtract adressen terug en BAGViewer, reguliere search. Alle betrokken objecten (VBOs etc) zijn ook niet recent gewijzigd.

Denk hier meer een kwestie in de achterliggende zoekmachine(s), bijv Elastic oid waarbij “suggest-achtige-queries” niet optimaal resolved worden. Een object id, volgt denk ik ander zoekpad, bijv table lookup (heb ooit aan eerste versie BAGViewer gewerkt, plm 2012…). Dacht eerst nog omdat “14” ook eerste twee cijfers Postcode zijn, maar vind ik in andere gevallen niet…

#8

Lijkt in de koppeling VBO-Pand te zitten voor de Waterhoenstraat 8 en 14 in Aalsmeer (nummer 8 heeft hetzelfde probleem).
Als ik de pand-info ophaal voor die beide panden, dan hebben ze een aantal_verblijfsobjecten van 0 (uit de getFeatureInfo van de BAG WMS). Ook geen gebruiksdoel of oppervlakte_min oppervlakte_max (de beide oppervlaktes komen uit de gekoppelde VBO’s).
de rdf_see_also link geeft wel een VBO, maar als dan doorklikt daar naar toe, dan is het antwoord 404 -no results found.

Pand 14: http://bag.basisregistraties.overheid.nl/bag/id/pand/0358100019902617
Heeft daar wel een url naar een vbo:
http://bag.basisregistraties.overheid.nl/bag/id/verblijfsobject/0358010018958837

Maar die geeft
{
“title” : “No results found”,
“status” : 404
}

Er is dus meer aan de hand dan alleen zoekmachines die niet correct indexeren of zo, het lijkt al in de BAG zelf niet lekker te zitten.

#9

Dan snap ik het ook niet. Ik had mijn eerdere antwoord op BAG 8 jan 2022 gebaseerd, maar ook in de versie van 8 feb 2022 zie ik geen probleem in de BAG bron zelf. We genereren bijv mbv NLExtract Adres Plus SQL een uitgebreide adressen-CSV voor
heel NL. Als er een koppeling VBO-PND zou ontbreken zou dat meteen effect hebben. Maar alles ziet er keurig uit. Aangehecht de CSV voor postcode 1431VZ. Zie PDF (edit: alleen relevante kolommen):

waterhoenstr-1431VZ.pdf (33,4 KB)

#10

Die PDF kan ik niet goed lezen, op mijn scherm zijn de letters zo klein dat ze vervormd raken, ook als ik inzoom…

Het is inderdaad een hele rare. Als ik in de BAG Viewer zoek op Waterhoenstraat 8 Aalsmeer, vind ie niks.
Als je alleen op Waterhoenstraat Aalsmeer zoekt, en dan rechts “Toon bijbehorende adressen” aanklikt, staan daar de nummers 8 en 14 wel tussen!

DUs wat daar mis gaat durf ik ook niet te zeggen, ik kijk ook alleen maar via de BAG Viewer of via de WMS/WFS, dus daar zit toch al het een en ander in. Misschioen dat via de API meer duidelijk word?
't blijft raar…

#11

Ja er zitten heel veel kolommen in :slight_smile: , veel weggehaald, nieuwe versie PDF hierboven.
Denk dat er beter “van binnenuit”, bij PDOK, gekeken kan worden.

#12

Ah ja, dat ziet er inderdaad heel compleet uit. Heel vreemd.

Eens. Wij kunnen hoogstens een melding doen. Ik vind het alleen altijd wel leuk puzzelwerk :wink:
(voor als ik weer eens zit te wachten op een ETL-proces van anderhalf uur…)

#13

Ik denk dat je de LV-BAG bedoelt, of is er iets waar PDOK specifiek naar moet kijken?

En is er al een terugmelding gedaan via de BAG terugmeldvoorziening?

#14

Melding, moet eigenlijk in BAGViewer bedenk ik…@Risingblue jij hebt blijkbaar een hele lijst, kan jij in BAGViewer Terugmelding(en) doen? Wijst zichzelf, ga naar adres en ergens is dan terugmeld-knop. @sbjager en ik hebben hier al tijd aan uitzoekwerk besteed.

#15

Goede tip! Ik ga de terugmelding doen. Ik haal op dagdagelijkse basis BAG2.0 API data op met eXtractor.ONE en bij een match met WOZ waarden kwamen er een stel adressen op de uitvallijst terecht.

#16

Dit topic vraagt om een reactie vanuit de BAG. Bij deze.

Met de waterhoenstraat 8 is inderdaad iets bijzonders aan de hand.

Het adres maakt onderdeel uit van de BAG registratie en is ook opgenomen in de LV BAG. Het adres is daarmee gewoon op te vragen via de producten die rechtstreeks vanuit de LV BAG worden geleverd. @Risingblue: het is in dit geval ook niet nodig een terugmelding te doen. De gemeente heeft het adres goed geregistreerd.

Het adres ontbreekt echter wel in de services die we via PDOK aanbieden. Oorzaak hiervan is een bug in de interne doorlevering van de BAG gegevens van de BAG database naar de PDOK database. We zijn aan het onderzoeken wat er verkeerd gaat, en gaan dit zo snel mogelijk herstellen. Het lijkt erop dat er specifieke objecten zijn waarin correcties in de levenscyclus zijn doorgevoerd ten onrechte niet als huidig worden gezien.
@Risingblue: het zou fijn zijn als we de lijst met ontbrekende objecten kunnen ontvangen. Dat helpt ons bij het analyseren van het probleem.

Dat het adres in sommige gevallen wel of niet gevonden wordt in de BAG viewer komt doordat de BAG viewer Ă©n services gebruikt die via PDOK worden gepubliceerd (locatieserver/WFS) Ă©n gebruik maakt van de BAG API waarmee de LV BAG rechtstreeks bevraagd wordt.
De standaardzoekfunctie (linksboven) maakt gebruik van de locatieserver van PDOK.
De zoekfunctie uitgebreid zoeken en het tonen van de adressen die zijn gekoppeld aan een openbare ruimte werkt op de BAG database.

Er komt dit jaar een nieuwe versie van de BAG viewer. Hierbij is het de bedoeling dat we de onderliggende services beter op elkaar afstemmen zodat verwarrende zoekresultaten zoals genoemd in dit topic niet meer voorkomen.

2 likes
#17

Duidelijk! Waar kan ik een lijst met voorbeelden heensturen?

#18

Ik heb je een pb gestuurd.

#20

Het heeft even geduurd, maar de ontbrekende adressen zijn weer te vinden. Er bleken verschillende complexe onderliggende oorzaken te zijn. In de historie van de ontbrekende objecten bleken complexe correcties te zijn uitgevoerd. Het resultaat hiervan was dat deze objecten niet (goed) in de locatieserver waren verwerkt. We hebben de verwerking van objecten vanuit de LV BAG in de locatieserver geoptimaliseerd waardoor deze objecten nu wel weer terug zijn te vinden.

Zie bijvoorbeeld: BAG Viewer

Als er onverhoopt toch nog ergens iets blijkt te ontbreken hoor ik dat overigens graag.

1 like