BAG vs. realiteit; pand vs. verblijfsobject

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.

Aansprakelijkheid verantwoordelijkheid, discussie hier verder.

[edit: per abuis te vroeg op submit geklikt]

Zo is het! Het gaat erom de methodiek te verbeteren.

Die laatste alinea maakt je verhaal behoorlijk compleet en overtuigend. Niettemin zie je op dit punt volgens mij iets belangrijks over het hoofd. Je legt namelijk de nadruk meer op de inhoud dan op het proces, meer op de gegevens dan op de mensen.

Je zet het ‘menselijke’ argument als emotioneel tegenover de rationele benadering, alsof het een kwestie is van begrip hebben voor en gedogen van de emotionele waarde die mappers hechten aan hun bijdragen. Je erkent wel dat uiteindelijk de mensen deze community maken maar ik lees tussen de regels door dat dat voor jou ondergeschikt is aan de data.
Ik heb zelf eerder al wat moeite gehad met de werkwijze van de DWG: de verantwoordelijkheid van het corrigeren van verkeerde wijzigingen eerst bij de community leggen en vervolgens mappers die niet overtuigen in communicatie en leergierigheid veel tijd en kansen geven voordat echt wordt ingegrepen.
Zo’n ‘losse’ mapper bezorgt veel extra werk aan de serieuze en ervaren mappers terwijl juist zij in diezelfde tijd met hun vaardigheden voor belangrijke toevoegingen en verbeteringen hadden kunnen zorgen.

Echter, de open toegang tot OSM is nou eenmaal onderdeel van het hele feest. Net als met Wikipedia is het hoofddoel niet om een zo goed mogelijke encyclopedie te maken maar om een in meerdere opzichten vrije encyclopedie te maken. Net zo is het volgens mij met OpenStreetMap (vrije geodata).
Kortom: de hoge kwaliteit moet worden gezien als een uitvloeisel van de vrije opzet van OSM en het versterkt het succes. Het is echter geen doel op zich. Individuele of groepjes mappers kunnen wel als doel hebben om op deelgebieden de gegevens te optimaliseren maar dit kan hooguit een subdoel zijn binnen OSM als gemeenschap en project.
Ik weet niet of ik het heel goed heb verwoord.

Is er hierbij geen onderscheid tussen de import die in 2013 is besproken en de huidige imports/updates? Indertijd was er nog niets vanuit de BAG geïmporteerd en als ik het goed heb is in 2014 elke regio wel aan de beurt geweest.
Is het populaire topic ‘Verzoek BAG-import’ er dan alleen zodat mappers updates kunnen versnellen en is de hogere betrouwbaarheid slechts een bijkomend voordeel?

De systematische regionale BAG-imports/updates hebben zeker mijn steun en sympathie. Ik zou alleen willen voorstellen om deze (ruim) vooraf aan te kondigen en te bespreken zodat lokale en geïnteresseerde mappers de mogelijkheid hebben om er invloed op uit te oefenen. Als een regio niet of nauwelijks reactie oproept dan is de kans groot dat het onderbelicht gebied is waarbij een import/update des te meer een grote vooruitgang zal betekenen.

De discussie raakt redelijk off topic…

Weer on topic…

============================================================================
Ik denk dat hoofdzaken van bijzaken dienen te worden gescheiden.
Het lijkt erop dat het “onkruid” belangrijker gaat worden dan “de bloemen”.

Vaak werkt dit zo in discussies. De één geeft een kritische noot, de ander verdedigd hetgeen op dat moment bekritiseerd wordt.

De BAG is in 2012 opendata geworden, het is belangrijke data die we graag in OSM opgenomen wilden zien.
Veel opendata wordt onder een CC-BY licentie uitgebracht.
Hier kunnen we, mits we goedkeuring van de bronhouder hebben, niet zo veel mee.
De BAG is onder CC0 1.0 uitgebracht, en mocht dus gebruikt worden binnen OSM.

Voordat een import mogelijk is, dient de community eerst consensus met elkaar in overleg te treden om te zien of er een meerderheid is die dit ook vind.

Daarna is een groep mappers een aantal keren bij elkaar gekomen om te boetseren hoe/wat/waarom/wanneer maar vooral met zorg gedaan kon gaan worden. Dit is allemaal vastgelegd en bediscusieerd destijds.

Daarna is een plugin ontwikkeld, die alle faccetten moest aankunnen, om überhaupt een import mogelijk te kunnen maken. Ook is er een handleiding geschreven waar veel aspecten in acht genomen moesten worden om te kunnen importeren.

Ervaren mappers hebben zich kunnen inschrijven om een exemplaar van de plugin te kunnen ontvangen.
Omdat heel Nederland uiteindelijk geïmporteerd ging worden, was het noodzaak om dit in goed overleg en met goede afbakeningen van gebieden uit te voeren. Deze werden bijgehouden in de intekenlijst.

Natuurlijk zijn er best veel mappers bezig geweest om zo zorgvuldig mogelijk deze import te doen slagen.

Na deze grote import actie (dit heeft toch gauw een jaartje geduurd) is er verder gedacht over de continuering van de gewijzigde/nieuwe/gesloopte panden) Nederland bouwt gewoon door.

Hiervoor heeft de plugin maker een geheel nieuwe plugin moeten ontwikkelen om deze mutaties te kunnen importeren.

Hierbij is afgesproken dat (ook bij deze import) de BAG status “vergunning verleent” niet geïmporteerd zou gaan worden, mits er duidelijk is dat de gemeente achterstand heeft in deze wijk. En dat dus lokale bekendheid actueler is, dan de BAG data.

Er is een BAG Update handleiding gemaakt, waaraan de mapper zich moet conformeren.

Mocht een mapper niet voldoen aan de gestelde eisen, mag je hem daar gerust op aan spreken.
Laten we elkaar geen “mietjes” noemen en probeer op een normale manier met elkaar in contact te treden.

Een mapper die de moglijkheid heeft om BAG panden te importeren dient zorgvuldig te werk te gaan, en dient de ontstane vragen die een andere mapper heeft te beantwoorden. We streven immers allemaal naar een zo zorgvuldig mogelijke data in OSM.

Hopelijk trekt een ieder, die de schoen past, aan.

Ik ben het helemaal eens BAG data (in sommige) gemeenten (helaas) niet betrouwbaar is.
Maar het is ondoenlijk om overal een terugmelding van te maken naar de bronhouder.

Dat heb je prima verwoord. Misschien ben ik degene die z’n standpunt niet duidelijk genoeg verwoord heeft.

Ik zie hoe mijn woordkeuze mischien niet de beste was, maar ik vind het zeker zeer belangrijk om rekening te houden met de gevoelens van mede-mappers.

Als je alleen naar de korte termijn kijkt dan is het rationele argument duidelijk het sterkste. Als je een heleboel goede data toevoegt ten koste van een kleine hoeveelheid data heb je per saldo een betere kaart.
Op de lange termijn is het echter zeer belangrijk om ook naar emotionele argumenten te luisteren, want hiermee bouw je aan een sterke community en kan osm ook in de toekomst in stand blijven. Met emotionele argumenten bedoel ik dat de mapper die de kleine hoeveelheid data uit het eerste voorbeeld heeft toegevoegd nu het gevoel krijgt dat zijn of haar bijdragen, plus de tijd die daar in is gaan zitten niet gewaardeerd worden. Behalve dat dit niet heel aardig is voor je mede-mapper loop je het risico dat deze mapper de motivatie verliest om aan osm bij te dragen. Hiermee verlies je niet alleen alle potentiële bijdragen van deze mapper maar ook een persoon die lokaal gegevens kan verifiëren.

Kortom: rekening houden met de gevoelens van mensen levert niet direct een betere kaart op, maar wel een sterkere community en dus op termijn een betere kaart.

Ik denk dat het belangrijk is dat iedereen zich realiseert dat niets perfect is. Het scherm waar je naar kijkt kan een dode pixel hebben, het toetsenbord waar je op typt een scherp randje heeft of dat er een scheurtje in een papiertje zit. Kaarten zijn ook niet perfect, ook niet de commerciëlen waar veel geld voor betaald wordt.

Ik ben persoonlijk zeer blij met de verwerking van de BAG gegevens en dat er mensen zijn die de moeite nemen om dit ook bij te houden! Ik kom (helaas) niet verder dan wijzigingen doorvoeren die mij opvallen als ik door het dorp heen fiets.

Om terug te komen op kaart versus werkelijkheid; een oud schoolgebouw wordt momenteel gesloopt bij ons in het dorp. Bij de desbetreffende node staat dat de source BAG is. In de BAG Viewer heeft deze de status ‘Sloopvergunning verleend’. Kan ik deze node(s) gewoon straffeloos verwijderen?

Ik las net meerdere comments op verschillende BAG importen over het per ongeluk her-importeren van gesloopte gebouwen. Mijn tip is daarom: zet building=* om naar demolished:building=*. Het gebouw verdwijnt dan van de kaart, maar de gegevens blijven (tijdelijk) bewaard. De adres node kan verwijderd worden. (Je kan nog overwegen het adres ook op de demolished:building te zetten, zoals ik bijvoorbeel hier heb gedaan.)

[toevoeging: voor de volledigheid zou je ook nog een construction area kunnen toevoegen, voor de tijd dat de sloop duurt. Al dan niet met een description (bijvoorbeeld: ‘description=sloop van schoolgebouw’).]

@de vries en andere BAG-importeurs:
ik ben erg blij met alle moeite die jullie nemen voor de BAG-imports en de resultaten daarvan.
Per saldo wordt OSM daar naar mijn idee echt beter van.
Veel dank dus!

@devries
Je begrijpt nog niet helemaal wat ik bedoel aangezien je mijn punt, door het te koppelen aan gevoel en emotie, eigenlijk niet als argument erkent.
Ik beweer simpelweg dat OSM niet alleen draait om zoveel mogelijk goede data toe te voegen. Dit staat dus los van cijfers en foutmarges. Samenwerking en overleg binnen de community is misschien wel het belangrijkste onderdeel van OSM.

De BAG-import-handleidingen bevatten vooral technische instructies. Wel lees ik:

Dit lijkt te gaan over de tijd waarin er nog geen volledige ronde aan BAG-import was gedaan.

Ik vind dat het bestaan van een afspraak uit 2013 en (overwegend technische) handleidingen voor BAG-import niet heel goed invulling geeft aan het aspect samenwerking en overleg binnen de community.
Imports en grootschalige updates kunnen het actueel houden van OSM stimuleren, ook lokaal.
Juist om meer waardering en betrokkenheid te scheppen heb ik mijn voorstel gedaan:

Het afgelopen half jaar heb ik de gebouwen in osm mbv de BAG up to date proberen te houden in Midden en Noord Limburg.

Fouten die gemakkelijk te herkennen zijn meld ik aan de betreffende gemeente. Meestal is er een snelle opvolging.
Van een paar gemeentes hoor je nooit iets terug en wordt er niets aangepast.
Ik zet een note op het gebouw dat er een afwijking is tussen de BAG en werkelijkheid.

Mocht er iemand zijn die zelf hier een gebied wil bijhouden, laat het dan even weten.
Bij de eerste update had ik de indruk dat er alleen de initiele import gedaan was, maar ik kan mij natuurlijk vergissen.