[OSM-talk-nl] BAG (Was: Diverse vragen)

[Martijn van Exel]

2011/8/29 Oliver Heesakkers <osm2 at heesakkers.info>:
> Op maandag 29 augustus 2011 14:42:29 schreef Martijn van Exel:
>> I2011/8/29 Oliver Heesakkers <osm2 at heesakkers.info>:
>> > Op zondag 28 augustus 2011 11:04:42 schreef Martijn van Exel:
>> >> 2011/8/28 Nico Witteman <nico at wittyman.nl>:
>> >> >(...)
>> >> >
>> >> > 2.       Zijn er plannen om de huisnummers van BAG-viewer
>> >> > http://bagviewer.geodan.nl/index.html te gaan importeren?
>> >>
>> >> Zie het mailinglijst-archief, er zijn volgens mij geen concrete
>> >> plannen om de BAG-huisnummers te importeren.
>> >> Ik ben er geen voorstander van. Bij een import moet je ook nadenken
>> >> over hoe die geimporteerde data bij wordt gehouden; van de BAG komt
>> >> maandelijks een mutatiebestand uit, importeren in OSM is alleen zinvol
>> >> als je ook die mutaties opneemt. Maar hoe moet dat dan met
>> >> adresobjecten die ondertussen door een echt persoon zijn bijgewerkt?
>> >> Dat zijn moeilijke vragen.
>> >
>> > Is er sinds die discussie / call to arms eind mei uberhaupt nog iets
>> > ondernomen op dit gebied?
>> >
>> > Ik zie de BAG als zinnige vervanger voor de 3dShapes gebouwen. De
>> > nauwkeurigheid is veel groter en de informatie is uitgebreider.
>> > Bovendien zijn het juist de regelmatige updates die deze informatie
>> > waardevoller maken dan 3dShapes.
>> > Hoe mooi de 3dShapes ook zijn, op sommige (vele?) punten is die
>> > informatie nu al gruwelijk achterhaald.
>> > Sommige imports zijn zinvoller dan anderen (powerlines, datakabels),
>> > maar
>> > juist BAG-data voldoet aan een basis wens voor de moderne
>> > navigatie-gebruiker, namelijk plaatsbepaling op huisnummerniveau.
>> >
>> > Er resteren nog vele vragen over hoe een BAG-import en daaropvolgende
>> > updates aangepakt moeten worden, zodat we dubbel getekende gebouwen
>> > voorkomen en door de community aangebrachte wijzigingen zo respectvol
>> > mogelijk behandelen. Daarvoor zijn al enkele oplossingen aangedragen,
>> > maar er zal toch echt een soort werkgroep opgezet moeten worden om deze
>> > uit te werken en een import zo soepel mogelijk te laten verlopen.
>> > Ook bestaan er wellicht nog enkele vraagtekens omtrent het
>> > licentie-vraagstuk, maar dat zou het ministerie / de gemeentes
>> > definitief moeten kunnen beantwoorden.
>>
>> Het is niet alleen een kwestie van nut voor de eindgebruiker. Als
>> iemand een navigatie-app wil maken of een website met een
>> routeplanner, kan hij prima 'best of breed' datasets combineren. Dat
>> betekent nog niet dat al die data in OSM hoeft te zitten. Bij een
>> import moet je volgens mij op de eerste plaats uitgaan van het nut
>> voor OpenStreetMap en *niet* het mogelijke nut voor de eindgebruiker.
>> Die ken je immers niet - wat voor de ene groep gebruikers een heel
>> nuttig thema is, is voor een andere categorie volstrekt irrelevant.
>
> Key:addr is al een geaccepteerd onderdeel van de OSM-database en wordt in
> meerdere landen toegepast. Het is niet logisch om de Nederlandse huisnummers
> in een aparte database te gaan verstoppen terwijl de rest van de wereld zijn
> huisnummers wel gewoon in de OSM-database heeft zitten. Zelfs seamarks,
> stroomkabels en GSM-masten worden opgenomen in de database. Dat had van mij
> best in een aparte database gemogen omdat het geen recht doet aan de core
> functie van een streetmap, de BAG gegevens doen dat echter wel.

Dat laat onverlet dat er verschillende manieren zijn om die adressen
in de database te krijgen. Ik denk dat het importeren van BAG-gegevens
alleen omdat 'het er is' en omdat er een standaard in OSM is om die
adressen te coderen geen goed idee is. Die zee-elementen en GSM-masten
zijn ook ooit geïmporteerd omdat de data 'er nu eenmaal was' en er een
tag in OSM voor bestond. Iedereen heeft zijn eigen ideeën over wat er
wel en wat er niet in OpenStreetMap thuishoort - de discussies
daarover woeden bij mappen èn bij imports. Die discussie zou wat mij
betreft niet leidend moeten zijn voor de beslissing al dan niet over
te gaan tot een import.

>>
>> Het 'nut voor OpenStreetMap' kun je mijns inziens langs twee meetlatten
>> aflezen: 1. Nut voor OpenStreetMap als project: een import kan bijvoorbeeld
>> bijdragen aan een beter publiek gezicht van het project. De
>> 3DShapes-import, hoeveel vraagtekens je ook bij de wenselijkheid
>> daarvan kunt zetten (zie hieronder), heeft een mooiere kaart
>> opgeleverd. OpenStreetMap is er als ondergrondlaag, als basiskaart,
>> aantrekkelijker door geworden.
>> 2. Nut voor de OpenStreetMap als gemeenschap: een import kan een
>> impuls geven aan de lokale mappers-gemeenschap, door bijvoorbeeld een
>> eerste aanzet te geven voor de kaart. Ik denk, maar dit is nooit
>> aangetoond, dat de AND-import en ook de TIGER-import hier in de VS
>> daaronder vallen. Mijn vermoeden is dat het merendeel van de mappers
>> liever werkt vanuit een basiskaart -- hoe slecht van kwaliteit
>> misschien ook -- dan vanuit een blanco vel. Weet iemand van een
>> onderzoek dat dit argument ondersteunt of ontkracht?
>
> Ik denk juist dat een potentiele mapper bij een eerste blik op de website zal
> zien dat zijn gebied prima in elkaar zit en geen reden ziet een account te
> maken om aanpassingen te doen, maar zoals je zelf ook al zegt is dat nooit
> hard te maken.
>
> Tegelijkertijd is de mate waarin het product "af" is van belang voor het nut
> van OSM voor de eindgebruiker. Deur tot deur navigatie is tegenwoordig de
> standaard in navigatie.

Daar moeten wat mij betreft de value adders inspringen: de bedrijven
en bedrijfjes die een markt hebben, bijvoorbeeld navigatiesoftware, en
daar de best mogelijke bestanddelen voor uitzoeken om hun markt zo
goed mogelijk te bedienen. Dat moet je,vind ik, overlaten aan die VARs
die dat stukje markt kennen. Ik vind dat OSM zich moet manifesteren op
zijn èchte sterkte: de lokale kennis ingebracht door toegewijde
vrijwilligers. Alles dat niet bijdraagt aan die kernkwaliteit hoort,
als je het mij vraagt, niet in OpenStreetMap thuis. Ik neig ernaar om
de BAG om die reden de BAG te laten, en ervan op te steken wat we
kunnen. Zie mijn eerdere voorbeelden.

Interessant om op te merken is in deze context ook de discussie die op
de talk-lijst wordt gevoerd over ditzelfde onderwerp en op ditzelfde
moment. Die discussie is aangezwengeld door Jaak Laineste,die achter
het idee van OpenMetaMap[1] zit. Ik ben er nog niet uit of dit, of een
andere Linked Data-geïnspireerde oplossing de toekomst voor 'imports'
in OSM is, maar zijn denkwijze is precies de mijne.

> Er bestaat dus een spanningsveld tussen mensen het product OSM slijten en
> mensen actief aan het mappen krijgen. Na de AND en 3dShapes imports denk ik
> dat je je toch vooral op het eerste moet richten en daarbij kan een BAG-import
> een belangrijke rol spelen.

Daarin verschillen we dus van mening. Mits OSM een duidelijk
herkenbaar product heeft, nu en in de toekomst, dat zich door zijn
'warme geografie' onderscheidt van 'koude' geodata die je bij het
Kadaster of andere overheids- of commerciële bron kunt halen, zullen
we succes blijven hebben. Als we een geodatadump worden, gaat de
'warmte' verloren en verliest OSM zijn bestaansrecht.

Voor wie naar SOTM in Denver komt en zich interesseert voor dit
spanningsveld tussen 'officiële' en vrijwilligers-geodata, moet op
zondag zeker even langskomen bij het panel 'I fight authority,
authority always wins' waarin ik hier met Ed Parsons (Google), Kari
Kraun (USGS) en Robert Cheetham (OpenTreeMap) discussieer.

>
>>
>> Naast deze criteria is volgens mij het 'data bij de bron'-argument
>> heel belangrijk: data voelt zich het beste thuis zo dicht mogelijk bij
>> de organisatie die verantwoordelijk is voor de productie.
>>
>> Wat mij betreft is voor wat betreft de BAG-gegevens het laatste
>> argument doorslaggevend: het betreft hier een landsdekkende, complexe
>> databron met maandelijkse mutaties. Wat haal je je op de hals als je
>> deze data in OSM importeert? Je kunt dat bijna alleen maar éénmalig
>> doen, wat betekent dat het merendeel van de BAG-data in OSM langzamaan
>> zal verouderen, terwijl bij de bron (het Kadaster) elke maand frisse
>> data te halen is. Bedenk je eens wat dat betekent voor de kwaliteit
>> van OpenStreetMap over een jaar of drie. Op de korte termijn is het
>> een leuke winstpakker, maar op de lange termijn brengt het schade aan
>> het project toe.
>
> Het is mijns inziens absoluut noodzakelijk om die updates ook mee te pakken.
> Hoeveel werk is dat? Dat weet ik (nu) niet, zoiets moet juist bekeken worden.
> Hoe pak je dat aan en hoeveel mensen betrek je bij daarbij? Hoe groot zijn die
> maandelijkse updates en wat gaan ze kosten?(!). Moeten we hierom misschien
> niet per maand maar per kwartaal of jaar updaten?
> Allemaal goede vragen waar een "werkgroep" zich over zou kunnen buigen.

De kosten zijn onlangs gepubliceerd, en zijn volgens mij te vinden op
de website van het Kadaster.

De techniek is volgens mij niet zo interessant. Dat is allemaal op te
lossen en daar is ook geen werkgroep voor nodig. Waar het echt
spannend wordt is conflictbeheer: hoe ga je om met gegevens die
ondertussen door echte mensen zijn aangepast? Hoe verenig je 'koude'
en 'warme' updates? Wanneer is een update van de brongegevens 'beter'
dan een handmatige correctie? Ik denk dat je dit niet voor de
uiteindelijke gebruiker van de data kunt beslissen, omdat jouw of mijn
criteria voor wat beter is misschien helemaal niet overeenstemmen met
de criteria van die gebruiker. Stel: een OSM-er heeft voor een hele
wijk alle gebouwen voorzien van een 'entrance'-punt. Nu komt er een
BAG-correctie waarin alle gebouwgeometrieën op details zijn aangepast,
sommigen een beetje meer dan anderen. Wat doe je daarmee? Misschien
niet eens zo'n goed voorbeeld, maar denk een kwartiertje na en je hebt
een A4-tje met voorbeelden.

Het punt is, bij een import maakt het groepje dat zich erover buigt
een hoop expliciete èn impliciete keuzes. Of die keuzes in het belang
van de uiteindelijke gebruiker uitpakken weten we niet - omdat we die
gebruiker niet kennen. De BAG daarentegen wordt geproduceerd met een
duidelijk mandaat, als je die dataset downloadt weet je precies wat je
krijgt en wie er achter zit, wat de kwaliteitsprocedures zijn etc.
Zodra die gegevens in OSM verdwijnen is dat allemaal weg. Voor de
gebruiker ontstaat een heel verwarrende situatie. OSM is voor een deel
het product van de inzet van vrijwilligers die hun lokale kennis
inbrengen, maar voor een ander deel een vergaarbak van data die je in
principe ook elders kan krijgen en die zijn belangrijkste
kwaliteitskenmerk heeft verloren, namelijk de herleidbaarheid van de
gegevens. Ik zou dan toch liever de bron aanspreken voor die data en
voor de 'warme' data bij OSM aankloppen. Data bij de bron, tenzij.

Misschien ontstaat er in de toekomst wel een gemandateerd koppelvlak
tussen de wereld van de vrijwillig bijgedragen geodata en de officiële
geodata - de USGS experimenteert daar al mee[2] - maar tot die tijd
moeten we die twee beesten volgens mij in gescheiden kooien houden.

> We zijn het eens dat verouderende data op de lange termijn schadelijk is voor
> het project (het volgt eigenlijk per definitie). Zonder Bing zou alle
> 3dShapes-data over enkele jaren eigenlijk zonder meer uit OSM moeten worden
> verwijderd. Nu met Bing en een flinke inzet van de community gaat die data
> misschien wat langer mee, maar ik weet zeker dat er grote gebieden in
> Nederland zijn waar geen mapper naar omkijkt, of hooguit als-ie er toevallig
> een keer doorheen loopt of fietst.
>
> Bij de gebouwen is dit probleem volgens mij nog groter dan bij landuses
>
> Regelmatige updates uit een betrouwbare en accurate bron helpen ook juist de
> mapper omdat je die gegevens als uitgangspunt of extra controle kan gebruiken.

Dat kan ook zonder import. Net als Bing kun je externe data als
achtergrond / controlelaag in een editor laden.

> [..]

[1] https://wiki.openstreetmap.org/wiki/OpenMetaMap
[2] http://pubs.usgs.gov/of/2011/1136/
-- 
martijn van exel
schaaltreinen.nl