BAG vs. realiteit; pand vs. verblijfsobject

@arvdk
Zie ook mijn tweede bericht.

De BAG is dus niet bedoeld om altijd de realiteit weer te geven. Vergeleken met OSM kent de BAG meer waarde toe aan historische en administratieve aspecten.

In dit geval zijn het dus volgens de BAG twee panden en één verblijfsobject op de begande grond. Ah, ik bedenk met net dat de twee adressen/verblijfsobjecten op de eerste etage mogelijk nog wel zijn ingericht als gescheiden panden. Dat maakt het complexer. Op de begane grond bevindt zich een Bruna-winkel en de reëele weergave daarvan heeft in de praktijk een veel groter belang voor een gemiddelde gebruiker van OSM-data. Tot vorig jaar waren er nog twee voordeuren en een tussenwand. Nu is er nog één voordeur en geen afscheiding meer.

In winkelstraten komen dit soort situaties veel voor. Een pand blijft in principe een pand totdat het gesloopt wordt. Dat het verbouwd wordt, en via het uitbreken van tussenmuren één bedrijfsruimte met een naastgelegen pand vormt, doet niet ter zake. Dat kan immers later ook weer ongedaan gemaakt worden.

Daar waar de BAG niet klopt met de werkelijkheid zet ik meestal ook een note op het gebouw met deze informatie.

In sommige gemeentes zitten er nog fouten de BAG (panden onterecht verwijderd, dubbel of driedubbel in de BAG) en worden
terugmeldingen genegeerd.

Sommige worden gebouwen ook niet in de BAG gezet (bv. een stal die aan 1 kant open is). Die teken ik dan handmatig in met een note dat het pand niet in de BAG staat.

Vele mappers baseren zich niet meer op eigen waarneming, maar op kaarten, etc. Dan worden er fouten gemaakt. Voor importeren uit bestanden geldt hetzelfde. Vaak zijn die bestanden gebaseerd op ‘oude rechten’ en is de situatie heden ten dage totaal anders. Zo werd er in 1911 een grindweg aangelegd tussen 2 dorpen in het Reitdiep gebied. Deze grindweg was een hele verbetering omdat de verbinding tussen de twee dorpen aanzienlijk korter werd. Er zijn nu aanzienlijk meer alternatieven en de boer gebruikt de grindweg uitsluitend voor eigen gebruik. Het is geen grindweg meer, maar een betonpad. Het pad is afgesloten d.m.v. een afrastering zodat de koeien en ander vee niet kunnen weglopen.

Enkele jaren geleden fietste ik over een slecht onverhard “menpad” met diepe kuilen. Het pad was afkomstig uit een BAG import en droeg een fraaie naam. Waarschijnlijk rusten er nog ‘oude rechten’ op dit pad, maar bruikbaar als fietspad is het niet. Hetzelfde geldt voor het recht van overpad. Vele boeren hebben dergelijk paden al lang omgeploegd omdat er decennialang geen gebruik van is gemaakt.

Ik ben niet tegen gebruik van kaarten, import, etc. als de mapper de gegevens controleert. Helaas ontbreekt die controle in vele gevallen en komen er wegen/paden op de OSM te staan die totaal niet bestaan of bruikbaar zijn.

Wat ik mis is een forumtopic waarin wordt aangegeven wat men van plan is. Ik had namelijk wel in gedachte om een keer in de BAG te kijken naar toevoegingen/wijzigingen in de regio, die dan fysiek te controleren en dan om import te vragen.
In Nederland is er in 2014 een massale BAG-import geweest. Het is logisch dat minder dunbevolkte bieden minder snel aan bod komen en mappers langer wachten om daarvoor updates aan de vragen. Dat wil niet zeggen dat er geen mappers zijn met interesse om zaken te controleren in dat gebied.

De mogelijkheid van ongedaan maken gold in dit geval misschien vóór de verbouwing maar nu niet meer. Ja, in theorie kan alles ongedaan gemaakt en teruggedraaid worden maar dan hoef je niets meer te mappen.
In mijn beleving onderscheidt OSM zich door gegevens zoveel mogelijk te baseren op (individuele) waarneming, waar vele andere bronnen, databases en kaarten zich baseren op aangeleverde gegevens zonder de directe controle in de praktijk.

Mattheus geeft een ander goed voorbeeld van hoe de drang naar een completere OSM-database kan leiden tot een verlies van betrouwbaarheid en van onderscheidende waarde.

Als de BAG voor 99.9% wel klopt, dan zou het jammer zijn om de BAG niet te importeren omdat het in 0.1% mis gaat. Dan kan je beter
een goede procedure hebben om te voorkomen dat na correctie een volgende update de correctie voor ongedaan maakt.

Dit doet me denken aan de Onroute Fietskaart. De makers ervan hadden allerlei fietsroutes geanalyseerd zodat de kaart altijd de mooiste routes zou kiezen.

Om een lang verhaal kort te maken: in theorie voldeed de kaart beter dan in de praktijk.

Bij bovenstaand voorbeeld (Voorstraat 82/84) in Kollom zou je kunnen kiezen uit 2 oplossingen die min of meer recht doen aan zowel de BAG als de werkelijkheid en daarnaast voorkomen dat de BAG controle mechanismes blijven aangeven dat er panden ontbreken

  1. Teken zowel de 2 oorspronkelijke gebouwen als het samengevoegde gebouw. Tag de oorspronkelijk BAG gebouwen met building:part=retail en het bag id. Tag het samengevoegde gebouw zonder bag id.
  2. Het zelfde als hierboven, maar gebruik no:building=yes ipv building:part=retail. De no: prefix in OSM kan gebruikt worden om expliciet aan te geven dat iets er niet is, hoewel andere bronnen aangeven dat het er wel is.

@Sander H: Als je meeleest, kan de de BAG Webservices aanpassen zodat ze rekening houden met building:part en no:building? Misschien ook no:addr:housenumber, maar daar heb ik zelf nog geen toepassing voor.

Ik ga kijken of note:BAG/note:bag in de BAG plug-in kan gebruiken om semi-automatische updates te blokkeren.

Ook in mijn regio heeft de vries bag updates uitgevoerd. Van de week heb ik dit gepost op de “verzoek bag-import”

Vanmorgen ben ik op werkbezoek geweest in een nieuwbouwwijk Casterhoven te Kesteren.
Het viel mij op dat er huizen verkeerd op OSM staan, zie https://www.openstreetmap.org/note/1136 … 0&layers=N .Degene die het heeft toegevoegd heeft een bericht van mij. De BAG is dan wel leidend maar vaak zie ik dat het fout gaat. Zoals bij Meester A dademalaan hier zijn enkele huizen in aanbouw (eerste verdieping af of alleen de fundering). Nu liggen enkele huizen in een pas gegraven afwateringssloot van 5mt breed. Ook andere huizen staan foutief op de kaart. Ik heb al een terugmelding gedaan.
Veel gemeenten die samengevoegd zijn lopen achter of muteren maar een paar keer per jaar. Dit geldt ook bij andere nieuwbouw projecten in deze gemeente, waaronder bij het nieuwe laanbomencentum aan de rand van Opheusden.
Zouden jullie hierop willen letten met importeren of er bij staat vergunning verleend, bouw gestart ( bv https://bagviewer.kadaster.nl/lvbag/bag … 0000020393 ) of nog niet ingemeten? Zelf heb ik geen bevoegdheid op OSM om BAG gegevens toe te voegen.
Ik werk dagelijks met de BAG en andere kadaster gerelateerd werk en kom op verschillende plaatsen in het land.

Van “de vries” vandaag deze reactie gekregen:
Bedankt voor het fixen en het doen van de terugmelding(de afhandeling hiervan verschilt echter nogal per gemeente).
Osm-notes zijn lastig te monitoren bij het uitvoeren van een bag-update. De beste manier om bag importeurs er op te wijzen dat je panden afwijkend van de bag hebt aangepast is de tag “note:BAG=*” aan het pand toe te voegen. Of aan een losse node als het om een verwijderd pand gaat.
In een andere reactie zegt dat hij de luchtfoto’s van Pdok bekijkt, op zich prima maar hoe doe je dat met nieuwbouwterreinen als er in de BAG staat dat de vergunning is verleend?

Jammer dat hij niet eerst kijkt ter plekke of er een update echt nodig is en hoe bij nieuwbouwterreinen de situatie is. Dat kan als laatste nogal verschillen van de tekentafel van architecten met hun sfeerimpressies en de uitvoering door het bouwbedrijf / aannemer.
Zie ook http://resultmaps.neis-one.org/osm-discussion-comments?uid=1707814 ik ben niet de enige die reacties naar de vries stuurt.

mechanical edits

In het update proces zit veel handwerk en checks om fouten te voorkomen. Ik kan echter niet ontkennen dat deze bewerkingen een mechanisch karakter hebben. Toch wil ik betogen dat dit geen probleem is. Ten eerste is het import/update proces uitgebreid gedocumenteerd en met de community bediscussieerd en voldoet hiermee aan de richtlijnen voor mechanical edits. Daarnaast is voor veel panden de bag de enige bron. Het zou in deze gevallen vreemd een aanvullende bron te eisen als de bag zegt dat een pand gewijzigd is of niet meer bestaat.
Daarnaast is dit een variant op het trolly probleem. Je hebt de gelegenheid om 100 fouten uit osm te verwijderen, maar de kans dat je een nieuwe fout introduceert is groot. Als je niets doet zal niemand je hier op aanspreken, maar iedere fout die je introduceert staat op jouw naam.

Enkele cijfers ter relativatie
In osm (in NL) staan ongeveer 10.000.000 bag-panden.
In de bag staan 90.000 panden die niet in osm staan. Een jaar geleden waren dat er nog 220.000. Maandelijks komen er ~5000 panden bij in de bag die nog niet in osm staan.
In osm staan 119.000 panden die volgens de bag gesloopt zijn, een jaar geleden waren dat er nog 179.000. Ook hier komen maandelijks enkele duizenden panden bij.
Dan zijn er nog de panden met een gewijzigde geometrie, Ik heb hier geen cijfers van, maar in mijn ervaring gaat dit om ongeveer 5x meer panden dan de missende panden.
Ook zijn er nog de missende en afgevoerde adressen, de statistieken hiervan zijn vergelijkbaar met die van de missende en gesloopte panden.
Ik schat in dat het op het huidige tempo nog zeker een jaar duurt voor de achterstand die osm op de bag heeft opgebouwd sinds de initiële import is weggewerkt. Daarna zullen maandelijks enkele duizenden panden en adressen in osm moeten worden toegevoegd/aangepast/gewist.

Ik geef het je te doen om deze plekken eerst allemaal af te reizen

Ik ben blij dat je naar deze pagina verwijst. Hierop kan je zien dat ik tot op heden 8x een melding heb gekregen over een probleem dat geïntroduceerd is bij een door mij uitgevoerde bag-update. Via Neis-one kan je ook zien dat ik de laatste bewerker ben van bijna 400.000 panden (dit is exclusief panden die later door iemand anders zijn bewerkt, panden die ik meerdere keren heb bewerkt en panden die ik heb gewist.) Persoonlijk ben ik best tevreden met deze foutratio.

Conclusie
Enkel op basis van eigen waarneming panden updaten is menselijk gezien niet haalbaar. Geen updates doen waar eigen waarnemingen ontbreken is ook geen optie, omdat osm dan al snel te ver achterloopt op de werkelijkheid om nog bruikbaar te zijn.
Gelukkig zijn er zorgvuldige update methodes ontwikkeld die voldoen aan de ‘Automated Edits code of conduct’. Hiermee is het mogelijk om op semi-automatische manier te updaten zonder veel fouten te introduceren. Volgens mijn berekening gaat slechts in 0,002% to 0,1% van de gevallen mis. (afhankelijk van afrondingen en hoe je fouten telt) Vanuit een puur pragmatisch standpunt is dit zeer acceptabel en zelfs verwaarloosbaar.

Het enige probleem dat overblijft is dat mensen hun handwerk overschreven zien worden door een bag-update. Dit is vooral een emotioneel argument dat vanuit een rationele benadering gemakkelijk onderuit te halen is, maar dat maakt het nog geen slecht argument. Het zijn uiteindelijk de mensen die deze community maken, dus het laatste wat we moeten doen is deze mensen demotiveren en/of wegjagen.
Het is dan ook goed dat bovenstaande problemen worden aangekaart en bediscussieerd. Dit houd iedereen scherp en motiveert om de methodiek van de bag-updates te blijven verbeteren.

Happy mapping!

Stel, je creëert door jouw manier van mappen een gevaarlijke situatie op de OSM en de gebruiker van de kaart overkomt iets. Want, zoals je zelf schrijft, “Ik geef het je te doen om deze plekken eerst allemaal af te reizen”.

Hoe zou je je dan voelen?

Het voorval beschreven in onderstaande link, vergeet ik nooit weer:

http://forum.gps.nl/viewtopic.php?f=76&t=32427

Kei goed! want ik zou dan weten dat ik statistisch gezien honderden mensen het zelfde lot bespaard heb.

voor de mensen die geen zin hadden dit hele verhaal te lezen: de TL;DR is Man met gps verdwaald in bos en geeft de gps de schuld.

Ik ben de afgelopen weken tenminste drie keer over een route geleid waar je niet mag fietsen. 1 was een voetpad waar om een of andere reden een bicycle=yes op stond. 2 keer een eenrichtingverkeer die verkeerd stond.

OSM is nu eenmaal niet perfect.

Voor mij is zeker de import van adressen uit de BAG goud waard.

Vandaar, de access icoontjes, zo dat het op valt.
https://forum.openstreetmap.org/viewtopic.php?id=58694

Het hangt er van af wat er wordt geïmporteerd: lantaarnpalen, etc., levert weinig problemen op, maar wegen en paden kunnen wel problemen opleveren. De mapper is verantwoordelijk voor wat hij/zij op de kaart zet. Hij/Zij zal zo nauwkeurig mogelijk te werk moeten gaan zodat de informatie op de kaart betrouwbaar is. We hebben niets aan onbetrouwbare kaarten. Maar om willekeurig dingen op de OSM te kwakken, zonder de informatie zelf daadwerkelijk te controleren is vragen om problemen. Iemand kan wel trots zijn op een lage foutmarge, maar elke fout is er één te veel, vooral als een mapper een gevaarlijke situatie creëert met zijn/haar niet gecontroleerde import.

Perfect zal de OSM kaart niet worden. Dat zal ook nooit gebeuren. Er zijn immers vele (amateur) mappers bezig die puur uit interesse hun hobby uitoefenen. De OSM is uiterst bruikbaar in vele gevallen. De Openfietsmap is heel wat beter dan de commerciële Onroute Fietskaart.

Automatische import van wegen en paden is op dit moment nogal theoretisch geloof ik. Zonder concreet plan is ook niet in te schatten
wat voor gevaar dat op zou leveren.

Een kaart geeft informatie. Stel iemand gaat ervan uit dat de kaart betrouwbare informatie geeft en krijgt daardoor een ongeluk. Een ongeluk veroorzaakt door een fout op de kaart. Er moet schade worden verhaald. Indien een OSM kaart wordt gebruikt, is de mapper eenvoudig te achterhalen. Kan justitie de mapper aansprakelijk stellen en de schade op hem/haar verhalen? Want de mappper is degene die de informatie heeft verstrekt.

Zou je daar eigen topic van kunnen maken.

Dat mag jij ook doen. Het is natuurlijk uiterst theoretisch, maar onmogelijk zou het niet zijn.

Zelf ben ik bezig met stamboomonderzoek, maar een boek zou ik niet uitgeven. Je weet nooit zeker hoeveel kinderen een echtpaar heeft gehad. Als er in het boek een kind niet wordt vermeld, wordt dat de auteur uiterst kwalijk genomen. Staan er meerdere foutjes in het boek, wordt het afgekraakt. Ik werk wel mee aan een boek waarin heel veel historische feiten staan. Bij mijn zoektocht naar gegevens, zorg ik ervoor dat de auteur de gegevens kan controleren en verifiëren. De auteurs zoeken alles op in officiële documenten zodat de kans op fouten in het boek minimaal zijn zodat de lezer veel plezier aan het boek heeft.

De mapper moet niet uitgaan van zichzelf, maar moet uitgaan van de gebruiker van de kaart. De gegevens die een mapper op de kaart zet, moeten voor de gebruiker 100% betrouwbaar zijn.