[OSM-talk-nl] Hack weekend Essen
Ha allemaal, Een herinnering: over twee weken is er een OSM hack weekend in Essen, in het geweldige LinuxHotel. Ik heb de details al eens eerder gepost, lees nog eens na op http://wiki.openstreetmap.org/wiki/Hack_Weekend_Essen_June_2011 Er is beperkte sponsoring waardoor de kosten redelijk laag kunnen blijven. Groet, -- Martijn van Exel http://about.me/mvexel ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] BAG
Hoi Jeroen en anderen, Die samenvatting in jouw mail van een paar maanden terug was een hele goeie. Ik heb nu een wiki-pagina gemaakt[1] waarin ik wat info over de BAG op een rijtje zet. Kan nog wel aanvullingen gebruiken, vooral op technisch vlak (bestandsformaat). Voor de geïnteresseerden heb ik hier een BAG-extract liggen. Mijn belangrijkste bezwaar tegen imports op grote schaal, en dus ook deze potentiële import, is dat het dode data is: niet gecreëerd door de gebruikers en zoveel dat het niet bij te houden is door de relatief kleine community in Nederland. OpenStreetMap wordt van een community-project een verzamelbak voor open databronnen. Dat vind ik geen aantrekkelijk idee. Hoe ziet de OSM-data er over vijf jaar uit in Nederland? 95% geïmporteerde data die vooral stof vangt en nog een klein beetje community-bijdragen? Wat een import als deze dan toch de moeite waard maakt is dat OSM serieuzer genomen kan worden als alternatief voor andere geodatabronnen. Dat zag je al na de AND-import, en nu ook weer bij 3dshapes. Hoe moet die afweging volgens jullie uitvallen? Trouwens, is die Nijmegen-import ergens gedocumenteerd? Ik kon op de wiki niks vinden. [1] http://wiki.openstreetmap.org/wiki/BAG 2011/6/1 Jeroen Muris jer...@tweejee.net: Hallo, De BAG is voor OSM niet helemaal nieuw. Zie bijvoorbeeld de BAG data van de gemeente Nijmegen [1]. Ik heb nog geen andere gemeentes gevonden die de BAG aan OSM hebben toegevoegd. Gebruik van de BAG en andere gemeentelijke gegevens is OSM is eerder ter sprake gekomen. Zelf heb ik naar aanleiding daarvan geprobeerd een soort samenvatting van mijn bevindingen te geven [2], onder andere over de BAG. Misschien zitten daar nog aanknopingspunten in voor anderen. [1] http://www.openstreetmap.org/?lat=51.844316lon=5.865084zoom=18layers=M [2] http://lists.openstreetmap.org/pipermail/talk-nl/2010-December/012185.html Groet, J-. Op 31-5-2011 23:13, Floris Looijesteijn schreef: Dag allemaal, Allereerst, als je nog niet weet wat de BAG is: http://bag.vrom.nl/ Als huisnummerfan is dit dus een machtig interessante dataset. Milo postte gister dit plaatje: http://yfrog.com/z/gyvhvpp (volgens mij beleefde ik m'n eerste orgosme bij het zien daarvan). Is het misschien een idee om met alle belanghebbenden eens een keer bij elkaar te gaan zitten (fysiek of conference call / irc) om de mogelijkheden van de BAG door te nemen? Groet, Floris ___ 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 -- Martijn van Exel http://about.me/mvexel ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] BAG
On Wed, Jun 01, 2011 at 12:59:13PM +0200, Martijn van Exel wrote: || Mijn belangrijkste bezwaar tegen imports op grote schaal, en dus ook || deze potentiële import, is dat het dode data is: niet gecreëerd door || de gebruikers en zoveel dat het niet bij te houden is door de relatief || kleine community in Nederland. OpenStreetMap wordt van een || community-project een verzamelbak voor open databronnen. Dat vind ik || geen aantrekkelijk idee. Hoe ziet de OSM-data er over vijf jaar uit in || Nederland? 95% geïmporteerde data die vooral stof vangt en nog een || klein beetje community-bijdragen? || || Wat een import als deze dan toch de moeite waard maakt is dat OSM || serieuzer genomen kan worden als alternatief voor andere || geodatabronnen. Dat zag je al na de AND-import, en nu ook weer bij || 3dshapes. Ik merk juist het omgekeerde. Nadat er imports zijn gemaakt, is er plotseling nog veel meer werk dat je als mapper eenvoudig kunt doen, omdat het kader er plotseling een stuk completer uitziet. Mijn voorbeeld: nadat de 3dshapes import in mijn buurt was langsgekomen ben ik heel rap begonnen om huisnummers te verzamelen en in te voeren. Voor de 3dshapes import had ik zelf de locaties van de huizenblokken ook moeten invoeren --een K-klus-- maar nu hoef ik alleen maar nummertjes te mappen en de huizenblokjes daarvan te voorzien. Stuk handiger. Ciao. Vincent. -- Vincent Zweije vinc...@zweije.nl | If you're flamed in a group you http://www.xs4all.nl/~zweije/ | don't read, does anybody get burnt? [Xhost should be taken out and shot] |-- Paul Tomblin on a.s.r. signature.asc Description: Digital signature ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] BAG
2011/6/1 Vincent Zweije vinc...@zweije.nl: Ik merk juist het omgekeerde. Nadat er imports zijn gemaakt, is er plotseling nog veel meer werk dat je als mapper eenvoudig kunt doen, omdat het kader er plotseling een stuk completer uitziet. Met Vincent eens, 'een paar huisnummertjes en een camera' is een stuk makkelijker dan alle straten, huizen etc. mappen... Christ van Willegen -- 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0 ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] BAG
On Wed, Jun 01, 2011 at 01:26:29PM +0200, Christ van Willegen wrote: || 2011/6/1 Vincent Zweije vinc...@zweije.nl: || Nadat er imports zijn gemaakt, is er plotseling nog veel meer werk dat || je als mapper eenvoudig kunt doen, omdat het kader er plotseling een || stuk completer uitziet. || || Met Vincent eens, 'een paar huisnummertjes en een camera' is een stuk || makkelijker dan alle straten, huizen etc. mappen... Aan de andere kant moeten natuurlijk ook die shapes zelf worden bijgehouden, maar ook daar merk ik dat ik zonder veel weerstand de shapes die niet kloppen aanpas, makkelijker dan dat ik ze nieuw aangemaakt zou hebben. -- Vincent Zweije vinc...@zweije.nl | If you're flamed in a group you http://www.xs4all.nl/~zweije/ | don't read, does anybody get burnt? [Xhost should be taken out and shot] |-- Paul Tomblin on a.s.r. signature.asc Description: Digital signature ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] BAG
Aan de andere kant moeten natuurlijk ook die shapes zelf worden bijgehouden, maar ook daar merk ik dat ik zonder veel weerstand de shapes die niet kloppen aanpas, makkelijker dan dat ik ze nieuw aangemaakt zou hebben. En als er een update van de bron data komt. Hoe wordt OSM dan synchroon gehouden. Of zijn we enkel blij met de initiële data set? Als ik het goed heb zijn de gemeenten verplicht om de BAG up2date te houden. Als we nu de BAG gaan importeren lopen we dus eigenlijk al weer achter. Peter. ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] BAG
Er zit aan elke gebouw een id, die nemen we gewoon mee. Net als de AND id's, die we achteraf nooit gebruikt hebben. Gr, Floris 2011/6/1 Peter Peterse pe...@peterse-uithuizen.com: Aan de andere kant moeten natuurlijk ook die shapes zelf worden bijgehouden, maar ook daar merk ik dat ik zonder veel weerstand de shapes die niet kloppen aanpas, makkelijker dan dat ik ze nieuw aangemaakt zou hebben. En als er een update van de bron data komt. Hoe wordt OSM dan synchroon gehouden. Of zijn we enkel blij met de initiële data set? Als ik het goed heb zijn de gemeenten verplicht om de BAG up2date te houden. Als we nu de BAG gaan importeren lopen we dus eigenlijk al weer achter. Peter. ___ 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
2011/6/1 Vincent Zweije vinc...@zweije.nl: On Wed, Jun 01, 2011 at 01:26:29PM +0200, Christ van Willegen wrote: || 2011/6/1 Vincent Zweije vinc...@zweije.nl: || Nadat er imports zijn gemaakt, is er plotseling nog veel meer werk dat || je als mapper eenvoudig kunt doen, omdat het kader er plotseling een || stuk completer uitziet. || || Met Vincent eens, 'een paar huisnummertjes en een camera' is een stuk || makkelijker dan alle straten, huizen etc. mappen... Aan de andere kant moeten natuurlijk ook die shapes zelf worden bijgehouden, maar ook daar merk ik dat ik zonder veel weerstand de shapes die niet kloppen aanpas, makkelijker dan dat ik ze nieuw aangemaakt zou hebben. Ha Vincent, da's ook een goed punt inderdaad. Zou interessant zijn om dit eens wat te analyseren: waar ( thematisch / geografisch) zien we een groei in activiteit na een import? In mijn beleving was het altijd zo dat er twee soorten mappers bestaan: de mensen die van opvullen houden en de mensen die van aanvullen houden. Dus de mappers die graag pionieren op een blanco kaart en de mappers die liever in een al wat gevulde kaart werken. Maar volgens mij is dat een te grote versimpeling van de werkelijkheid. Ik val zelf bijvoorbeeld al meteen niet in een van mijn eigen categorieen... -- Martijn van Exel http://about.me/mvexel ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] BAG
2011/6/1 Floris Looijesteijn o...@floris.nu: Er zit aan elke gebouw een id, die nemen we gewoon mee. Net als de AND id's, die we achteraf nooit gebruikt hebben. Gr, Floris Dat is de makkelijke kant van het verhaal. De uitdagingen liggen ietsje onder de oppervlakte (maar niet ver): * Wat doen we met alle panden plus hun attributen die al in OSM zitten? Dit [1] wil je toch niet al te veel met de hand gaan doen. * Wat gebeurt er met de menselijke updates tussen twee import-updates in? * Als een pand volgens de import niet meer bestaat en volgens de community nog wel, wie heeft er dan gelijk? [1] http://www.openstreetmap.org/browse/changeset/8309041 -- Martijn van Exel http://about.me/mvexel ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] BAG
Dat was ook de belangrijkste reden om het nu op de agenda te zetten. Wat is marginaal? Bv. 100 euro per kwartaal kunnen we vast wel opbrengen. Maar dat is waarschijnlijk op de zaken vooruitlopen... Gr, Floris 2011/6/1 Cartinus carti...@xs4all.nl: Waar ik dan alleen bang voor ben is dit: quote Tot 1 juli 2011 is de BAG als bestand door iedereen gratis op te vragen. Daarna worden waarschijnlijk 'marginale verstrekkingskosten' gevraagd aan private gebruikers. /quote Dat betekent dat de vrijwilliger die de data wil updaten daar niet alleen een hoop tijd en moeite in moet stekken, maar ook nog eens de portemonnee moet openen. -- m.v.g., Cartinus On Wednesday 01 June 2011 13:54:28 Floris Looijesteijn wrote: Er zit aan elke gebouw een id, die nemen we gewoon mee. Net als de AND id's, die we achteraf nooit gebruikt hebben. Gr, Floris 2011/6/1 Peter Peterse pe...@peterse-uithuizen.com: Aan de andere kant moeten natuurlijk ook die shapes zelf worden bijgehouden, maar ook daar merk ik dat ik zonder veel weerstand de shapes die niet kloppen aanpas, makkelijker dan dat ik ze nieuw aangemaakt zou hebben. En als er een update van de bron data komt. Hoe wordt OSM dan synchroon gehouden. Of zijn we enkel blij met de initiële data set? Als ik het goed heb zijn de gemeenten verplicht om de BAG up2date te houden. Als we nu de BAG gaan importeren lopen we dus eigenlijk al weer achter. Peter. ___ 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
Wat in de hele OSM strategy ontbreekt is een update strategie. Deze BAG data heeft inderdaad de potentie om de hele community te overspoelen met update werk . Aan de andere kant wordt de BAG data ook bijgewerkt door de overheid. Als we een geautomatiseerd systeem hadden om updates in OSM te laden, dan zou deze hoeveelheid niet zo erg zijn. (overigens : is het echt zoveel meer dan de 3d importen?) Op kleine schaal zie je dat met bijvoorbeeld de fietsroutes. Als er iets veranderd is het maar de vraag of dat door iemand van ons wordt opgemerkt. Daar zouden we ons de komende jaren op moeten richten: Hoe houden we de data up-to-date ? Gert Gremmen - Openstreetmap.nl (alias: cetest) Before printing, think about the environment. -Oorspronkelijk bericht- Van: Vincent Zweije [mailto:vinc...@zweije.nl] Verzonden: Wednesday, June 01, 2011 1:34 PM Aan: talk-nl@openstreetmap.org Onderwerp: Re: [OSM-talk-nl] BAG On Wed, Jun 01, 2011 at 01:26:29PM +0200, Christ van Willegen wrote: || 2011/6/1 Vincent Zweije vinc...@zweije.nl: || Nadat er imports zijn gemaakt, is er plotseling nog veel meer werk || dat je als mapper eenvoudig kunt doen, omdat het kader er || plotseling een stuk completer uitziet. || || Met Vincent eens, 'een paar huisnummertjes en een camera' is een || stuk makkelijker dan alle straten, huizen etc. mappen... Aan de andere kant moeten natuurlijk ook die shapes zelf worden bijgehouden, maar ook daar merk ik dat ik zonder veel weerstand de shapes die niet kloppen aanpas, makkelijker dan dat ik ze nieuw aangemaakt zou hebben. -- Vincent Zweije vinc...@zweije.nl | If you're flamed in a group you http://www.xs4all.nl/~zweije/ | don't read, does anybody get burnt? [Xhost should be taken out and shot] |-- Paul Tomblin on a.s.r. ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
[OSM-talk-nl] Betr: Re: BAG
Wat is marginaal? Bv. 100 euro per kwartaal kunnen we vast wel opbrengen. Maar dat is waarschijnlijk op de zaken vooruitlopen... De definitieve licentie is nog niet beschikbaar, maar zoals ik het begrijp zal het toegestaan zijn de data door te leveren. Alleen het ophalen bij het BAG-loket kost geld. De workflow moet wat mij betreft dus zo uitzien dat een van de bevriende bedrijven (geodan, goudappel) die de data sowieso nodig hebben die voor de community gratis beschikbaar maken. Groeten, Dirk ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] BAG
Gert et al, 2011/6/1 ce-test, qualified testing bv - Gert Gremmen g.grem...@cetest.nl: Wat in de hele OSM strategy ontbreekt is een update strategie. Deze BAG data heeft inderdaad de potentie om de hele community te overspoelen met update werk . Aan de andere kant wordt de BAG data ook bijgewerkt door de overheid. Als we een geautomatiseerd systeem hadden om updates in OSM te laden, dan zou deze hoeveelheid niet zo erg zijn. (overigens : is het echt zoveel meer dan de 3d importen?) Op kleine schaal zie je dat met bijvoorbeeld de fietsroutes. Als er iets veranderd is het maar de vraag of dat door iemand van ons wordt opgemerkt. Daar zouden we ons de komende jaren op moeten richten: Hoe houden we de data up-to-date ? Dit was ook mijn zorg. Niet alleen voor de updates op zich, wat al een hoop werk is (ze komen maandelijks uit) maar ook hoe om te gaan met 'echte' edits door de community op gebouwen, zie mijn eerdere mail. Dit speelde met AND niet omdat het een eenmalige update was, en voor 3DShapes misschien in mindere mate omdat veel van het grondgebruik sowieso niet snel door de community in kaart zou worden gebracht: moeilijk en lage prioriteit, maar het ziet er nu wel fraai uit. Maar ook deze data veroudert op den duur. We moeten wat mij betreft ook onder ogen zien dat de BAG misschien niet per se in de OSM-database zou hoeven te worden geimporteerd. Het kan ook als afzonderlijke laag worden weergegeven. Importeren moet niet dogmatisch worden. Het is niet van: er is vrije data, *dus* het moet in OSM. -- Martijn van Exel http://about.me/mvexel ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] BAG
On Wed, Jun 01, 2011 at 02:04:01PM +0200, Martijn van Exel wrote: || 2011/6/1 Floris Looijesteijn o...@floris.nu: || Er zit aan elke gebouw een id, die nemen we gewoon mee. || Net als de AND id's, die we achteraf nooit gebruikt hebben. || Dat is de makkelijke kant van het verhaal. De uitdagingen liggen || ietsje onder de oppervlakte (maar niet ver): || * Wat doen we met alle panden plus hun attributen die al in OSM || zitten? Dit [1] wil je toch niet al te veel met de hand gaan doen. || * Wat gebeurt er met de menselijke updates tussen twee import-updates in? || * Als een pand volgens de import niet meer bestaat en volgens de || community nog wel, wie heeft er dan gelijk? De ultieme oplossing is, net als in (distributed) version control systems, het (automatisch) mergen van wijzigingen. Daarvoor moet je de wijzigingen die door mappers met de hand zijn aangebracht als precies dat: wijzigingen, representeren. Vervolgens moet je hetzelfde doen met de nieuwe BAG data: representeren als wijzigingen. Daarna kun je alle wijzigingen die niet conflicteren automatisch doorvoeren. De wijzigingen die wel conflicteren moeten met de hand worden uitgezocht. Daarin ligt het grootste probleem. Je kunt dit minimaliseren door slimme representaties van wijzigingen uit te vinden, die weinig conflicten opleveren. Uiteindelijk zal er altijd handwerk overblijven; daar kom je niet onderuit. Helemaal mooi zou het zijn als de conflicten ook in OSM kunnen worden opgeslagen, zodat mappers ze op hun gemakje kunnen oplossen. One can dream... Ciao. Vincent. -- Vincent Zweije vinc...@zweije.nl | If you're flamed in a group you http://www.xs4all.nl/~zweije/ | don't read, does anybody get burnt? [Xhost should be taken out and shot] |-- Paul Tomblin on a.s.r. signature.asc Description: Digital signature ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
[OSM-talk-nl] BAG = BAGGER ?
De locatie in Rotterdam waar mijn bedrijfspand staat aan de Kiotoweg heet al sinds het pand is gebouwd Kiotoweg. Oh ja, ik ben eigenaar van het pand en de straat heet echt Kiotoweg in het kadaster. Dus niet: de Kiotoweg heet gewoon nog Montevideostraat in BAG Verder staan er nog 2 straten in waarvan de post altijd onbezorgd blijft... Nu heb ik lang gedacht dat dat een easter egg was van de kaartleveranciers, en dat ergens in de catacomben van de BV Nederland de juist naam wel bekend zou zijn, en dat BAG toch wel de juiste data zou hebben Kijk maar eens op de site van Geodan , héé jammer, geen permalink One can dream , indeed ! Gert Gremmen - Openstreetmap.nl (alias: cetest) Before printing, think about the environment. -Oorspronkelijk bericht- Van: Vincent Zweije [mailto:vinc...@zweije.nl] Verzonden: Wednesday, June 01, 2011 2:56 PM Aan: OpenStreetMap NL discussion list Onderwerp: Re: [OSM-talk-nl] BAG On Wed, Jun 01, 2011 at 02:04:01PM +0200, Martijn van Exel wrote: || 2011/6/1 Floris Looijesteijn o...@floris.nu: || Er zit aan elke gebouw een id, die nemen we gewoon mee. || Net als de AND id's, die we achteraf nooit gebruikt hebben. || Dat is de makkelijke kant van het verhaal. De uitdagingen liggen || ietsje onder de oppervlakte (maar niet ver): || * Wat doen we met alle panden plus hun attributen die al in OSM || zitten? Dit [1] wil je toch niet al te veel met de hand gaan doen. || * Wat gebeurt er met de menselijke updates tussen twee import-updates in? || * Als een pand volgens de import niet meer bestaat en volgens de || community nog wel, wie heeft er dan gelijk? De ultieme oplossing is, net als in (distributed) version control systems, het (automatisch) mergen van wijzigingen. Daarvoor moet je de wijzigingen die door mappers met de hand zijn aangebracht als precies dat: wijzigingen, representeren. Vervolgens moet je hetzelfde doen met de nieuwe BAG data: representeren als wijzigingen. Daarna kun je alle wijzigingen die niet conflicteren automatisch doorvoeren. De wijzigingen die wel conflicteren moeten met de hand worden uitgezocht. Daarin ligt het grootste probleem. Je kunt dit minimaliseren door slimme representaties van wijzigingen uit te vinden, die weinig conflicten opleveren. Uiteindelijk zal er altijd handwerk overblijven; daar kom je niet onderuit. Helemaal mooi zou het zijn als de conflicten ook in OSM kunnen worden opgeslagen, zodat mappers ze op hun gemakje kunnen oplossen. One can dream... Ciao. Vincent. -- Vincent Zweije vinc...@zweije.nl | If you're flamed in a group you http://www.xs4all.nl/~zweije/ | don't read, does anybody get burnt? [Xhost should be taken out and shot] |-- Paul Tomblin on a.s.r. ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] BAG
Martijn, je wilt niet weten hoeveel verschillen er zijn tussen de 3D gebouwen en de BING foto's. En dan heb ik het alleen maar over de toegevoegde/gewijzigde gebouwen waarvan je gevoeglijk kunt aannemen dat de BING nieuwer is. Gert Gremmen - Openstreetmap.nl (alias: cetest) Before printing, think about the environment. -Oorspronkelijk bericht- Van: Martijn van Exel [mailto:m...@rtijn.org] Verzonden: Wednesday, June 01, 2011 2:49 PM Aan: OpenStreetMap NL discussion list Onderwerp: Re: [OSM-talk-nl] BAG Gert et al, 2011/6/1 ce-test, qualified testing bv - Gert Gremmen g.grem...@cetest.nl: Wat in de hele OSM strategy ontbreekt is een update strategie. Deze BAG data heeft inderdaad de potentie om de hele community te overspoelen met update werk . Aan de andere kant wordt de BAG data ook bijgewerkt door de overheid. Als we een geautomatiseerd systeem hadden om updates in OSM te laden, dan zou deze hoeveelheid niet zo erg zijn. (overigens : is het echt zoveel meer dan de 3d importen?) Op kleine schaal zie je dat met bijvoorbeeld de fietsroutes. Als er iets veranderd is het maar de vraag of dat door iemand van ons wordt opgemerkt. Daar zouden we ons de komende jaren op moeten richten: Hoe houden we de data up-to-date ? Dit was ook mijn zorg. Niet alleen voor de updates op zich, wat al een hoop werk is (ze komen maandelijks uit) maar ook hoe om te gaan met 'echte' edits door de community op gebouwen, zie mijn eerdere mail. Dit speelde met AND niet omdat het een eenmalige update was, en voor 3DShapes misschien in mindere mate omdat veel van het grondgebruik sowieso niet snel door de community in kaart zou worden gebracht: moeilijk en lage prioriteit, maar het ziet er nu wel fraai uit. Maar ook deze data veroudert op den duur. We moeten wat mij betreft ook onder ogen zien dat de BAG misschien niet per se in de OSM-database zou hoeven te worden geimporteerd. Het kan ook als afzonderlijke laag worden weergegeven. Importeren moet niet dogmatisch worden. Het is niet van: er is vrije data, *dus* het moet in OSM. -- Martijn van Exel http://about.me/mvexel ___ 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
2011/6/1 Vincent Zweije vinc...@zweije.nl: On Wed, Jun 01, 2011 at 02:04:01PM +0200, Martijn van Exel wrote: || 2011/6/1 Floris Looijesteijn o...@floris.nu: || Er zit aan elke gebouw een id, die nemen we gewoon mee. || Net als de AND id's, die we achteraf nooit gebruikt hebben. || Dat is de makkelijke kant van het verhaal. De uitdagingen liggen || ietsje onder de oppervlakte (maar niet ver): || * Wat doen we met alle panden plus hun attributen die al in OSM || zitten? Dit [1] wil je toch niet al te veel met de hand gaan doen. || * Wat gebeurt er met de menselijke updates tussen twee import-updates in? || * Als een pand volgens de import niet meer bestaat en volgens de || community nog wel, wie heeft er dan gelijk? De ultieme oplossing is, net als in (distributed) version control systems, het (automatisch) mergen van wijzigingen. Daarvoor moet je de wijzigingen die door mappers met de hand zijn aangebracht als precies dat: wijzigingen, representeren. Vervolgens moet je hetzelfde doen met de nieuwe BAG data: representeren als wijzigingen. Daarna kun je alle wijzigingen die niet conflicteren automatisch doorvoeren. De wijzigingen die wel conflicteren moeten met de hand worden uitgezocht. Daarin ligt het grootste probleem. Je kunt dit minimaliseren door slimme representaties van wijzigingen uit te vinden, die weinig conflicten opleveren. Uiteindelijk zal er altijd handwerk overblijven; daar kom je niet onderuit. Helemaal mooi zou het zijn als de conflicten ook in OSM kunnen worden opgeslagen, zodat mappers ze op hun gemakje kunnen oplossen. One can dream... Ja dat is inderdaad de ultieme oplossing. Ik heb de vraag maar eens in de groep gegooid bij de GIS-experts op StackExchange[1]. Dat heeft zijdelings te maken met een ander onderwerp waar ik momenteel mee bezig ben: de brakke manier waarop geschiedenis op dit moment in OSM wordt opgeslagen. Omdat ways en relations geen eigen geometrie hebben, zitten er aan het ophalen van alle versies van een way- of relation-object nogal wat haken en ogen[2]. Iets wat in één klap zou kunnen worden opgelost met dit probleem. [1] http://gis.stackexchange.com/questions/10493/how-to-deal-with-versioning-in-openstreetmap [2] http://wiki.openstreetmap.org/wiki/User:MaZderMind/Reading_OSM_History_dumps#The_Problem -- Martijn van Exel http://about.me/mvexel ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] BAG
Quoting Martijn van Exel m...@rtijn.org: In mijn beleving was het altijd zo dat er twee soorten mappers bestaan: de mensen die van opvullen houden en de mensen die van aanvullen houden. Dus de mappers die graag pionieren op een blanco kaart en de mappers die liever in een al wat gevulde kaart werken. Maar volgens mij is dat een te grote versimpeling van de werkelijkheid. Ik val zelf bijvoorbeeld al meteen niet in een van mijn eigen categorieen... Er is in mijn beleving nog een derde categorie mappers, namelijk mensen die graag over mappen praten. Dat verklaart m.i. jouw constatering over jezelf. j/k ;) Frank ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] BAG
On 1-6-2011 15:20, ce-test, qualified testing bv - Gert Gremmen wrote: Martijn, je wilt niet weten hoeveel verschillen er zijn tussen de 3D gebouwen en de BING foto's. En dan heb ik het alleen maar over de toegevoegde/gewijzigde gebouwen waarvan je gevoeglijk kunt aannemen dat de BING nieuwer is. Dan is er nog de derde optie: dat de foto (of 3dShapes) verschoven is. Verder verschilt de 3dShapes data weleens per gemeente, zeker de gebouwen. Waar in de ene gemeente vooral rechthoekjes getekend zijn, zijn bij de andere gemeente dan weer overal ook schuurtjes te zien. Als je in Groningen (stad) kijkt, zie je zelfs dat rijtjeswoningen of -flats als 1 gebouw getekend zijn, maar met wel overal extra nodes, vermoedelijk dus de locatie van de perceelscheidingen/tussenmuren. -- Lennard ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] BAG
Quoting Martijn van Exel m...@rtijn.org: Gert et al, 2011/6/1 ce-test, qualified testing bv - Gert Gremmen g.grem...@cetest.nl: Wat in de hele OSM strategy ontbreekt is een update strategie. Deze BAG data heeft inderdaad de potentie om de hele community te overspoelen met update werk . Aan de andere kant wordt de BAG data ook bijgewerkt door de overheid. Als we een geautomatiseerd systeem hadden om updates in OSM te laden, dan zou deze hoeveelheid niet zo erg zijn. (overigens : is het echt zoveel meer dan de 3d importen?) Op kleine schaal zie je dat met bijvoorbeeld de fietsroutes. Als er iets veranderd is het maar de vraag of dat door iemand van ons wordt opgemerkt. Daar zouden we ons de komende jaren op moeten richten: Hoe houden we de data up-to-date ? Dit was ook mijn zorg. Niet alleen voor de updates op zich, wat al een hoop werk is (ze komen maandelijks uit) maar ook hoe om te gaan met 'echte' edits door de community op gebouwen, zie mijn eerdere mail. Dit speelde met AND niet omdat het een eenmalige update was, en voor 3DShapes misschien in mindere mate omdat veel van het grondgebruik sowieso niet snel door de community in kaart zou worden gebracht: moeilijk en lage prioriteit, maar het ziet er nu wel fraai uit. Maar ook deze data veroudert op den duur. We moeten wat mij betreft ook onder ogen zien dat de BAG misschien niet per se in de OSM-database zou hoeven te worden geimporteerd. Het kan ook als afzonderlijke laag worden weergegeven. Importeren moet niet dogmatisch worden. Het is niet van: er is vrije data, *dus* het moet in OSM. Mee eens. Deze trend is ook enige tijd op talk waar te nemen. Als ik deze kennis ca 1 1/2 jaar geleden had, weet ik niet of ik mij nog wel met volle overgave op de landuse van 3dShapes gestort zou hebben... Waar bijna iedereen het wel over eens is, is dat het community-aspect van OSM veel belangrijker is dan het zijn van een open data-warehouse. Dat betekent ook dat het minder noodzakelijk is om na te denken over een update-strategie. Dat zal altijd lastig geworden. Nieuwe gebruikers zullen zich niks aantrekken van ID's. Het is erg makkelijk om ze te vernaggelen met de huidige editors (bijv. door knippen en mergen van shapes). Niet de schuld van de editors, maar de identificatie van een objectje in OSM is de geometrie zelf (en in mindere mate het OSM ID) en niet een extern ID wat als attribuut eraan hangt. Dat gaat dus conflicten opleveren met systemen die wel ID-gebaseerd zijn, zoals de BAG. Zelfs het OSM ID kan gaan wandelen in de loop van de tijd. Het is geen permanent gegeven. Frank ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] BAG = BAGGER ?
Gert, 2011/6/1 ce-test, qualified testing bv - Gert Gremmen g.grem...@cetest.nl: De locatie in Rotterdam waar mijn bedrijfspand staat aan de Kiotoweg heet al sinds het pand is gebouwd Kiotoweg. Oh ja, ik ben eigenaar van het pand en de straat heet echt Kiotoweg in het kadaster. Dus niet: de Kiotoweg heet gewoon nog Montevideostraat in BAG Verder staan er nog 2 straten in waarvan de post altijd onbezorgd blijft... Nu heb ik lang gedacht dat dat een easter egg was van de kaartleveranciers, en dat ergens in de catacomben van de BV Nederland de juist naam wel bekend zou zijn, en dat BAG toch wel de juiste data zou hebben Dat jouw hoekje van NL er niet correct op staat wil niet zeggen dat het hele bestand bagger is. Nu wil het toeval (ahem) overigens wel dat er behoorlijk wat rommel in het bestand blijkt te zitten, zoals die gekke driehoeken bij jou in de buurt op de kaart. Het lijkt dus verstandig om het bestand eens goed uit te pluizen voordat we met wat dan ook verder gaan. Bij Geodan zijn hier ook al een paar man mee aan de slag. Overigens komt de ondergrondkaart niet uit BAG, daar zitten namelijk geen straten in. De stratenondergrond is van TomTom / TeleAtlas. Dus moet je bij hen zijn voor je straatnamenprobleem ;) Kijk maar eens op de site van Geodan , héé jammer, geen permalink Ik geef de permalink-tip even door, dat zou inderdaad handig zijn. -- Martijn van Exel http://about.me/mvexel ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] BAG = BAGGER ?
BAG = Basis Administratie Gebouwen Zoals de naam al zegt, dan zijn dus gebouwen, geen straten. De stratenachtergrond in de BAG viewer komt niet uit de BAG, maar uit een andere bron. (Ik gok het NWB, Daarvan is de kwaliteit inderdaad lager dan die van OSM.) Als je de moeite neemt om op de gebouwen te klikken, dan zul je zien dat de gebouwen gewoon aan de Kiotoweg staan volgens de BAG. On Wednesday 01 June 2011 15:14:14 ce-test, qualified testing bv - Gert Gremmen wrote: De locatie in Rotterdam waar mijn bedrijfspand staat aan de Kiotoweg heet al sinds het pand is gebouwd Kiotoweg. Oh ja, ik ben eigenaar van het pand en de straat heet echt Kiotoweg in het kadaster. Dus niet: de Kiotoweg heet gewoon nog Montevideostraat in BAG Verder staan er nog 2 straten in waarvan de post altijd onbezorgd blijft... Nu heb ik lang gedacht dat dat een easter egg was van de kaartleveranciers, en dat ergens in de catacomben van de BV Nederland de juist naam wel bekend zou zijn, en dat BAG toch wel de juiste data zou hebben Kijk maar eens op de site van Geodan , héé jammer, geen permalink One can dream , indeed ! Gert Gremmen -- m.v.g., Cartinus ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] BAG
Quoting ce-test, qualified testing bv - Gert Gremmen g.grem...@cetest.nl: Wat in de hele OSM strategy ontbreekt is een update strategie. Deze BAG data heeft inderdaad de potentie om de hele community te overspoelen met update werk . Aan de andere kant wordt de BAG data ook bijgewerkt door de overheid. Als we een geautomatiseerd systeem hadden om updates in OSM te laden, dan zou deze hoeveelheid niet zo erg zijn. (overigens : is het echt zoveel meer dan de 3d importen?) Op kleine schaal zie je dat met bijvoorbeeld de fietsroutes. Als er iets veranderd is het maar de vraag of dat door iemand van ons wordt opgemerkt. Daar zouden we ons de komende jaren op moeten richten: Hoe houden we de data up-to-date ? Er zijn tools waarmee je veranderingen beter kunt volgen, zoals OWL wat door Matt Amos is gemaakt. Hiermee kun je bijv. een RSS feed opvragen met de recente wijzigingen in het gebied. Het werkt beter dan het opvragen van de changes met een bounding box via de main OSM site. Wereldomvattende edits blijven buiten beschouwing, tenzij ze echt binnen het gebied zelf wijzigingen hebben. V.w.b. geautomatiseerd updaten: hier bestaat weerstand tegen en m.i. is dat terecht. Ik wil niet dat het BAG-updatebotje van H@ndigeH@rry OSM in mijn buurt gaat lopen verzieken. Niemand wil dat. De hoeveelheid werk van de initiële upload zal sowieso meer zijn dan de upload van de 3dShapes gebouwen. Dit omdat heel Nederland al voorzien is van gebouwen. Ook zijn gebruikers actief aan de slag gegaan met huisnummers toevoegen, etc. Ik heb dat in mijn wijk en een naburige wijk ook gedaan, in de verwachting dat bijv. de BAG niet geïmporteerd zou worden. Ergens moet je een grens trekken: je wilt als OSM community je niet constant gaan laven aan de (open) data-stroom van de overheid. Je moet je eerst afvragen of het nodig is en wat het oplevert. De BAG-data zou ons i.i.g. adresinformatie opleveren. Als we alleen dit kunnen extraheren, dan zal de import ook makkelijker gaan en voor minder conflicten zorgen. Door een ruimtelijke query erop los te laten, kun je ook gebieden uitsluiten die al zijn voorzien van huisnummers (en deze gebieden aan de mappers daarvan beschikbaar stellen). Eenzelfde werkwijze zou ook voor de footprints van de gebouwen aangehouden kunnen worden. Waar in OSM al gebouwen zitten, zou ook aan lokale mappers ter beschikking gesteld kunnen worden. Voor mij hoeven in OSM de gebouwen niet zo perfect in te zitten als in BAG, aangezien de meeste casual mappers niet met deze nauwkeurigheid werken ;) Frank ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] BAG
Martijn, We moeten wat mij betreft ook onder ogen zien dat de BAG misschien niet per se in de OSM-database zou hoeven te worden geimporteerd. Het kan ook als afzonderlijke laag worden weergegeven. Importeren moet niet dogmatisch worden. Het is niet van: er is vrije data, *dus* het moet in OSM. je hebt gelijk. De reflex vrije data = import is verkeerd. Daarom heb ik ook toen gezegd dat we wegwerk- en filemeldingen er niet in moeten hebben ondanks die vrij beschikbaar zijn. De BAG echter is wel ontzettend waardevol. 1. de kaart ziet visueel zeer volledig uit met alle gebouwen, zeker als er straks ook de hoogte in staat en wij die 3D renderen. 2. indirect krijgen wij volledige huisnummers en vanaf 2010 ook postcodes mee. Heel handig om te routeren. 3. Omgekeerd willen wij die wel kunnen aanpassen. Bijvoorbeeld aanvullende eigenschappen toevoegen (basisschool, winkel, geldautomaat) en natuurlijk fouten verbeteren. 4. wat gebeurt met de huidige gebouwen in osm als iedereen alleen naar de nieuwe extra-laag kijkt? 5. een extra laag is ook jammer voor de wereldwijde integratie: apps uit andere landen die generiek iets met osm-data doen zouden die niet gebruiken. Synchronisatie hoeft volgens mij niet super-moeilijk zijn. De automaat kijkt dan naar het datum van de laatste wijziging. Als de BAG recent heeft gewijzigt wint die, anders OSM. Dit inderdaad per attribuut (en geometry als verzameling van alle nodes is voor het gemak een attribuut). Ook verwijderen is een wijziging die kan winnen. Dus een welbewust weggehaald pand in osm wordt niet indirect via de BAG weer hersteld. Daar waar afwijkingen zijn kunnen wij die als een extra tag (SYNC of zo) expliciet maken zodat plaatselijke mappers dat eventueel op kunnen pakken. Wat dat betreft met Vincent eens. Dit is trouwens een goede oefening voor het NWB straks als die vrij wordt gegeven (ik geef het niet op!). Ook daar willen wij niet zomaar alle goede osm-wegen met slechte NWB-wegen overschrijven, maar er zijn echt wel ook nieuwbouwwijken die in OSM ontbreken en in het NWB wel inzitten. Wie organiseert een chat of skype conferentie hierover, eventueel als voorbereiding voor een fysieke ontmoeting? Groeten, Dirk 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
2011/6/1 stegg...@steggink.org: Quoting Martijn van Exel m...@rtijn.org: [..] We moeten wat mij betreft ook onder ogen zien dat de BAG misschien niet per se in de OSM-database zou hoeven te worden geimporteerd. Het kan ook als afzonderlijke laag worden weergegeven. Importeren moet niet dogmatisch worden. Het is niet van: er is vrije data, *dus* het moet in OSM. Mee eens. Deze trend is ook enige tijd op talk waar te nemen. Als ik deze kennis ca 1 1/2 jaar geleden had, weet ik niet of ik mij nog wel met volle overgave op de landuse van 3dShapes gestort zou hebben... Ik denk dat die energie heel goed besteed is geweest. Iedereeen is het er volgens mij wel over eens dat de kaart er mooier uitziet, en de discussie over imports is levend, mede aangewakkerd door 3dshapes. Bovendien hebben we het kadaster / pbl nog kunnen verleiden tot een uitspraak over de herbruikbaarheid, iets dat ze nooit uit zichzelf hadden gedaan. Waar bijna iedereen het wel over eens is, is dat het community-aspect van OSM veel belangrijker is dan het zijn van een open data-warehouse. Dat betekent ook dat het minder noodzakelijk is om na te denken over een update-strategie. Dat zal altijd lastig geworden. Nieuwe gebruikers zullen zich niks aantrekken van ID's. Het is erg makkelijk om ze te vernaggelen met de huidige editors (bijv. door knippen en mergen van shapes). Niet de schuld van de editors, maar de identificatie van een objectje in OSM is de geometrie zelf (en in mindere mate het OSM ID) en niet een extern ID wat als attribuut eraan hangt. Dat gaat dus conflicten opleveren met systemen die wel ID-gebaseerd zijn, zoals de BAG. Zelfs het OSM ID kan gaan wandelen in de loop van de tijd. Het is geen permanent gegeven. Maar dat maakt het toch *juist* noodzakelijk om erover na te denken? Juist omdat OSM bestaat en groeit bij de gratie van twee heel verschillende bronnen, imports en menselijke bijdrages, is het relevant. De huidige werkelijkheid is dat de data-imports ervoor zorgen dat de basiskaart goed is en blijft, en de menselijke gebruikers zorgen voor dat beetje extra: de fietsroutes en -paden, POIs, allerlei wegkenmerken, attributen voor specifieke doelgroepen... Zo is de situatie niet in de gehele wereld - kijk maar naar onze Oosterburen waar imports geen enkele rol spelen - maar wij hebben hier om te gaan met onze realiteit. En volgens mij hoort die discussie over import-updates daar wel bij. -- Martijn van Exel http://about.me/mvexel ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] BAG = BAGGER ?
Jullie hebben gelijk, maar het woordgrapje was te verleidelijk. Gert Gremmen - Openstreetmap.nl (alias: cetest) Before printing, think about the environment. -Oorspronkelijk bericht- Van: Cartinus [mailto:carti...@xs4all.nl] Verzonden: Wednesday, June 01, 2011 3:55 PM Aan: talk-nl@openstreetmap.org Onderwerp: Re: [OSM-talk-nl] BAG = BAGGER ? BAG = Basis Administratie Gebouwen Zoals de naam al zegt, dan zijn dus gebouwen, geen straten. De stratenachtergrond in de BAG viewer komt niet uit de BAG, maar uit een andere bron. (Ik gok het NWB, Daarvan is de kwaliteit inderdaad lager dan die van OSM.) Als je de moeite neemt om op de gebouwen te klikken, dan zul je zien dat de gebouwen gewoon aan de Kiotoweg staan volgens de BAG. On Wednesday 01 June 2011 15:14:14 ce-test, qualified testing bv - Gert Gremmen wrote: De locatie in Rotterdam waar mijn bedrijfspand staat aan de Kiotoweg heet al sinds het pand is gebouwd Kiotoweg. Oh ja, ik ben eigenaar van het pand en de straat heet echt Kiotoweg in het kadaster. Dus niet: de Kiotoweg heet gewoon nog Montevideostraat in BAG Verder staan er nog 2 straten in waarvan de post altijd onbezorgd blijft... Nu heb ik lang gedacht dat dat een easter egg was van de kaartleveranciers, en dat ergens in de catacomben van de BV Nederland de juist naam wel bekend zou zijn, en dat BAG toch wel de juiste data zou hebben Kijk maar eens op de site van Geodan , héé jammer, geen permalink One can dream , indeed ! Gert Gremmen -- m.v.g., Cartinus ___ 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 = BAGGER ?
2011/6/1 ce-test, qualified testing bv - Gert Gremmen g.grem...@cetest.nl: Jullie hebben gelijk, maar het woordgrapje was te verleidelijk. Ja, wij hebben het hier ook al over het 'speciaal voor de BAG ontwikkelde .GER-formaat' waarin de data is opgeslagen :D -- Martijn van Exel http://about.me/mvexel ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] BAG = BAGGER ?
On 1-6-2011 15:54, Cartinus wrote: BAG = Basis Administratie Gebouwen Zoals de naam al zegt, dan zijn dus gebouwen, geen straten. Bijna goed. :) Basisregistraties Adressen en Gebouwen Dat betekent niet dat er straten instaan, maar wel dat er adresgegevens voor de gebouwen ingevoerd zijn. Dat opent de weg naar nog een andere leuke verificatietool: kijken of een in de BAG genoemde weg inderdaad binnen xxx meter van dat gebouw te vinden is in OSM. Indien niet: vlaggetje op de kaart met hey, is hier alles ok? -- Lennard ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] BAG
On 1-6-2011 16:08, Jeroen Muris wrote: Trouwens, is die Nijmegen-import ergens gedocumenteerd? Ik kon op de wiki niks vinden. Nee, voor zover ik heb kunnen nagaan is die import nergens gedocumenteerd. De gebruiker 'nijmegen' was onbereikbaar. Ik heb daarna contact gehad met de gemeente Nijmegen. Zei zeiden: Neem voor verdere informatie eens contact op met Roeland Douma. Leest uiteraard (en hopelijk regelmatig) mee hier. Hij heeft de import uitgevoerd onder dat account. -- Lennard ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] BAG
Op 1-6-2011 16:11, Martijn van Exel schreef: 2011/6/1dbuss...@goudappel.nl: [...] Dit is trouwens een goede oefening voor het NWB straks als die vrij wordt gegeven (ik geef het niet op!). Ook daar willen wij niet zomaar alle goede osm-wegen met slechte NWB-wegen overschrijven, maar er zijn echt wel ook nieuwbouwwijken die in OSM ontbreken en in het NWB wel inzitten. Wie organiseert een chat of skype conferentie hierover, eventueel als voorbereiding voor een fysieke ontmoeting? Groeten, Dirk Ik denk dat we genoeg stof hebben voor een mooie discussie. Floris heeft het voortouw. Het lijkt me niet verkeerd als iemand daar dan ter introductie de BAG een beetje kan uitleggen, met ook aandacht voor de kwaliteits-issues die her en der al opduiken (een gebouw ter grootte van de hele woonplaats in Deventer, rare driehoeken in Rotterdam, drie Sneeks, dat zijn de dingen die ik zo hoor als ik mijn oren te luisteren leg hier). Martijn Zonder er in detail naar gekeken te hebben kan ik de driehoeken en de verschillende Sneeks misschien verklaren: In de BAG moet een gebouw worden opgevoerd binnen vier dagen naar verlening van de bouwvergunning. Hier mag eerst een 'voorlopige geometrie' voor gebruikt worden. Sommige gemeenten proberen met de voorlopige geometrie de toekomstige werkelijkheid te benaderen, anderen (zoals dus kennelijk Rotterdam) kiezen er voor duidelijk te laten blijken dat de geometrie voorlopig is. De BAG wordt door iedere gemeente afzonderlijk bijgehouden (en via XML berichten met een 'landelijke voorziening' uitgewisseld). Nu kan het voorkomen dat een woonplaats aan, op, of over de grens van een gemeente ligt; dan zal elke gemeenten die objecten (panden, nummeraanduidingen, ...) in die woonplaats heeft de woonplaats in haar administratie opnemen. Afhankelijk van hoe de BAG dan bevraagd wordt kan één woonplaats dan meermalen voorkomen. J-. ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] BAG
Die driehoeken bij mij in de buurt ( 300 meter) zijn echte bugs, en geen nieuwe gebouwen. Misschien verbouwingen ?? Gert Gremmen - Openstreetmap.nl (alias: cetest) Before printing, think about the environment. -Oorspronkelijk bericht- Van: Jeroen Muris [mailto:jer...@tweejee.net] Verzonden: Wednesday, June 01, 2011 4:22 PM Aan: OpenStreetMap NL discussion list Onderwerp: Re: [OSM-talk-nl] BAG Op 1-6-2011 16:11, Martijn van Exel schreef: 2011/6/1dbuss...@goudappel.nl: [...] Dit is trouwens een goede oefening voor het NWB straks als die vrij wordt gegeven (ik geef het niet op!). Ook daar willen wij niet zomaar alle goede osm-wegen met slechte NWB-wegen overschrijven, maar er zijn echt wel ook nieuwbouwwijken die in OSM ontbreken en in het NWB wel inzitten. Wie organiseert een chat of skype conferentie hierover, eventueel als voorbereiding voor een fysieke ontmoeting? Groeten, Dirk Ik denk dat we genoeg stof hebben voor een mooie discussie. Floris heeft het voortouw. Het lijkt me niet verkeerd als iemand daar dan ter introductie de BAG een beetje kan uitleggen, met ook aandacht voor de kwaliteits-issues die her en der al opduiken (een gebouw ter grootte van de hele woonplaats in Deventer, rare driehoeken in Rotterdam, drie Sneeks, dat zijn de dingen die ik zo hoor als ik mijn oren te luisteren leg hier). Martijn Zonder er in detail naar gekeken te hebben kan ik de driehoeken en de verschillende Sneeks misschien verklaren: In de BAG moet een gebouw worden opgevoerd binnen vier dagen naar verlening van de bouwvergunning. Hier mag eerst een 'voorlopige geometrie' voor gebruikt worden. Sommige gemeenten proberen met de voorlopige geometrie de toekomstige werkelijkheid te benaderen, anderen (zoals dus kennelijk Rotterdam) kiezen er voor duidelijk te laten blijken dat de geometrie voorlopig is. De BAG wordt door iedere gemeente afzonderlijk bijgehouden (en via XML berichten met een 'landelijke voorziening' uitgewisseld). Nu kan het voorkomen dat een woonplaats aan, op, of over de grens van een gemeente ligt; dan zal elke gemeenten die objecten (panden, nummeraanduidingen, ...) in die woonplaats heeft de woonplaats in haar administratie opnemen. Afhankelijk van hoe de BAG dan bevraagd wordt kan één woonplaats dan meermalen voorkomen. J-. ___ 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
[OSM-talk-nl] Auto Reply: Talk-nl Digest, Vol 52, Issue 5
This is an auto-replied message. I am out of office right now. For OOB/bug related questions contact a BDE member in your own timezone. Bernard ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] BAG
On Wednesday 01 June 2011 15:57:36 stegg...@steggink.org wrote: De hoeveelheid werk van de initiële upload zal sowieso meer zijn dan de upload van de 3dShapes gebouwen. Dit omdat heel Nederland al voorzien is van gebouwen. Ook zijn gebruikers actief aan de slag gegaan met huisnummers toevoegen, etc. Ik heb dat in mijn wijk en een naburige wijk ook gedaan, in de verwachting dat bijv. de BAG niet geïmporteerd zou worden. Ergens moet je een grens trekken: je wilt als OSM community je niet constant gaan laven aan de (open) data-stroom van de overheid. Je moet je eerst afvragen of het nodig is en wat het oplevert. De BAG-data zou ons i.i.g. adresinformatie opleveren. Als we alleen dit kunnen extraheren, dan zal de import ook makkelijker gaan en voor minder conflicten zorgen. Door een ruimtelijke query erop los te laten, kun je ook gebieden uitsluiten die al zijn voorzien van huisnummers (en deze gebieden aan de mappers daarvan beschikbaar stellen). Eenzelfde werkwijze zou ook voor de footprints van de gebouwen aangehouden kunnen worden. Waar in OSM al gebouwen zitten, zou ook aan lokale mappers ter beschikking gesteld kunnen worden. Voor mij hoeven in OSM de gebouwen niet zo perfect in te zitten als in BAG, aangezien de meeste casual mappers niet met deze nauwkeurigheid werken ;) Dit sluit goed aan bij mijn ideeën over grote imports. In plaats van een paar personen die het hele land importeren, zouden die personen de externe data om kunnen zetten in hapklare brokjes. Dan kunnen lokale mappers daar makkelijker mee aan de slag. De lokale mappers kunnen veel beter beoordelen wat er nu wel en niet precies geïmporteerd en/of gecombineerd moet worden. -- m.v.g., Cartinus ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] BAG
On 1-6-2011 16:02, dbuss...@goudappel.nl wrote: Synchronisatie hoeft volgens mij niet super-moeilijk zijn. De automaat kijkt dan naar het datum van de laatste wijziging. Als de BAG recent heeft gewijzigt wint die, anders OSM. Dit inderdaad per attribuut (en geometry als verzameling van alle nodes is voor het gemak een attribuut). Ook verwijderen is een wijziging die kan winnen. Dus een welbewust weggehaald pand in osm wordt niet indirect via de BAG weer hersteld. Daar waar afwijkingen zijn kunnen wij die als een extra tag (SYNC of zo) expliciet maken zodat plaatselijke mappers dat eventueel op kunnen pakken. Wat dat betreft met Vincent eens. Ik zie veel heil in een interim database, waar alle BAG objecten in komen. Dit maakt meerdere dingen mogelijk: 1) BAG updates zijn eenduidig te verwerken, doordat het BAG id nooit verloren kan gaan. 2) Elk object kan vlaggetjes krijgen dat de status van dat object in OSM aanduidt: geïmporteerd (+timestamp), niet geïmporteerd, gesloopt, etc. Geen dubbel werk en als er twijfel is over een gebied/pand, kan dat later nog een keer aan de orde komen. Lokale mappers kunnen benaderd worden. 3) Vanuit deze db kunnen overlays gerenderd worden alsook diagnosetools draaien. 4) Je zou er als locale mapper een plukje gebouwen uit moeten kunnen selecteren, die dan met de hand verwerkt kunnen worden in OSM. 5) Het maakt spatiële analyse andersom mogelijk: pak een OSM gebouw en kijk of dit in de BAG ook bestaat. Komen de adrestags overeen? Kan OSM aangevuld worden? Is het gebouw in OSM een eenvoudige BAG-dump of zitten er verrijkende tags (amenity, etc) op? En het voorkomt dat je iedere keer opnieuw 'het wiel moet uitvinden' of door zowel de hele OSM-db als BAG moet lopen om wijzigingen te detecteren. Zoals Frank al aangaf: BAG id's op OSM objecten hangen biedt geen enkele zekerheid. -- Lennard ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] BAG
On Wed, Jun 01, 2011 at 04:22:05PM +0200, Jeroen Muris wrote: || De BAG wordt door iedere gemeente afzonderlijk bijgehouden (en via || XML berichten met een 'landelijke voorziening' uitgewisseld). Nu || kan het voorkomen dat een woonplaats aan, op, of over de grens van || een gemeente ligt; dan zal elke gemeenten die objecten (panden, || nummeraanduidingen, ...) in die woonplaats heeft de woonplaats in || haar administratie opnemen. Afhankelijk van hoe de BAG dan || bevraagd wordt kan één woonplaats dan meermalen voorkomen. Hee! Ik lees hieruit dat de gemeenten elkaar, dan wel een centrale BAG, up to date houden met (roffel) updates! Als we die nou kunnen krijgen? Dat zou wel eens heel nuttig kunnen zijn voor het up to date houden van onze BAG informatie, mochten we een BAG import of tussenbestand maken. Ciao. Vincent. -- Vincent Zweije vinc...@zweije.nl | If you're flamed in a group you http://www.xs4all.nl/~zweije/ | don't read, does anybody get burnt? [Xhost should be taken out and shot] |-- Paul Tomblin on a.s.r. signature.asc Description: Digital signature ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] BAG
Quoting Vincent Zweije vinc...@zweije.nl: On Wed, Jun 01, 2011 at 04:22:05PM +0200, Jeroen Muris wrote: || De BAG wordt door iedere gemeente afzonderlijk bijgehouden (en via || XML berichten met een 'landelijke voorziening' uitgewisseld). Nu || kan het voorkomen dat een woonplaats aan, op, of over de grens van || een gemeente ligt; dan zal elke gemeenten die objecten (panden, || nummeraanduidingen, ...) in die woonplaats heeft de woonplaats in || haar administratie opnemen. Afhankelijk van hoe de BAG dan || bevraagd wordt kan één woonplaats dan meermalen voorkomen. Hee! Ik lees hieruit dat de gemeenten elkaar, dan wel een centrale BAG, up to date houden met (roffel) updates! Als we die nou kunnen krijgen? Dat zou wel eens heel nuttig kunnen zijn voor het up to date houden van onze BAG informatie, mochten we een BAG import of tussenbestand maken. We moeten ons dus als de wiedeweerga aansluiten bij de Landelijke Voorziening en zorgen dat we voor 1 juli de BAG van heel Nederland gratis binnen hebben. ;) Alle gemeenten zijn ondertussen aangesloten, dus de LV is gevuld. Zodra er duidelijkheid is over het hergebruik is van de BAG-data, kunnen we de nuttige delen hieruit importeren in OSM. Meer info: http://bag.vrom.nl/de_bag_gebruiken/vraag_en_antwoord#v8b26cdcfe276bdac8813e5709073a6c0 Martijn, Jeroen: weten jullie of deze FAQ nog actueel is? Groeten, Frank ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] BAG
Quoting Lennard l...@xs4all.nl: On 1-6-2011 16:08, Jeroen Muris wrote: Trouwens, is die Nijmegen-import ergens gedocumenteerd? Ik kon op de wiki niks vinden. Nee, voor zover ik heb kunnen nagaan is die import nergens gedocumenteerd. De gebruiker 'nijmegen' was onbereikbaar. Ik heb daarna contact gehad met de gemeente Nijmegen. Zei zeiden: Neem voor verdere informatie eens contact op met Roeland Douma. Leest uiteraard (en hopelijk regelmatig) mee hier. Hij heeft de import uitgevoerd onder dat account. Een medewerker van de gemeente Nijmegen heeft zich aangemeld bij de OSM-groep in LinkedIn. Daarop heeft Roeland de stoute schoenen aangetrokken, een verzoek voor interessante data voor OSM bij hem neergelegd, en heeft hij de BAG-data gekregen. Frank ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
[OSM-talk-nl] Hoe gecombineerde bruggen te mappen?
Ik heb een brug kunstwerk wat 2 fietspaden en 1 weg bevat: http://goo.gl/maps/stHx Hoe krijg ik die netjes in OSM neergezet? Ik heb nu drie bruggen gemaakt, maar dat lijkt me niet de bedoeling: http://www.openstreetmap.org/?lat=52.117858lon=4.501895zoom=18layers=M Gr. /Rick -- http://rickvanderzwet.nl ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] (geen onderwerp)
Dat was altijd http://mijndev.openstreetmap.nl/~rullzer/ofk_wms/ Maar deze wordt al een tijdje niet ververst... Date: Wed, 1 Jun 2011 17:39:20 +0200 From: md...@xs4all.nl To: talk-nl@openstreetmap.org Subject: Re: [OSM-talk-nl] (geen onderwerp) On 1-6-2011 16:28, ce-test, qualified testing bv - Gert Gremmen wrote: Waar zit ook al weer die fietskaart die de goede/foute fietsroute relaties laat zien in rood en blauw ….. Groen en blauw. Je bedoelt waarschijnlijk www.openfietskaart.nl Daarnaast heb je de www.openwandelkaart.nl met ook rode routes, maar dan zijn dus de wandelroutes. Maarten ___ 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] Fietsroutes check
Of amsterdams ;) Ja om een of andere duistere reden doet de WMS het niet meer helemaal. Ik zal en binnenkort eens een blik op werpen. --Roeland On Wednesday 01 June 2011 20:27:59 Lennard wrote: On 1-6-2011 19:29, ce-test, qualified testing bv - Gert Gremmen wrote: Rubke hedde ge nuch tijd da scriptje een schopke onder de kont te gevven ? (accent voor verbetering vatbaar ;) Ja, vooral omdat je een Purmerends accent had moeten doen. Dat was altijd http://mijndev.openstreetmap.nl/~rullzer/ofk_wms/ Maar signature.asc Description: This is a digitally signed message part. ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] bag vs shape import
Net langs diverse gebouwen gelopen die ik ooit in Nijmegen heb ingetekend (kerken, ziekenhuizen, scholen etc). Een aantal is netjes vervangen door de BAG-import, maar een stuk op 10 staan er nog. En in de Waalsprong zijn enkele onlangs gesloopte panden weer verrezen. Morgen heb ik geen tijd, ik zal dit vrijdag eens goed opruimen. Groeten, Dirk Het noordelijke sportfondsenbad heb ik 2 jaar geleden, dus nog voor de 3D shapes op basis van een gps-meting langs de voorgevel ingetekend. Ben best trots hoe goed het overeenkomt met de BAG ;-) Ik zal de attributen overnemen (BAG weet niet eens dat het een zwembad is) en mijn oud gebouwtje dan verwijderen. Met vriendelijke groet, 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
