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.
[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.