Re: [OSM-talk-nl] BAG (Was: Diverse vragen)
Dirk, Goede nieuwe argumenten in de discussie. Je eerste argument is bedacht vanuit een gebruikersstandpunt. Ik vind dat we uit moeten gaan van de eigen kracht; wat definieert ons als OpenStreetMap ten opzichte van andere databoeren. Als we ons gaan laten leiden door een specifieke groep 'afnemers' dan gaat onze uniciteit verloren. Bovendien klopt het niet -- er is geen sprake van enige regionale consistentie van dekking van adressen of zelfs maar adresranges in OSM. Een potentiële gebruiker zal dus hoe dan ook de data-situatie per regio moeten bekijken en hun software en dataverwerking daarop aan moeten passen. Je tweede argument vóór de import is sterk. Wat motiveert mappers om dat soort informatie in te brengen als het gewoon op straat ligt? Niet veel mensen zullen nog huisnummers gaan invoeren.. Daar is geen eer meer aan te behalen. Er komt dan een soort kunstmatige scheiding tussen wat nog interessant is om te mappen en wat niet meer, omdat die data er al is èn er geen toegevoegde waarde is in het 'warm' mappen. Als de ontwikkelingen zo doorgaan ligt straks alle overheidsdata op straat en heeft OSM zichzelf helemaal overbodig gemaakt voor wat betreft de topografie. Dus dan maar opslokken en verbeteren of gebruiken als inspiratie? Ik zie het als een groot dilemma! En daarom goed dat we erover discussiëren. Martijn 2011/8/30 : > - ontwikkel een procedure voor import en up-to-date houden van gebouwen en > adressen uit BAG rekening houdend met edits van mappers Je hebt mijn reserveringen gelezen over de (on)mogelijkheden omtrent dit vraagstuk. Ik wil mijn ideeen graag inbrengen als die werkgroep er komt. Let op voor eindeloos polderen: een werkgroep moet een leider, een trekker hebben. Niet alleen maar deelnemers. Ik ben niet meer in de positie om zo'n rol te vervullen, maar misschien kun jij dat dan doen. Veel succces hoe dan ook. -- martijn van exel schaaltreinen.nl ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] BAG (Was: Diverse vragen)
Dirk, > Wat mij betreft graag een werkgroep oprichten die in eerste instantie 2 > vragen meekrijgt: > - ontwikkel een procedure voor import en up-to-date houden van gebouwen en > adressen uit BAG rekening houdend met edits van mappers > - ga na welke mogelijkheden de BAG-licentie biedt, hoe we praktisch bij de > data komen > > En dit dan weer hier terugkoppelt alvorens het ook daadwerkelijk te > bouwen. > > Ik wil deel van de werkgroep zijn. Wie meer? Wil ik ook wel. Ik kan nog wel ergens een uurtje per week afsnoepen (of een paar meer). Christ van Willegen ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] BAG (Was: Diverse vragen)
Er zijn twee belangrijke redenen voor de import: 1. internationale applicaties zoals smartphone-navigatie en b.v. onderzoekstoepassingen verwachten adressen en gebouwen in de dataset, niet apart. Niemand gaat speciaal voor Nederland andere code maken. 2. het is nutteloze bezigheidstherapie voor mappers om gebouwen en huisnummers in te tekenen die al lang beschikbaar zijn. Mijn tijd en energie wil ik liever kwijt in bijhouden van nieuwe ontwikkelingen, taggen van gebruik van de gebouwen etc Wat mij betreft graag een werkgroep oprichten die in eerste instantie 2 vragen meekrijgt: - ontwikkel een procedure voor import en up-to-date houden van gebouwen en adressen uit BAG rekening houdend met edits van mappers - ga na welke mogelijkheden de BAG-licentie biedt, hoe we praktisch bij de data komen En dit dan weer hier terugkoppelt alvorens het ook daadwerkelijk te bouwen. Ik wil deel van de werkgroep zijn. Wie meer? Groeten, Dirk Dirk Bussche Senior Adviseur Geografische Toepassingen T +31 (0)570 666 830 ▪ E dbuss...@goudappel.nl (aanwezig op kantoor: maandag, dinsdag en woensdag) Goudappel Coffeng ▪ Snipperlingsdijk 4 ▪ 7417 BJ Deventer ▪ Postbus 161 ▪ 7400 AD Deventer ▪ The Netherlands ▪ www.goudappel.nl Goudappel Coffeng BV is gevestigd in Deventer, Den Haag, Eindhoven, Leeuwarden en Amsterdam __ Disclaimer De informatie opgenomen in dit bericht kan vertrouwelijk zijn en is uitsluitend bestemd voor de geadresseerde. Indien u dit bericht onterecht ontvangt, wordt u verzocht de inhoud niet te gebruiken en de afzender direct te informeren door het bericht te retourneren. De afzender sluit iedere aansprakelijkheid uit die voortvloeit uit elektronische verzending. ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] BAG (Was: Diverse vragen)
2011/8/29 Oliver Heesakkers : > Op maandag 29 augustus 2011 14:42:29 schreef Martijn van Exel: >> I2011/8/29 Oliver Heesakkers : >> > Op zondag 28 augustus 2011 11:04:42 schreef Martijn van Exel: >> >> 2011/8/28 Nico Witteman : >> >> >(...) >> >> > >> >> > 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
Re: [OSM-talk-nl] BAG (Was: Diverse vragen)
2011/8/29 drek : > Op 29-08-11 22:42, Martijn van Exel schreef: >> >> 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. > > Dit snap ik niet... BAG-data verouderen, maar dat doet 3dShapes toch ook? > Mijn vraag is dan ook: zijn BAG-data beter (nauwkeuriger, gedetailleerder) > dan 3dShapes? Hoe veel moeite is het om de data in te passen? Ja, BAG-data is beter (recenter, betere geometrie, veel meer atribuut-data). En inderdaad, het probleem met verouderende data treft 3DShapes eveneens. Kijk maar eens welk percentage van de 3DShapes-data nog nooit is aangeraakt sinds de import. Datzelfde geldt trouwens in mindere mate voor de AND-gegevens. De vraag is: beter (steeds) oude data dan géén data? Dat moet je je per dataset afvragen. -- martijn van exel schaaltreinen.nl ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] BAG (Was: Diverse vragen)
2011/8/29 Lennard : > On 29-8-2011 23:44, Floris Looijesteijn wrote: >> >> ik zie wel mogelijkheden voor een update script. >> ik zeg niet dat ik het ga maken :) maar het is wel mogelijk. > > Inderdaad, dat lijkt me ook. Een BAG ID is het meest voor de hand liggende, > maar ook een vergelijking op geometrie kan. Je krijgt te maken met > onaangeraakte objecten en aangepaste objecten. Bij die laatste hangt het dan > weer af van wat er aangepast is: tags of vorm. > Yep, een update-script kan, maar de crux is hoe je beslist welke updates voorrang genieten en welke criteria je daarvoor aanhoudt. Dat is heel lastig omdat de meetbare grootte van de aanpassing tussen twee BAG-versies niet evenredig hoeft te zijn met de 'waarde' ervan. Hoe wil je dat oplossen? -- martijn van exel schaaltreinen.nl ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] BAG (Was: Diverse vragen)
Op maandag 29 augustus 2011 14:42:29 schreef Martijn van Exel: > I2011/8/29 Oliver Heesakkers : > > Op zondag 28 augustus 2011 11:04:42 schreef Martijn van Exel: > >> 2011/8/28 Nico Witteman : > >> >(...) > >> > > >> > 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: dat
Re: [OSM-talk-nl] BAG (Was: Diverse vragen)
Op 29-08-11 22:42, Martijn van Exel schreef: 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. Dit snap ik niet... BAG-data verouderen, maar dat doet 3dShapes toch ook? Mijn vraag is dan ook: zijn BAG-data beter (nauwkeuriger, gedetailleerder) dan 3dShapes? Hoe veel moeite is het om de data in te passen? Groeten, André ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] BAG (Was: Diverse vragen)
ik zat er zelfs aan te denken om de bag-id - osm-id koppeling buiten de osm database te houden om vervuiling tegen te gaan. maar mogelijkheden genoeg... gr, floris 2011/8/29 Lennard : > On 29-8-2011 23:44, Floris Looijesteijn wrote: >> >> ik zie wel mogelijkheden voor een update script. >> ik zeg niet dat ik het ga maken :) maar het is wel mogelijk. > > Inderdaad, dat lijkt me ook. Een BAG ID is het meest voor de hand liggende, > maar ook een vergelijking op geometrie kan. Je krijgt te maken met > onaangeraakte objecten en aangepaste objecten. Bij die laatste hangt het dan > weer af van wat er aangepast is: tags of vorm. > > -- > Lennard > > ___ > Talk-nl mailing list > Talk-nl@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-nl > ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] BAG (Was: Diverse vragen)
On 29-8-2011 23:44, Floris Looijesteijn wrote: ik zie wel mogelijkheden voor een update script. ik zeg niet dat ik het ga maken :) maar het is wel mogelijk. Inderdaad, dat lijkt me ook. Een BAG ID is het meest voor de hand liggende, maar ook een vergelijking op geometrie kan. Je krijgt te maken met onaangeraakte objecten en aangepaste objecten. Bij die laatste hangt het dan weer af van wat er aangepast is: tags of vorm. -- Lennard ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] BAG (Was: Diverse vragen)
ik zie wel mogelijkheden voor een update script. ik zeg niet dat ik het ga maken :) maar het is wel mogelijk. groet, floris 2011/8/29 Martijn van Exel : > I2011/8/29 Oliver Heesakkers : >> Op zondag 28 augustus 2011 11:04:42 schreef Martijn van Exel: >>> 2011/8/28 Nico Witteman : >>> >(...) >>> >>> > 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. > > 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? > > 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 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 > ge
Re: [OSM-talk-nl] BAG (Was: Diverse vragen)
I2011/8/29 Oliver Heesakkers : > Op zondag 28 augustus 2011 11:04:42 schreef Martijn van Exel: >> 2011/8/28 Nico Witteman : >> >(...) >> >> > 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. 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? 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 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. -- martijn van exel schaaltreinen.nl ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] BAG (Was: Diverse vragen)
Er zijn voor en tegenstanders :) Ik ben zelf voorstander van zoveel mogelijk data in OpenStreetMap, als het tenminste nuttig is voor navigeren. En daar lijkt me in dit geval geen twijfel over mogelijk. Ik voer trouwens ook vrijwel geen huisnummers meer in tegenwoordig... Groet, Floris 2011/8/29 Oliver Heesakkers : > Op zondag 28 augustus 2011 11:04:42 schreef Martijn van Exel: >> 2011/8/28 Nico Witteman : >> >(...) >> >> > 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 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. > > ___ > Talk-nl mailing list > Talk-nl@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-nl > ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] BAG (Was: Diverse vragen)
Op zondag 28 augustus 2011 11:04:42 schreef Martijn van Exel: > 2011/8/28 Nico Witteman : > >(...) > > > 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 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. ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
