BAG historische fouten (opschonen?)

Datasets BAG
#1

Ik vraag me even af of er misschien anderen ook tegenaan lopen dat de BAG niet alleen “echte” historie bevat, dus van ontstaan t/m verdwijnen in de buitenwereld maar ook van beheerfouten (neem ik aan). Ik zag het zo snel nog niet als topic hier voorbijkomen.

In het voorbeeld van BAG panden zit een verkeerd pand niet direct in de weg, vaak is het al snel op “Pand gesloopt” of “Niet gerealiseerd pand” gezet.
Maar als de geometrie erg afwijkt kan het voor bepaalde software tot problemen leiden. Zo werkt bij mij de geoserver WMS niet meer goed op de BAG NL set (in PostGIS).

Ik denk zelf dat het komt door de panden in de Noordzee en de sterk horizontaal uitgerekte panden… (zie afbeelding hieronder)
Natuurlijk kan ik ze simpel uitfilteren maar met name de Rotterdamse woonwijk in de Noordzee vond ik wel een sterk voorbeeld. Het lijkt er trouwens al enige tijd in te zitten, vanaf medio eind 2020.

Misschien kan Kadaster dit verwijderen uit de LV? Of enkel pandgeometrie toelaten binnen de NL bounding box. Het verwijderen wordt neem ik aan lastig omdat de bronhouder en het Kadaster dit dan (technisch) zouden moeten afstemmen…
Nou zou het nog kunnen dat ik het verkeerd geconverteerd heb uit het BAG extract maar ik denk dat ik de conversie juist heb.

Heeft iemand anders hier een ervaring mee?

image
image2465×753 82.3 KB

#2

Dit is mij ook opgevallen toen ik je conversie tool gebruikte. Er zijn af een toe “vreemde” panden. :crazy_face:

#3

Ik heb dit wel eens aangekaart bij het Kadaster. Deze panden horen er volgens hen in. Als je enorm gaat toveren met de geldig van en geldig tot datums en nog wat if>then expressies kan je ze er uit halen.

Als je wilt weten welke regels je daarvoor moet gebruiken: Succes met uitzoeken, de documentatie gaat je niet helpen.

#4

@Ronald_Mulder: Het historiemodel van de BAG heeft nu eenmaal als uitgangspunt dat historische fouten een onderdeel van de registratie blijven. Het is daarmee niet mogelijk oude fouten uit de registratie te verwijderen.

Het kenmerk van het BAG extract is dat het extract een volledige weergave is van de BAG. In een BAG extract zul je dus altijd historische fouten tegenkomen. Als gebruiker van een BAG extract is het dus vereist dat je hiermee om kunt gaan. Zoals jezelf al aangeeft is het relatief eenvoudig deze fouten eruit te filteren. Voor de volledigheid verwijs ik nog even naar een topic over de filtering op historie.

Er zijn toepassingen van de BAG waarin er geen behoefte aan historische gegevens (laat staan historische fouten). Daarom zijn er productvarianten ontwikkeld zonder historie. Voorbeelden hiervan zijn de BAG WFS en de BAG WMS.

Graag maak ik van de gelegenheid gebruik om aan te kondigen dat we de definitieve versie van de BAG geopackage in de loop van deze maand zullen opleveren. Aangezien de geopackage alleen huidige gegevens bevat, heb je als gebruiker van de geopackage geen last van historische fouten.

De Rotterdamse panden in de noordzee zul je bijvoorbeeld niet terugvinden in de geopackage. Deze panden hebben kort na opvoer de status ‘niet gerealiseerd pand’ gekregen. Zie bijvoorbeeld het pand met ID 0599100110003885

image
image717×273 28.6 KB

#5

@PieterDijkstraBAG

Dit is dus exact wat ik bedoel. “Als gebruiker van een BAG extract is het dus vereist dat je hiermee om kunt gaan.”

Ermee om kunnen gaan zal ik even vertalen: Als je bij de in-crowd hoort. Want jezelf aanleren ermee om te gaan is vrijwel geen doen (of het moet je kerntaak zijn en dan nog is het niet bepaald een pretje). Gelinkte topic is een mooi voorbeeld: als je wilt weten hoe je aan de actuele panden wilt komen blijkt dat nergens duidelijk uit de gebrekkige documentatie. De WMS helpt sowieso niemand die een analyse wil doen, de WFS is nog steeds onbetrouwbaar en heeft een max van 10.000 panden. Je moet dus maar net even over een obscure forumpost struikelen om erachter te komen hoe je alleen de bestaande panden over houdt. En dat is nog maar 1 van de struikelblokken.

Wel goed om te lezen dat de Geopackage komt!

#6

Pieter, dank voor je reactie.
Op zich heel begrijpelijk, ik was ook al wel iets bekend met deze achtergrond.
Wel jammer dat dit zo star is en niet opnieuw kan worden overwogen (tenzij in nieuwe BAG versie wellicht).

Het is volgens mij voortschrijdend inzicht dat een basisregistratie ook gevoelig is voor verkeerd ingebrachte objecten. Waar gewerkt wordt worden fouten gemaakt, door mensen en systemen. Waarom niet een route die in staat stelt om dit te kunnen corrigeren? Nu is het effect dat je decentraal door verschillende afnemers dit moet laten corrigeren, een soort symptoom bestrijding…
En dat elke maand weer(!)

Plus dat veel afnemers dit niet verwachten, niet of moeilijk kunnen oplossen, en een negatief beeld overhouden aan de BAG registratie. Terwijl het zo’n fantastische dataset is! :slight_smile:

Het zou toch veel eleganter zijn om dit 1x bij de bron aan te kunnen pakken.

Overigens maak ik daadwerkelijk gebruik van de historie in de BAG dus voor mij zou het zeer zeker nuttig zijn.

Ik vind het wel daarnaast wel leuk en handig dat de distributie meer en meer richting GeoPackage gaat! (eigenlijk ook voortschrijdend inzicht, eerder moest het altijd en enkel via GML).

2 likes
#7

Tja, ik ben het met je eens dat niet alle keuzes keuzes die bij het ontstaan van de BAG zijn gemaakt altijd even goed uitpakken. Binnen de huidige (wettelijke) kaders zijn de mogelijkheden dit structureel op te lossen echter beperkt. Formeel gezien is de landelijke BAG-registratie nog steeds niet meer dan een kopie van de BAG-registratie bij de gemeente. We zijn als beheerder van de LV BAG daarmee verplicht (functionele) fouten in de gemeentelijke registratie over te nemen in de landelijke BAG-registratie.
In de keuzes die we maken bij de uitlevering van de gegevens is het zeker onze bedoeling dat we zo veel mogelijk voorzien in de behoefte van de gebruikers en gegevens uitleveren met een zo hoog mogelijke (beleving van de) kwaliteit. Zo verwacht ik dat de geopackage geen grote fouten in de pandgeometrie bevat.

Ik zal eens onderzoeken of we ergens helder kunnen beschrijven welke soorten historische fouten bij ons bekend zijn, zodat niet elke afnemer deze fouten zelf apart hoeft te ontdekken.

#8

Hallo Michiel,

Ondanks dat ik je frustraties begrijp, en deels ook deel, zou ik je toch willen vragen om een beetje te letten op de toon van je berichten. Die komen namelijk via een forum, zonder context van gezicht en lichaamshouding, heel onvriendelijk over.

Ik weet dankzij veel internationale ervaring heel goed dat Nederlanders een reputatie hebben van directheid (“allowing questions after a presentation feels like being machine-gunned”, vrij geparafraseerd naar Charles Hampden-Turner en Fons Trompenaars), maar je kunt feedback ook op een minder negatieve manier verwoorden. Positieve, opbouwende kritiek is altijd welkom, en verbetert uiteindelijk producten, maar als je te vaak te negatief bent jaag je alleen maar mensen tegen je in het harnas. En dat wil niemand. Bovendien stoot het minder ervaren mensen misschien ook af - en dat willen we ook niet, iedereen moet zich hier veilig voelen om alle vragen te kunnen stellen.

Als je hier verder over wilt discussieren, is een PM, of een telefoontje, altijd een optie.

Groet,
Stefan

#9

Hallo Stefan,

Op zich heb je gelijk. De frustratie is gevolg van het jaren lang negeren van berichten die wel op een vriendelijke toon waren, ik heb het echt wel geprobeerd.

Ik heb hierover inmiddels contact met het Kadaster en we gaan binnenkort een keer in gesprek, zodra mijn agenda dat toelaat.

#10

Hoi Michiel,

Prima! Aanbod blijft staan overigens, ook als je een keer 'n kop koffie naast station Amersfoort wil komen drinken.

Groet,
Stefan

#11

Dank je. Ik kom helaas niet (meer) zo vaak in Amersfoort.