Op maandag 29 augustus 2011 14:42:29 schreef Martijn van Exel:
> I2011/8/29 Oliver Heesakkers <o...@heesakkers.info>:
> > Op zondag 28 augustus 2011 11:04:42 schreef Martijn van Exel:
> >> 2011/8/28 Nico Witteman <n...@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.
>
> 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.
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.
>
> 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.
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.
>
> > Het is echter wel zaak om hiermee aan de gang te gaan en bezig te
> > blijven, want het zou zonde zijn als we uiteindelijk helemaal niets met
> > deze databron doen.
>
> We kunnen natuurlijk wel allerlei andere dingen met de BAG-gegevens
> doen. We kunnen tools maken die kijken waar we straten missen. We
> kunnen tools maken die ons erop attenderen dat er in een bepaald
> gebied veel nieuwe adressen zijn bijgekomen: tijd om er eens langs te
> gaan met een mapping party.
Als je die data toch hebt, importeer hem, dan kan de mapping-party zich
helemaal richten op wegen, landuses en POI's. We lopen natuurlijk liever voor
op Bing dan dat we er van overtrekken.
--
Oliver
_______________________________________________
Talk-nl mailing list
Talk-nl@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-nl
