Re: [OSM-talk-nl] BAG viewer
Stefan, Oliver heeft het over het importeren van BAG-data in OSM, niet om toevoegingen van OSM-gebruikers weer aan de BAG te voeden. Dit kan ook helemeal niet. De BAG wordt bijgehouden door de bronhouders; de gemeenten. Wat authentieke BAG-data is, wordt door deze bronhouders bepaald. Er is geen mogelijkheid om OSM op de een of andere manier op de Landelijke Voorziening aan te sluiten, om de BAG van extra attributen te voorzien. Wij kunnen alleen besluiten om BAG-data uit de LV te onttrekken en deze in OSM te importeren. (Wat dit betreft heb ik wel twijfels over het databankenrecht, maar dat is een andere discussie.) Quoting Stefan de Konink ste...@konink.de: Op 02-11-11 21:02, Oliver Heesakkers schreef: OSM is echter veel laagdrempeliger. Onzin, als OSM laagdrempelig was kwamen er niet tal van mensen naar mij toe met de vraag hoe ze uberhaupt data uit OSM kunnen halen. Vector data ja, dat ze kunnen verwerken in met software. OSM XML != Standaard. Er staat laagdrempelig_er_. Ik zie ook niet een leek zomaar met GML data in de weer gaan. Geimporteerde BAG-data geeft de mapper gelegenheid om namen, ingangen, openingstijden, etc. toe te voegen en geeft die mapper ook makkelijk de gelegenheid om de plaatsing van wegen te orienteren aan de gebouwen. Een GML bestand geeft diezelfde functionaliteit. Ik mis het punt. Omdat die tags niet in IMGeo (het uitwisselingsformaat voor BAG) gedefinieerd staan? De huisnummers (en binnenkort wellicht postcodes) die BAG levert zijn relevante en goed bruikbare data die ook juist voor afgeleide (navigatie)producten juist heel interessant zijn. Het bij elkaar houden van de data voorkomt dan licentievraagstukken en compatibiliteitsproblemen. Het introduceert alleen maar licentie vraagstukken. De vraag: waarom BAG data geedit door OSM'ers opeens niet meer PD zijn bijvoorbeeld. De OSM-licentie blijft gelden (be it CC-BY-SA 2.0 of ODbL). Alles wat in OSM zit, voldoet hieraan. Er is geen enkel bezwaar om PD data te importeren. Afgeleide data hoeft, per definitie, niet PD te blijven. De originele bron blijft dat natuurlijk wel. Anders zou daar een share-alike clausule aanhangen. Frank ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] BAG viewer
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Op 03-11-11 08:40, Frank Steggink schreef: Stefan, Oliver heeft het over het importeren van BAG-data in OSM, niet om toevoegingen van OSM-gebruikers weer aan de BAG te voeden. Dit kan ook helemeal niet. De BAG wordt bijgehouden door de bronhouders; de gemeenten. Wat authentieke BAG-data is, wordt door deze bronhouders bepaald. Er is geen mogelijkheid om OSM op de een of andere manier op de Landelijke Voorziening aan te sluiten, om de BAG van extra attributen te voorzien. Wij kunnen alleen besluiten om BAG-data uit de LV te onttrekken en deze in OSM te importeren. (Wat dit betreft heb ik wel twijfels over het databankenrecht, maar dat is een andere discussie.) Zover ik heb begrepen kan er bij iedere bronhouder worden gerapporteerd als er dingen in de BAG niet kloppen. Databankenrecht waarop? BAG licentie gelezen? Stefan -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEAREKAAYFAk6yguUACgkQYH1+F2Rqwn0k2gCghHZFOpkzda0yWp0krAaKuFe1 Ez8An3nEC2rgdIrFZFJeVvyaHES98dpZ =DA39 -END PGP SIGNATURE- ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] BAG viewer
Quoting Stefan de Konink ste...@konink.de: Op 03-11-11 08:40, Frank Steggink schreef: Stefan, Oliver heeft het over het importeren van BAG-data in OSM, niet om toevoegingen van OSM-gebruikers weer aan de BAG te voeden. Dit kan ook helemeal niet. De BAG wordt bijgehouden door de bronhouders; de gemeenten. Wat authentieke BAG-data is, wordt door deze bronhouders bepaald. Er is geen mogelijkheid om OSM op de een of andere manier op de Landelijke Voorziening aan te sluiten, om de BAG van extra attributen te voorzien. Wij kunnen alleen besluiten om BAG-data uit de LV te onttrekken en deze in OSM te importeren. (Wat dit betreft heb ik wel twijfels over het databankenrecht, maar dat is een andere discussie.) Zover ik heb begrepen kan er bij iedere bronhouder worden gerapporteerd als er dingen in de BAG niet kloppen. Succes als je deze weg wilt bewandelen :) Databankenrecht waarop? BAG licentie gelezen? Niet recent, dus het is me ontgaan. Google brengt me wel op deze site uit: http://wiki.openstreetmap.org/wiki/BAG . Jeroen's samenvatting waar naar verwezen wordt laat het databankenrecht nog als open punt (onverlet het auteursrecht). Frank ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] BAG viewer
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Op 03-11-11 14:19, Frank Steggink schreef: Succes als je deze weg wilt bewandelen :) Je kunt maar beter de eerste zijn he :) Terugmelden onjuistheden BAG Antwoord Als u gerede twijfel heeft over de juistheid van de informatie in de BAG, dan kunt u dit per email melden bij b...@kadaster.nl. In het onderwerpveld van de e-mail dient u de gemeente waarbinnen het object valt te vermelden. Dat lijkt me nu een perfect e-mail adres om automatisch verbetering naar toe te sturen :) Databankenrecht waarop? BAG licentie gelezen? Niet recent, dus het is me ontgaan. Google brengt me wel op deze site uit: http://wiki.openstreetmap.org/wiki/BAG . Jeroen's samenvatting waar naar verwezen wordt laat het databankenrecht nog als open punt (onverlet het auteursrecht). Mag ik de BAG-data aan derden verstrekken? Antwoord De BAG is er voor iedereen! Hoewel de BAG in eerste instantie gebouwd is om overheden efficiënter en klantgerichter te laten werken, is de BAG ook beschikbaar voor burgers en bedrijven. Het beleid van de Rijksoverheid is immers dat overheidsinformatie op een makkelijke en goedkope wijze ter beschikking moet worden gesteld aan iedereen die daar behoefte aan heeft. In beginsel is er aan hergebruik van deze informatie geen belemmering gekoppeld. Een uitzondering hierop vormt de postcode. Vanwege een oude afspraak tussen de overheid en PostNL mag de postcode uit de BAG niet voor commerciële doeleinden worden gebruikt. De overheid heeft deze afspraak opgezegd en deze belemmering vervalt uiterlijk 1 februari 2012. Daarna mag, ook de postcode uit de BAG voor commerciële doeleinden worden gebruikt, net zoals alle andere gegevens uit de BAG. Is de FUD nu eigenlijk over? Stefan -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEAREKAAYFAk6yvYwACgkQYH1+F2Rqwn1riACfXX9f/IsJBLwOw59yeTpuqcqB /YoAn2EoPtB3ncEss3W6PiOAG0KtNXYC =j4/p -END PGP SIGNATURE- ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] BAG viewer
On 11-11-03 05:13 PM, Stefan de Konink wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Op 03-11-11 14:19, Frank Steggink schreef: Succes als je deze weg wilt bewandelen :) Je kunt maar beter de eerste zijn he :) Terugmelden onjuistheden BAG Antwoord Als u gerede twijfel heeft over de juistheid van de informatie in de BAG, dan kunt u dit per email melden bij b...@kadaster.nl. In het onderwerpveld van de e-mail dient u de gemeente waarbinnen het object valt te vermelden. Dat lijkt me nu een perfect e-mail adres om automatisch verbetering naar toe te sturen :) Databankenrecht waarop? BAG licentie gelezen? Niet recent, dus het is me ontgaan. Google brengt me wel op deze site uit: http://wiki.openstreetmap.org/wiki/BAG . Jeroen's samenvatting waar naar verwezen wordt laat het databankenrecht nog als open punt (onverlet het auteursrecht). Mag ik de BAG-data aan derden verstrekken? Antwoord De BAG is er voor iedereen! Hoewel de BAG in eerste instantie gebouwd is om overheden efficiënter en klantgerichter te laten werken, is de BAG ook beschikbaar voor burgers en bedrijven. Het beleid van de Rijksoverheid is immers dat overheidsinformatie op een makkelijke en goedkope wijze ter beschikking moet worden gesteld aan iedereen die daar behoefte aan heeft. In beginsel is er aan hergebruik van deze informatie geen belemmering gekoppeld. Een uitzondering hierop vormt de postcode. Vanwege een oude afspraak tussen de overheid en PostNL mag de postcode uit de BAG niet voor commerciële doeleinden worden gebruikt. De overheid heeft deze afspraak opgezegd en deze belemmering vervalt uiterlijk 1 februari 2012. Daarna mag, ook de postcode uit de BAG voor commerciële doeleinden worden gebruikt, net zoals alle andere gegevens uit de BAG. Is de FUD nu eigenlijk over? Stefan -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEAREKAAYFAk6yvYwACgkQYH1+F2Rqwn1riACfXX9f/IsJBLwOw59yeTpuqcqB /YoAn2EoPtB3ncEss3W6PiOAG0KtNXYC =j4/p -END PGP SIGNATURE- ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl Volgens Google is de zin Mag ik de BAG-data aan derden verstrekken? en het antwoord inderdaad op de Kadaster-site te vinden (. Goed nieuws dus ;) Alleen jammer dat hun site het net lijkt te hebben begeven, omdat ik een foutmelding krijg. Het zou beter zijn als het Kadaster dit op een zodanige plek neerzet dat het statement niet door een ASP.NET fout onbereikbaar wordt. Ik had dit antwoord nog niet gezien, omdat ik OSM minder intensief volg, maar toch de BAG-discussie interessant vind. Ik wilde geen FUD zaaien, maar had zelf nog last van een restant 'D'. Je weet dat ik pro-open data ben, maar ik heb geen tijd en zin om achteraf met juridische zaken geconfronteerd te worden bij overhaaste beslissingen. Frank ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] BAG viewer
Op za 29 okt 2011 17:36:21 schreef Stefan de Konink: Op 29-10-11 14:50, Oliver Heesakkers schreef: Up-to-date houden van de data zie ik niet direct als probleem, meer een technische uitdaging. Bovendien moet er ook over worden nagedacht hoe vaak je het wilt doen (een maal per maand lijkt mij schromelijk overdreven). Dan denken wij daar dus duidelijk anders over. Het is totaal onnodig om de BAG data te importeren. Omdat de data in een PD licentie beschikbaar is en een open standaard gebruikt om de data te ontsluiten. Wil je de data renderen kan dat gewoon, zelfs samen met OpenStreetMap op 1 kaart laag. Weerleg mijn argumenten maar. Het argument dat de data PD is leidt uberhaupt niet tot de conclusie dat het onnodig is om die data in de OSM-database te importeren. Je veronderstelt dat elke burger geen probleem zou hebben om contact op te nemen met de overheid om BAG-data te verwerven en ze ook kan verwerken. OSM is echter veel laagdrempeliger. Geimporteerde BAG-data geeft de mapper gelegenheid om namen, ingangen, openingstijden, etc. toe te voegen en geeft die mapper ook makkelijk de gelegenheid om de plaatsing van wegen te orienteren aan de gebouwen. De huisnummers (en binnenkort wellicht postcodes) die BAG levert zijn relevante en goed bruikbare data die ook juist voor afgeleide (navigatie)producten juist heel interessant zijn. Het bij elkaar houden van de data voorkomt dan licentievraagstukken en compatibiliteitsproblemen. ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] BAG viewer
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Op 02-11-11 21:02, Oliver Heesakkers schreef: OSM is echter veel laagdrempeliger. Onzin, als OSM laagdrempelig was kwamen er niet tal van mensen naar mij toe met de vraag hoe ze uberhaupt data uit OSM kunnen halen. Vector data ja, dat ze kunnen verwerken in met software. OSM XML != Standaard. Geimporteerde BAG-data geeft de mapper gelegenheid om namen, ingangen, openingstijden, etc. toe te voegen en geeft die mapper ook makkelijk de gelegenheid om de plaatsing van wegen te orienteren aan de gebouwen. Een GML bestand geeft diezelfde functionaliteit. Ik mis het punt. De huisnummers (en binnenkort wellicht postcodes) die BAG levert zijn relevante en goed bruikbare data die ook juist voor afgeleide (navigatie)producten juist heel interessant zijn. Het bij elkaar houden van de data voorkomt dan licentievraagstukken en compatibiliteitsproblemen. Het introduceert alleen maar licentie vraagstukken. De vraag: waarom BAG data geedit door OSM'ers opeens niet meer PD zijn bijvoorbeeld. Stefan -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEAREKAAYFAk6xvuoACgkQYH1+F2Rqwn0qUgCbBEsXSzscvFizsDyBsXYTft/T AcQAn1+iuyAa2kx01GNJ+oaOysJC5/Ow =gh5h -END PGP SIGNATURE- ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] BAG viewer
Hey Dick, De BAG is heel accuraat, maar niet compleet. Het heeft een zeer duidelijk omschreven set van eisen en daarbinnen is het de gezaghebbende bron voor heel Nederland. Echter zoals elders in de discussie opgemerkt het bevat niet alles, zo kan een OSM gebruiker extra tags of wijzigingen op de geometrie toevoegen om te zeggen waar de ingang (of de rolstoel vriendelijke ingang) is, welke voorzieningen het pand bevat e.d. Als een OSMer met veel zorg en liefde alle rolstoelingangen (random voorbeeld*)) van alle gebouwen in OSM heeft gezet, zal hij niet blij zijn als je blind de BAG data over zijn wijzigingen zet, met het idee dat de BAG gezaghebbend is. Het punt is dat de BAG gezaghebbend is in een heel specifiek domein, maar dat OSM over meerdere domeinen gaat (sterker nog OSM heeft expliciet gekozen om juist niet bij voorbaat vast te stellen welke domeinen wel en niet worden gemapped) en dus meer/andere informatie bevat dan de BAG. groet Steven *) niet geheel random natuurlijk, ik weet uit ervaring dat er een groot verschil is tussen een ingang en een rolstoelvriendelijke ingang en dat een geometrie van een gebouw niet altijd de rolstoel-ramp toont of niet vertelt hoe hij loopt (boven/onder). Ik weet trouwens niet hoe de BAG dat doet. On Oct 31, 2011, at 7:43 PM, Dick wrote: He Martijn, Bedankt voor je reactie. Wie weet hoe accuraat BAG is? Voor wat ik nu zie heel accuraat, wat mij betreft kan BAG dan blind OSM overschijven (als de data nieuwer is dan OSM en een bag objekt id tag heeft). gr Dick ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl sudo sluiskill all ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
[OSM-talk-nl] BAG viewer
Dick d...@mrns.nlschreef: Wie weet hoe accuraat BAG is? Voor wat ik nu zie heel accuraat, wat mij betreft kan BAG dan blind OSM overschijven (als de data nieuwer is dan OSM en een bag objekt id tag heeft). De accuraatheid van de BAG zal per gemeente verschillen en zal afhangen van de organisatie en de hoeveelheid aandacht die het bij een gemeente krijgt. Bij het vervangen van de 3dShapes in Gorinchem door adressen en gebouwen uit de BAG stuitte ik op diverse slordigheden die niet overeenstemmen met de werkelijkheid; die zijn dan ook direct door mij aangepast. Overall zijn vooral de gebouwcontouren stukken nauwkeuriger en recenter dan 3dShapes maar ook BAG-data is niet overal 100% foutloos. Ik voel dan ook veel voor het idee om de BAG-data op wat voor manier dan ook als resource ter beschikking te stellen, en dat lokale mappers daar waar zij het belangrijk vinden de 3dShapes vervangen door BAG-data. Groeten, Ruud den Blanken ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] BAG viewer
On Sunday 30 October 2011 08:12:53 Frank Steggink wrote: On 11-10-30 12:52 AM, Stefan de Konink wrote: Dat je geen object ids nodig hebt kan kloppen als het systeem in 1 klap alle data laat importeren en daarmee het systeem laat bij houden welke data is ingevoerd en welke data mapt naar welk object. Of je verplicht iedereen een apart importaccount aan te maken en houdt een lijst van deze accounts bij. Dan kun je de data zonder teveel gedoe vervangen zodra er een mutatie is gedetecteerd, maar wanneer de versie van het object (en alle nodes) nog 1 is. Uiteraard met een importaccount. Het is dan wel van belang om oude data volledig te verwijderen en nieuwe data opnieuw te importeren, om het versienummer op 1 te houden. Wanneer de bestaande data al gewijzigd is, dan gaat dit niet meer op. Dit zal handmatig moeten gebeuren, om zeker te weten dat je geen user-contributed aanvullingen weggooit. Het maken van een importaccount voor imports is sowieso een best practice! Zie http://wiki.openstreetmap.org/wiki/Import/Guidelines#Use_a_dedicated_user_a ccount Jullie gaan allebei nog steeds uit van vergelijken van geupdate brondata met data in OSM door een programma. Daar heb ik het helemaal niet over. Je neemt BAG data van een beperkt gebied (je eigen buurt en misschien wat buurten eromheen of je eigen dorp). Dat converteer je naar OSM formaat. Dat geconverteerde bestand bewaar je! De volgende keer dat je de BAG data bekijkt maak je weer een bestand in OSM formaat met alleen BAG data. Dat vergelijk je met het vorige bestand met alleen BAG data. De verschillen tussen die twee ga je vervolgens _met de hand_ vergelijken met de data in OSM. Data vergelijken gaat bijvoorbeeld prima in JOSM met twee data-layers. Zolang de lokale mapper niet te veel hooi op z'n vork neemt moet dat prima te doen zijn. Dus: Hé, laat ik in m'n eentje de hele provincie Utrecht bijhouden. gaat nooit lukken. Utrecht Zuid-West en de noordrand van Nieuwegein is makkelijk bij te houden door één persoon. In de meeste plaatsen in Nederland hebben we niet zo'n groot overschot aan langdurig actieve mappers dat we elkaar voor de voeten zouden lopen met deze aanpak. -- m.v.g., Cartinus ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] BAG viewer
On 29-10-11 21:31, Stefan de Konink wrote: Het probleem is juist het overzetten. Als ObjectIDs stabiel zijn, dan is er geen probleem. Maar juist een systeem dat dat stukje monitort en intelligent is om fouten op te sporen en te herstellen... dat ontbreekt. Als het nou om data ging die 1x per jaar wordt geupdate... maar het gaat om data die technisch gezien realtime geupdate kan worden. Stel dat we nu al beginnen met kleinschalige imports van de BAG, dan wordt de kwaliteit van OSM beter in deze gebieden. Probleem is dan dat als OpenMetaMap of iets dergelijks klaar is, dat we dan de BAG weer uit OSM moeten halen en in de OMM moeten krijgen. Daarbij zou het wenselijk zijn om de reeds gemaakte aanpassingen door OSM'ers mee te kopiëren. Alleen, stel dat we nu gewoon de 3dShapes laten staan. Als dan OMM klaar is, en we zetten de BAG daarin, hebben we dus twee verzamelingen gebouwen staan. Dat lijkt me ook onwenselijk en dan moeten de 3dShapes-gebouwen dus waarschijnlijk ook weer uit OSM. Maar ook aan de 3dShapes zijn reeds verbeteringen doorgevoerd door lokale mappers. Die zullen dus ook naar de OMM overgehaald moeten worden. Dan is er in feite toch geen verschil tussen het nu wel of niet importeren van gedeelten van de BAG, of begrijp ik het idee van OMM nu niet goed? Willem Sonke ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] BAG viewer
Deze aanpak zie ik ook wel zitten. Ik denk echter dat de werkwijze voor het importeren laagdrempelige gemaakt moet worden, zodat veel beetje ervaren lokale mappers het als een uitdaging zien om dit vergelijk te maken. Groet Robert Met vriendelijke groeten, Robert Elsenaar (Verzonden vanaf Mobile) Cartinus carti...@xs4all.nl schreef: On Sunday 30 October 2011 08:12:53 Frank Steggink wrote: On 11-10-30 12:52 AM, Stefan de Konink wrote: Dat je geen object ids nodig hebt kan kloppen als het systeem in 1 klap alle data laat importeren en daarmee het systeem laat bij houden welke data is ingevoerd en welke data mapt naar welk object. Of je verplicht iedereen een apart importaccount aan te maken en houdt een lijst van deze accounts bij. Dan kun je de data zonder teveel gedoe vervangen zodra er een mutatie is gedetecteerd, maar wanneer de versie van het object (en alle nodes) nog 1 is. Uiteraard met een importaccount. Het is dan wel van belang om oude data volledig te verwijderen en nieuwe data opnieuw te importeren, om het versienummer op 1 te houden. Wanneer de bestaande data al gewijzigd is, dan gaat dit niet meer op. Dit zal handmatig moeten gebeuren, om zeker te weten dat je geen user-contributed aanvullingen weggooit. Het maken van een importaccount voor imports is sowieso een best practice! Zie http://wiki.openstreetmap.org/wiki/Import/Guidelines#Use_a_dedicated_user_a ccount Jullie gaan allebei nog steeds uit van vergelijken van geupdate brondata met data in OSM door een programma. Daar heb ik het helemaal niet over. Je neemt BAG data van een beperkt gebied (je eigen buurt en misschien wat buurten eromheen of je eigen dorp). Dat converteer je naar OSM formaat. Dat geconverteerde bestand bewaar je! De volgende keer dat je de BAG data bekijkt maak je weer een bestand in OSM formaat met alleen BAG data. Dat vergelijk je met het vorige bestand met alleen BAG data. De verschillen tussen die twee ga je vervolgens _met de hand_ vergelijken met de data in OSM. Data vergelijken gaat bijvoorbeeld prima in JOSM met twee data-layers. Zolang de lokale mapper niet te veel hooi op z'n vork neemt moet dat prima te doen zijn. Dus: Hé, laat ik in m'n eentje de hele provincie Utrecht bijhouden. gaat nooit lukken. Utrecht Zuid-West en de noordrand van Nieuwegein is makkelijk bij te houden door één persoon. In de meeste plaatsen in Nederland hebben we niet zo'n groot overschot aan langdurig actieve mappers dat we elkaar voor de voeten zouden lopen met deze aanpak. -- 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 viewer
On 11-10-30 10:34 AM, Robert Elsenaar wrote: Deze aanpak zie ik ook wel zitten. Ik denk echter dat de werkwijze voor het importeren laagdrempelige gemaakt moet worden, zodat veel beetje ervaren lokale mappers het als een uitdaging zien om dit vergelijk te maken. Groet Robert Met vriendelijke groeten, Robert Elsenaar (Verzonden vanaf Mobile) Cartinus carti...@xs4all.nl schreef: On Sunday 30 October 2011 08:12:53 Frank Steggink wrote: On 11-10-30 12:52 AM, Stefan de Konink wrote: Dat je geen object ids nodig hebt kan kloppen als het systeem in 1 klap alle data laat importeren en daarmee het systeem laat bij houden welke data is ingevoerd en welke data mapt naar welk object. Of je verplicht iedereen een apart importaccount aan te maken en houdt een lijst van deze accounts bij. Dan kun je de data zonder teveel gedoe vervangen zodra er een mutatie is gedetecteerd, maar wanneer de versie van het object (en alle nodes) nog 1 is. Uiteraard met een importaccount. Het is dan wel van belang om oude data volledig te verwijderen en nieuwe data opnieuw te importeren, om het versienummer op 1 te houden. Wanneer de bestaande data al gewijzigd is, dan gaat dit niet meer op. Dit zal handmatig moeten gebeuren, om zeker te weten dat je geen user-contributed aanvullingen weggooit. Het maken van een importaccount voor imports is sowieso een best practice! Zie http://wiki.openstreetmap.org/wiki/Import/Guidelines#Use_a_dedicated_user_a ccount Jullie gaan allebei nog steeds uit van vergelijken van geupdate brondata met data in OSM door een programma. Daar heb ik het helemaal niet over. Je neemt BAG data van een beperkt gebied (je eigen buurt en misschien wat buurten eromheen of je eigen dorp). Dat converteer je naar OSM formaat. Dat geconverteerde bestand bewaar je! De volgende keer dat je de BAG data bekijkt maak je weer een bestand in OSM formaat met alleen BAG data. Dat vergelijk je met het vorige bestand met alleen BAG data. De verschillen tussen die twee ga je vervolgens _met de hand_ vergelijken met de data in OSM. Data vergelijken gaat bijvoorbeeld prima in JOSM met twee data-layers. Zolang de lokale mapper niet te veel hooi op z'n vork neemt moet dat prima te doen zijn. Dus: Hé, laat ik in m'n eentje de hele provincie Utrecht bijhouden. gaat nooit lukken. Utrecht Zuid-West en de noordrand van Nieuwegein is makkelijk bij te houden door één persoon. In de meeste plaatsen in Nederland hebben we niet zo'n groot overschot aan langdurig actieve mappers dat we elkaar voor de voeten zouden lopen met deze aanpak. -- m.v.g., Cartinus Ik ga er niet van uit dat de vergelijking geautomatiseerd gebeurt. Ik beschrijf alleen hoe je de vergelijking zelf doet, niet waarmee. In JOSM kun je ook zoeken op version:1. Een bepaald deel zou automatisch kunnen gebeuren (niet verplicht), maar het andere deel zeker niet. Frank ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] BAG viewer
Ik zat zelf een beetje aan de volgende globale procedure te denken: 1) Zet de initiële brongegevens uit BAG om naar OSM formaat. 2) Open je gebied uit OSM in JOSM. 3) Leg hier overheen het zelfde gebiedje in OSM formaat dat uit de eerste import gemaakt is. 4) Vergelijk deze twee lagen visueel waarbij je de gebouwen uit OSM verwijderd die op de BAG laag beter zijn. Uiteindelijk heb je lokaal een projectie van de twee lagen die juist is. 5) Upload de BAG-OSM laag naar OSM. 6) Registreer de uitgevoerde update in Wiki en voeg daarbij de brongegevens van de gebruikte initiële update Er zijn een aantal updates beschikbaar van de initiële BAG gegevens die je reeds geïmporteerd hebt. 7) Maak van de brongegevens van de updates een Delta update. Dit kan voor iedere lokale mapper een andere verzameling zijn omdat de één ieder kwartaal update en een ander ieder jaar. Ik ga uit van maandelijkse updates vanuit BAG. 8) Behandel deze update op gelijke manier als de initiële update en breng de gegevens in OSM. 9) Registreer de uitgevoerde update in Wiki en voeg daarbij de brongegevens van de gebruikte delta update Ik denk dat voor het klaarmaken van de initiële update en het fabriceren van de delta update in OSM formaat een programma zou moeten komen die werkt zoals WalkingPaper (Gebied aangeven) datum laatste update opgeven en je kunt binnen een gepaste tijd het OSM bestand downloaden. Verder moet er een Wiki pagina komen met de werkbeschrijving over hoe een update uitgevoerd kan worden inclusief tips en trucs binnen JOSM in het omgaan met twee layers. Benodigdheden: a) Centrale opslag BAG gegevens en sponsor voor het update abonnement. b) Een programma BAG2OSM die via een pagina de updates kan aanleveren. c) Een Wiki pagina met de beschrijving van hoe je te werk moet gaan. Wie schiet? groet Robert -Oorspronkelijk bericht- From: Frank Steggink Sent: Sunday, October 30, 2011 10:44 AM To: talk-nl@openstreetmap.org Subject: Re: [OSM-talk-nl] BAG viewer On 11-10-30 10:34 AM, Robert Elsenaar wrote: Deze aanpak zie ik ook wel zitten. Ik denk echter dat de werkwijze voor het importeren laagdrempelige gemaakt moet worden, zodat veel beetje ervaren lokale mappers het als een uitdaging zien om dit vergelijk te maken. Groet Robert Met vriendelijke groeten, Robert Elsenaar (Verzonden vanaf Mobile) Cartinus carti...@xs4all.nl schreef: On Sunday 30 October 2011 08:12:53 Frank Steggink wrote: On 11-10-30 12:52 AM, Stefan de Konink wrote: Dat je geen object ids nodig hebt kan kloppen als het systeem in 1 klap alle data laat importeren en daarmee het systeem laat bij houden welke data is ingevoerd en welke data mapt naar welk object. Of je verplicht iedereen een apart importaccount aan te maken en houdt een lijst van deze accounts bij. Dan kun je de data zonder teveel gedoe vervangen zodra er een mutatie is gedetecteerd, maar wanneer de versie van het object (en alle nodes) nog 1 is. Uiteraard met een importaccount. Het is dan wel van belang om oude data volledig te verwijderen en nieuwe data opnieuw te importeren, om het versienummer op 1 te houden. Wanneer de bestaande data al gewijzigd is, dan gaat dit niet meer op. Dit zal handmatig moeten gebeuren, om zeker te weten dat je geen user-contributed aanvullingen weggooit. Het maken van een importaccount voor imports is sowieso een best practice! Zie http://wiki.openstreetmap.org/wiki/Import/Guidelines#Use_a_dedicated_user_a ccount Jullie gaan allebei nog steeds uit van vergelijken van geupdate brondata met data in OSM door een programma. Daar heb ik het helemaal niet over. Je neemt BAG data van een beperkt gebied (je eigen buurt en misschien wat buurten eromheen of je eigen dorp). Dat converteer je naar OSM formaat. Dat geconverteerde bestand bewaar je! De volgende keer dat je de BAG data bekijkt maak je weer een bestand in OSM formaat met alleen BAG data. Dat vergelijk je met het vorige bestand met alleen BAG data. De verschillen tussen die twee ga je vervolgens _met de hand_ vergelijken met de data in OSM. Data vergelijken gaat bijvoorbeeld prima in JOSM met twee data-layers. Zolang de lokale mapper niet te veel hooi op z'n vork neemt moet dat prima te doen zijn. Dus: Hé, laat ik in m'n eentje de hele provincie Utrecht bijhouden. gaat nooit lukken. Utrecht Zuid-West en de noordrand van Nieuwegein is makkelijk bij te houden door één persoon. In de meeste plaatsen in Nederland hebben we niet zo'n groot overschot aan langdurig actieve mappers dat we elkaar voor de voeten zouden lopen met deze aanpak. -- m.v.g., Cartinus Ik ga er niet van uit dat de vergelijking geautomatiseerd gebeurt. Ik beschrijf alleen hoe je de vergelijking zelf doet, niet waarmee. In JOSM kun je ook zoeken op version:1. Een bepaald deel zou automatisch kunnen gebeuren (niet verplicht), maar het andere deel zeker niet. Frank ___ Talk-nl mailing list Talk-nl@openstreetmap.org
Re: [OSM-talk-nl] BAG viewer
On 30-10-11 12:58, Andre wrote: De bestanden kunnen via 1 goedkoop abonnement van meen ik 160 euro landelijk worden verkregen, waarom zou je dan niet landelijk importeren? Per gemeente importeren vraagt om inconsistentie: de actualiteit en verversingsfreqentie gaat dan per gebied afwijken en daarmee is de kaart niet meet als referentie te gebruiken, want je weet dan niet meer waar je naar lijkt. Dat is nu, met de 3dShapes, ook niet het geval. Ik heb zelf het idee: als je exacte gebouwendata wilt, dan zul je toch naar de ruwe BAG moeten kijken. Is het dan niet beter om de gehele BAG in 1 x landelijk te importeren en dan in zijn geheel om de drie maanden te vervangen? Dus verwijderen en opnieuw importeren. Er zullen weinig of geen mutaties nodig zijn schat ik dan in. De huidige 3dshapes kunnen er dan uit. Blijven er dan toch nog verschillen over, dan zouden die in een aparte laag kunnen, die wel gemuteerd kan worden. Ik denk echter dat de meeste mutaties dan even vooroplopen op de BAG, en na verloop van tijd wel weer eruit kunnen. Ik denk dat de BAG alleen dan goed genoeg is. Eventueel kan de verversings frequentue dan omhoog naar 1x per maand. Bij iedere update van de BAG moet wel gekeken worden of er door OSM'ers geen updates gedaan zijn. Bij een massale landelijke import en landelijke updates loop je het risico dat gegevens van mensen die zelf veel moeite hebben gedaan ze toe te voegen zomaar verwijderd worden. Om dat te voorkomen moet er continu contact zijn met de lokale mappers. Dan kunnen die de import en updates toch net zo goed zelf doen? De vraag is of het een probleem is dat de BAG niet letterlijk in OSM zit; ik vind van niet, sterker nog, ik vind het onwenselijk. De gegevens moeten kunnen worden aangepast, dat is juist het idee van OSM. We moeten dus voorkomen dat er iedere maand een landelijke update eroverheen komt die al je verbeteringen weer teniet doet. Ik zeg niet dat het onmogelijk is om landelijk goed te regelen, maar er moet wel veel aandacht aan worden besteed. Daarnaast is het een idee om behalve de gebouwen ook de huisnummers met daaraan gekoppeld de adresinformatie op te nemen in OSM op zodanige wijze dat ook op adres gezocht kan gaan worden? Dat lijkt me sowieso een goed idee, net zoals dat gedaan is in Gorinchem. Dan hebben we eindelijk fatsoenlijke deur-tot-deur-navigatie in heel Nederland :-) Willem Sonke ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] BAG viewer
Is mijn procedure niet overgekomen? Vanmorgen gaf ik al een idee over het beschikbaar stellen van de laatste relevante BAG gegevens aan lokale mappers . Met vriendelijke groeten, Robert Elsenaar (Verzonden vanaf Mobile) Henk Hoff toffeh...@gmail.com schreef: 2011/10/30 Willem Sonke willemso...@planet.nl Bij iedere update van de BAG moet wel gekeken worden of er door OSM'ers geen updates gedaan zijn. Bij een massale landelijke import en landelijke updates loop je het risico dat gegevens van mensen die zelf veel moeite hebben gedaan ze toe te voegen zomaar verwijderd worden. Om dat te voorkomen moet er continu contact zijn met de lokale mappers. Dan kunnen die de import en updates toch net zo goed zelf doen? De vraag is of het een probleem is dat de BAG niet letterlijk in OSM zit; ik vind van niet, sterker nog, ik vind het onwenselijk. De gegevens moeten kunnen worden aangepast, dat is juist het idee van OSM. We moeten dus voorkomen dat er iedere maand een landelijke update eroverheen komt die al je verbeteringen weer teniet doet. Ik zeg niet dat het onmogelijk is om landelijk goed te regelen, maar er moet wel veel aandacht aan worden besteed. In een forum op SotM Wenen werd gesteld dat imports de community om zeep helpen. Daar zit een kern van waarheid in. Hetgeen Willem dus ook aangeeft. Het is uiteraard uitdagend om een kick-ass import script te schrijven die ervoor zorgt dat OSM-nl een kopie wordt van de BAG. Maar daarbij gaat we voorbij aan het idee achter OSM. Daarnaast staat door andere NL-importen in het recente verleden verschillende data dubbel in. Kortom, hoe kun je van bomen een bos maken en dat laten veranderen in een ondoordringbaar oerwoud. Neemt niet weg dat de BAG een interessante data-source is waar we wat aan kunnen hebben. Is het een idee om een mogelijkheid te hebben wanneer (middels plug-in in JOSM bv) om een BAG als een achtergrond te hebben vanwaar eenvoudig geselecteerde data van het BAG naar de OSM laag gekopieerd kan worden? Op deze wijze kan iedereen binnen de OSM community helpen om zijn deel van de kaart beter te maken. Tegelijkertijd zit er ook een visuele check op dat er geen al te rare dingen wordt gedaan. Met een beetje creativiteit kan deze tool dan ook door andere landen gebruikt worden. Nederland is nl niet het enige land waarin geodata wordt vrijgegeven. Gr, Henk ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] BAG viewer
On Sunday 30 October 2011 19:26:09 Dick wrote: Dan kunnen we, als de bag data is gewijzigd de OSM data automatisch aanpassen. Het probleem is helemaal niet het volgen van de BAG wijzigingen. Dat is simpel. Het probleem is het respecteren van andere edits op hetzelfde object. In de BAG zit bijvoorbeeld nergens waar de ingang van een pand zit. Of welke winkel of restaurant er zit. Of... Of... Daar moet je bij nadenken. Iets wat een individuele mapper zou moeten kunnen, maar wat een update script niet kan. -- m.v.g., Cartinus ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] BAG viewer
Op 30 oktober 2011 19:56 heeft Cartinus carti...@xs4all.nl het volgende geschreven: On Sunday 30 October 2011 19:26:09 Dick wrote: Dan kunnen we, als de bag data is gewijzigd de OSM data automatisch aanpassen. Het probleem is helemaal niet het volgen van de BAG wijzigingen. Dat is simpel. Het probleem is het respecteren van andere edits op hetzelfde object. In de BAG zit bijvoorbeeld nergens waar de ingang van een pand zit. Of welke winkel of restaurant er zit. Of... Of... Daar moet je bij nadenken. Iets wat een individuele mapper zou moeten kunnen, maar wat een update script niet kan. De oplossing voor dit probleem zoals ik het zie, is het maken van een script dat niet automatisch gaat updaten, maar dat een rapport aanmaakt met aandachtspunten waar medewerkers dan mee aan de slag kunnen om wijzigingen van upstream te gaan samenvoegen met de bijdragen van de medewerkers. Als daar vanwege upstream interesse voor is, kunnen bepaalde wijzigingen misschien ook teruggekoppeld worden. Een ander probleem zijn wijzigingen die moedwillig (vandalisme) of per ongeluk (onvervaren mapper o.i.d.) worden aangebracht. Eigenlijk zouden we dat ook moeten kunnen detecteren. mvg, Jo ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] BAG viewer
De bottleneck zit 'm in die 'medewerkers'. Wie gaat er door die gegenereerde rapporten heenwerken? We zijn allemaal vrijwilligers hier, met soms veel tijd maar meestal maar een klein beetje. Mensen komen, en mensen gaan ook weer. Ik heb zelf honderden, misschien wel duizenden building-objecten bewerkt in Nederland, maar woon nu in de VS en richt mijn schaarse vrije tijd op het verbeteren van de kaart hier. Zonder de continuiteit van een organisatie met vaste medewerkers kun je geen processen gaan inrichten die voor hun voortgang afhankelijk zijn van mensen. De geografische dimensie maakt het nog extra lastig. Iemand die in Schagen woont kan niet zonder meer BAG-mutaties samenvoegen met lokale OSM-mutaties in Ootmarsum, omdat de kans heel groot is dat je lokale kennis nodig hebt om te beslissen welke mutatie gehonoreerd moet worden in geval van conflicten. Een dataset als de BAG, die al zo goed wordt bijgehouden (bij wet geregeld!) door de lokale overheden, kan in de dynamiek van OSM geen goede plek vinden en heeft er dan ook niets te zoeken. Martijn. 2011/10/30 Jo winfi...@gmail.com: Op 30 oktober 2011 19:56 heeft Cartinus carti...@xs4all.nl het volgende geschreven: On Sunday 30 October 2011 19:26:09 Dick wrote: Dan kunnen we, als de bag data is gewijzigd de OSM data automatisch aanpassen. Het probleem is helemaal niet het volgen van de BAG wijzigingen. Dat is simpel. Het probleem is het respecteren van andere edits op hetzelfde object. In de BAG zit bijvoorbeeld nergens waar de ingang van een pand zit. Of welke winkel of restaurant er zit. Of... Of... Daar moet je bij nadenken. Iets wat een individuele mapper zou moeten kunnen, maar wat een update script niet kan. De oplossing voor dit probleem zoals ik het zie, is het maken van een script dat niet automatisch gaat updaten, maar dat een rapport aanmaakt met aandachtspunten waar medewerkers dan mee aan de slag kunnen om wijzigingen van upstream te gaan samenvoegen met de bijdragen van de medewerkers. Als daar vanwege upstream interesse voor is, kunnen bepaalde wijzigingen misschien ook teruggekoppeld worden. Een ander probleem zijn wijzigingen die moedwillig (vandalisme) of per ongeluk (onvervaren mapper o.i.d.) worden aangebracht. Eigenlijk zouden we dat ook moeten kunnen detecteren. mvg, Jo ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl -- martijn van exel geospatial omnivore 1109 1st ave #2 salt lake city, ut 84103 801-550-5815 http://oegeo.wordpress.com ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] BAG viewer
Met vriendelijke groeten, Robert Elsenaar (Verzonden vanaf Mobile) Martijn van Exel m...@rtijn.org schreef: De bottleneck zit 'm in die 'medewerkers'. Wie gaat er door die gegenereerde rapporten heenwerken? We zijn allemaal vrijwilligers hier, met soms veel tijd maar meestal maar een klein beetje. Mensen komen, en mensen gaan ook weer. Ik heb zelf honderden, misschien wel duizenden building-objecten bewerkt in Nederland, maar woon nu in de VS en richt mijn schaarse vrije tijd op het verbeteren van de kaart hier. Zonder de continuiteit van een organisatie met vaste medewerkers kun je geen processen gaan inrichten die voor hun voortgang afhankelijk zijn van mensen. De geografische dimensie maakt het nog extra lastig. Iemand die in Schagen woont kan niet zonder meer BAG-mutaties samenvoegen met lokale OSM-mutaties in Ootmarsum, omdat de kans heel groot is dat je lokale kennis nodig hebt om te beslissen welke mutatie gehonoreerd moet worden in geval van conflicten. Een dataset als de BAG, die al zo goed wordt bijgehouden (bij wet geregeld!) door de lokale overheden, kan in de dynamiek van OSM geen goede plek vinden en heeft er dan ook niets te zoeken. Martijn. 2011/10/30 Jo winfi...@gmail.com: Op 30 oktober 2011 19:56 heeft Cartinus carti...@xs4all.nl het volgende geschreven: On Sunday 30 October 2011 19:26:09 Dick wrote: Dan kunnen we, als de bag data is gewijzigd de OSM data automatisch aanpassen. Het probleem is helemaal niet het volgen van de BAG wijzigingen. Dat is simpel. Het probleem is het respecteren van andere edits op hetzelfde object. In de BAG zit bijvoorbeeld nergens waar de ingang van een pand zit. Of welke winkel of restaurant er zit. Of... Of... Daar moet je bij nadenken. Iets wat een individuele mapper zou moeten kunnen, maar wat een update script niet kan. De oplossing voor dit probleem zoals ik het zie, is het maken van een script dat niet automatisch gaat updaten, maar dat een rapport aanmaakt met aandachtspunten waar medewerkers dan mee aan de slag kunnen om wijzigingen van upstream te gaan samenvoegen met de bijdragen van de medewerkers. Als daar vanwege upstream interesse voor is, kunnen bepaalde wijzigingen misschien ook teruggekoppeld worden. Een ander probleem zijn wijzigingen die moedwillig (vandalisme) of per ongeluk (onvervaren mapper o.i.d.) worden aangebracht. Eigenlijk zouden we dat ook moeten kunnen detecteren. mvg, Jo ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl -- martijn van exel geospatial omnivore 1109 1st ave #2 salt lake city, ut 84103 801-550-5815 http://oegeo.wordpress.com ___ 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 viewer
Op vr 28 okt 2011 13:48:00 schreef Stefan de Konink: Op 28-10-11 13:06, Maarten Deen schreef: On Fri, 28 Oct 2011 12:51:23 +0200, Just van den Broecke wrote: Importeren van BAG in OSM is natuurlijk een andere optie maar dat is een aparte discussie die elders gevoerd wordt :-). Mag dat, BAG gegevens gebruken in OSM? Ja, maar laten we vooral OSM nog een grote rotzooi maken als de mag maandelijks door het Kadaster wordt geupdate en er nog _nooit_ 1 externe bron in OSM goed is gesynced. De BAG-data is juist een opruiming. Weg met die oude schots en scheve 3dShapes gebouwen. Dat het in verleden nooit goed gesynced is betekent niet dat het nu niet zou kunnen. Alleen moeten er dan wel korte termijn spijkers met koppen worden geslagen. Bij gebrek aan een landelijke regie beginnen individuele mappers beginnen nu al individuele steden van BAG-data te voorzien. Overigens ben ik er ook voorstander van om de individuele mappers (evt onder begeleiding) in te schakelen om hun stad (en omstreken) van de BAG-import te voorzien en landelijk alleen een regie te voeren. Up-to-date houden van de data zie ik niet direct als probleem, meer een technische uitdaging. Bovendien moet er ook over worden nagedacht hoe vaak je het wilt doen (een maal per maand lijkt mij schromelijk overdreven). Wat ik wil voorstellen is een combi-render. Zoals nu al gebeurd met de water/land grenzen. Hoe bedoel je dat precies? we hebben toch admin_level=2 en border_type=territorial in de database zitten? Ik blijf er bij dat de import in de OSM-database plaats moet vinden. Zoals ik net al schreef verspreidt deze gedacht zich ook naar andere gebruikers. Naast het alom bekende Nijmegen is nu ook Gorinchem voorzien van de BAG-data. In het bijbehorende forumtopic[1] worden ook Helmond en Putten als volgende kandidaten genoemd en persoonlijk heb ik ook wel zin om de gemeente Eindhoven aan te schrijven, al was het alleen maar om de update-procedure zelf eens te bestuderen. @Martijn: De laatste keer dat we hierover spraken, haalde jij de paneldiscussie I fight authority, Authority always wins aan op de SotM 2011 waar jij zelf ook deel van uitmaakte.[1] Is daar nog iets interessants/relevants voor deze discussie uitgekomen? Oliver [1] http://forum.openstreetmap.org/viewtopic.php?id=13917 [2] http://wiki.openstreetmap.org/wiki/SotM_2011_Panel:_I_fight_authority,_Authority_always_wins ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] BAG viewer
On 29-10-11 19:23, Stefan de Konink wrote: Het heeft exact het zelfde probleem als een landelijke import, alleen is de vervuiling lokaler. Als er regie gevoerd moet worden begin dan gewoon goed; dat wil zeggen: implementeer openmetamap op een manier dat het gebruikbaar is, en het geen grote geograbbelton wordt. Ik heb even op de Wiki gekeken wat OpenMetaMap nu precies inhoudt, en het idee is erg goed. Ik vrees alleen dat een en ander in de praktijk heel lastig te implementeren is. Daardoor zal het nog wel een tijd duren totdat dit beschikbaar is. Maar wat is het probleem als we in de tussentijd gecontroleerd de BAG al toevoegen? Op dit moment staat er 3dShapes die naar verwachting niet bijgewerkt gaat worden en van lagere kwaliteit is. Ik zie niet in waarom we niet ondertussen op kleine schaal de BAG zouden kunnen importeren. Als dan OpenMetaMap klaar is, dan kan alles toch nog overgezet worden? Daarmee kunnen bronnen worden gerespecteerd, en data op een juiste wijzen kan 'geciteerd' worden. Updates bijhouden en updates terug laten vloeien naar gemeentes lijkt me dan erg goed. Daar is nu geen infrastructuur voor, niet in OSM niet bij het Kadaster en al zeker niet bij de gemeentes. Maar dit is wel de burgerparticipatie die we nodig hebben. Het terug laten vloeien van bijgewerkte gegevens naar de gemeenten lijkt me zinvol, maar ik vraag me af of de overheid daar zelf behoefte aan heeft. Ik denk dat ze vanwege de nauwkeurigheid alle gebouwen toch zelf willen opmeten -- OSM'ers zijn ten slotte geen landmeters die punten op de decimeter nauwkeurig kunnen inmeten. Daarbij is het dus van belang dat als iemand in de Kadaster data edit, hij expliciet toestemming geeft dat zijn data ook gebruikt mag worden om verbetering door te voeren. Dat betekent weer dat daarop geen ODbL kan zitten... Dat weet ik niet, mijn juridische kennis is niet bepaald goed te noemen. :-) ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] BAG viewer
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Op 29-10-11 19:41, Willem Sonke schreef: Maar wat is het probleem als we in de tussentijd gecontroleerd de BAG al toevoegen? Op dit moment staat er 3dShapes die naar verwachting niet bijgewerkt gaat worden en van lagere kwaliteit is. Ik zie niet in waarom we niet ondertussen op kleine schaal de BAG zouden kunnen importeren. Als dan OpenMetaMap klaar is, dan kan alles toch nog overgezet worden? Het probleem is juist het overzetten. Als ObjectIDs stabiel zijn, dan is er geen probleem. Maar juist een systeem dat dat stukje monitort en intelligent is om fouten op te sporen en te herstellen... dat ontbreekt. Als het nou om data ging die 1x per jaar wordt geupdate... maar het gaat om data die technisch gezien realtime geupdate kan worden. Het terug laten vloeien van bijgewerkte gegevens naar de gemeenten lijkt me zinvol, maar ik vraag me af of de overheid daar zelf behoefte aan heeft. Ik denk dat ze vanwege de nauwkeurigheid alle gebouwen toch zelf willen opmeten -- OSM'ers zijn ten slotte geen landmeters die punten op de decimeter nauwkeurig kunnen inmeten. Als een OSM'er aangeeft: deze invloed klopt niet. Is die constatering even waardevol als verbeterjebuurt.nl Stefan -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEAREKAAYFAk6sVIMACgkQYH1+F2Rqwn3UCQCfQog56E+ewwq1wPdxEKgYjDqq ChcAniDU+3Fa3wLnZAKjMzUnCSin8aDx =BaT4 -END PGP SIGNATURE- ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] BAG viewer
On Saturday 29 October 2011 19:41:03 Willem Sonke wrote: On 29-10-11 19:23, Stefan de Konink wrote: Het heeft exact het zelfde probleem als een landelijke import, alleen is de vervuiling lokaler. Als er regie gevoerd moet worden begin dan gewoon goed; dat wil zeggen: implementeer openmetamap op een manier dat het gebruikbaar is, en het geen grote geograbbelton wordt. Ik heb even op de Wiki gekeken wat OpenMetaMap nu precies inhoudt, en het idee is erg goed. Ik vrees alleen dat een en ander in de praktijk heel lastig te implementeren is. Daardoor zal het nog wel een tijd duren totdat dit beschikbaar is. Maar wat is het probleem als we in de tussentijd gecontroleerd de BAG al toevoegen? Op dit moment staat er 3dShapes die naar verwachting niet bijgewerkt gaat worden en van lagere kwaliteit is. Ik zie niet in waarom we niet ondertussen op kleine schaal de BAG zouden kunnen importeren. Als OpenMetaMap ooit van vapourware verandert in realiteit zal het zeker een mooie tool zijn. Tot die tijd kan het ook volgens mij geen kwaad als lokale mappers selectief de onnauwkeurige en/of verouderde 3dShapes vervangen door wat beters. On Saturday 29 October 2011 21:31:15 Stefan de Konink wrote: Het probleem is juist het overzetten. Als ObjectIDs stabiel zijn, dan is er geen probleem. Maar juist een systeem dat dat stukje monitort en intelligent is om fouten op te sporen en te herstellen... dat ontbreekt. Voor monitoring van veranderingen in de brondata heb je helemaal geen stabiele ObjectID's binnen OSM nodig. Daarvoor heb je de brondata van nu en de brondata zoals hij was toen je er de vorige keer naar keek nodig. Zolang een lokale mapper een gebied in de gaten houd dat niet al te groot is, zal het geen probleem zijn om die wijzigingen _met de hand_ in OSM te verwerken. Zoveel wordt er in Nederland nu ook weer niet ge- en verbouwd. -- m.v.g., Cartinus ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] BAG viewer
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Op 29-10-11 23:38, Cartinus schreef: Zoveel wordt er in Nederland nu ook weer niet ge- en verbouwd. ...je hebt werkelijk geen idee. Dat je geen object ids nodig hebt kan kloppen als het systeem in 1 klap alle data laat importeren en daarmee het systeem laat bij houden welke data is ingevoerd en welke data mapt naar welk object. Maar goed je noede het zelf net vaporware. Laten we vooral alles wat goed beschreven is voordat het gebouwd dient te worden afschilderen als vaporware, daar schieten we wat mee op. Stefan -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEAREKAAYFAk6sg5gACgkQYH1+F2Rqwn3+qQCeIiGgFPD5DPGusVssI95SWSU4 K9YAoIQ/SI6kx3UvRPzKF6/FGxIVE7cV =f+0z -END PGP SIGNATURE- ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] BAG viewer
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Op 28-10-11 13:06, Maarten Deen schreef: On Fri, 28 Oct 2011 12:51:23 +0200, Just van den Broecke wrote: Importeren van BAG in OSM is natuurlijk een andere optie maar dat is een aparte discussie die elders gevoerd wordt :-). Mag dat, BAG gegevens gebruken in OSM? Ja, maar laten we vooral OSM nog een grote rotzooi maken als de mag maandelijks door het Kadaster wordt geupdate en er nog _nooit_ 1 externe bron in OSM goed is gesynced. Wat ik wil voorstellen is een combi-render. Zoals nu al gebeurd met de water/land grenzen. Maar dan alle gemeente grenzen, en gebouwen uit BAG. Ik heb voor de liefhebbers ook een aanvraag gedaan om de beide OpenStreetMap.nl servers aan te sluiten op PDOK.nl Stefan -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEAREKAAYFAk6qlnAACgkQYH1+F2Rqwn2+8gCfQQd/YJzF5lNrXaEB3xYSXz/E kYoAnj+BrC1RaOVI5I1eWbrdRu/PxqNI =23zK -END PGP SIGNATURE- ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] BAG viewer
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Op 28-10-11 14:10, Maarten Deen schreef: Ik heb namelijk zelf de woonplaatsgrenzen voor mijn gemeente ingetekend. Het is allemaal erg ruw en gebaseerd op wat ik weet en hoe de postcodes lopen en de BAG geeft daar een paar leuke verduidelijkingen. Dat kan en mag ik dus aanpassen ;-) Pas op... fundamentele discussie... Kadaster zou de autoriteit moeten zijn op het gebied van die data. Als jij 'verduidelijkingen' belangrijk vindt moet er een manier zijn om die data aan jouw gemeente te overleggen... OpenMetaMap implementeren voor de BAG? Vrijwilligers? En dan ga ik ook mijn tuinhuisje intekenen :-D ;) Spielerij ;) Stefan -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEAREKAAYFAk6qnikACgkQYH1+F2Rqwn0z2gCeKoKZOG3IPMKA2kegZwAmffBz oAYAoIwYVPti+yob1YweV7oX9ny3burU =lOcm -END PGP SIGNATURE- ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] BAG viewer
En dan ga ik ook mijn tuinhuisje intekenen :-D ;) Spielerij ;) Als de volgende mapping party daar doorgaat, moeten we dat natuurlijk wel weten te vinden, he. Hij moet dan wel zorgen voor Wifi, ook, vind ik. Jo ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] BAG viewer
Dat lijkt me gaaf. Robert -Oorspronkelijk bericht- From: Martijn van Exel Sent: Friday, October 28, 2011 4:49 PM To: OpenStreetMap NL discussion list Subject: Re: [OSM-talk-nl] BAG viewer Een manier is converteren naar SHP met de BAG-conversietool [1] en dan een tiled layer aanmaken met bijv Geoserver. Is nog steeds een hoop werk, vanwege de inmense grootte van het BAG-bestand. Je kunt ook de tile-configuratie van de BAG viewer achterhalen en die in JOSM prikken, denkelijk? [1] https://github.com/MinIenM/BAG-Extract 2011/10/27 Robert Elsenaar rob...@elsenaar.info: vertel, vertel. Hoe projrcteer ik BAG op OSM? Met vriendelijke groeten, Robert Elsenaar (Verzonden vanaf Mobile) Stefan de Konink ste...@konink.de schreef: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Op 27-10-11 21:51, Jeroen Muris schreef: In ieder geval leuk om eens te zijn wat er nu eigenlijk in de veelbesproken BAG zit... Uiteraard als je de vector versie op openstreetmap wilt zien ;) Kan dat ook wel geregeld worden. Stefan -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEAREKAAYFAk6pyZcACgkQYH1+F2Rqwn3UbQCglQiNl+ngY7MWY75g9EiEDonp MxAAn03JNZ7ZD8MZYXQ3sNBCWNZqqSPQ =oniZ -END PGP SIGNATURE- ___ 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 geospatial omnivore 1109 1st ave #2 salt lake city, ut 84103 801-550-5815 http://oegeo.wordpress.com ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl --- Tekst ingevoegd door Panda GP 2011: Als het hier gaat om een ongevraagde e-mail (SPAM), klik dan op de volgende link om de e-mail te herclasseren: http://localhost:6083/Panda?ID=pav_10691SPAM=truepath=C:\Windows\system32\config\systemprofile\AppData\Local\Panda%20Security\Panda%20Global%20Protection%202011\AntiSpam --- ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
