Re: [OSM-talk-nl] intransparantie m.b.t. rechtmatigheid geimporteerde data
On Tue, 24 Nov 2009, Freek wrote: On Monday 23 November 2009 23:02:50 Stefan de Konink wrote: Oftewel kijk eens op onze blog terug; http://blog.openstreetmap.nl/index.php/2009/03/02/een-mirror-en-nieuwe-data Hee, ik lees daar dat er ook hoogte-informatie beschikbaar is, waarom is dat niet meegenomen bij de import? Datamodel osm suckt ;) Stefan ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] intransparantie m.b.t. rechtmatigheid geimporteerde data
On Tuesday 24 November 2009 09:28:45 Stefan de Konink wrote: On Tue, 24 Nov 2009, Freek wrote: On Monday 23 November 2009 23:02:50 Stefan de Konink wrote: Oftewel kijk eens op onze blog terug; http://blog.openstreetmap.nl/index.php/2009/03/02/een-mirror-en-nieuwe- data Hee, ik lees daar dat er ook hoogte-informatie beschikbaar is, waarom is dat niet meegenomen bij de import? Datamodel osm suckt ;) Ik dacht meer aan een simpele height-tag op elk gebouw... -- Freek ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] intransparantie m.b.t. rechtmatigheid geimporteerde data
On Tue, 24 Nov 2009, Freek wrote: Ik dacht meer aan een simpele height-tag op elk gebouw... 3dshapes gaat volgens mij over vormen, dus ook schuine daken. Stefan ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] intransparantie m.b.t. rechtmatigheid geimporteerde data
Hee, ik lees daar dat er ook hoogte-informatie beschikbaar is, waarom is dat niet meegenomen bij de import? De eerste conversie was wel gedaan met de hoogte erop, maar er bleek al snel zoveel variatie in te zitten, zelfs tussen identieke huizenblokken in dezelfde straat, dat het beter leek om geen hoogte-informatie mee te nemen dan foute informatie. De hoogte van de gebouwen was ook t.o.v. NAP, dus in bijvoorbeeld Maastricht hadden we opeens allemaal gebouwen van richting de 100 m hoogte. Dat viel bij de eerste proefimports (Ilpendam, Heiloo) nog niet op. -- Lennard ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] intransparantie m.b.t. rechtmatigheid geimporteerde data
On Tuesday 24 November 2009 09:41:17 Stefan de Konink wrote: On Tue, 24 Nov 2009, Freek wrote: Ik dacht meer aan een simpele height-tag op elk gebouw... 3dshapes gaat volgens mij over vormen, dus ook schuine daken. Snap ik, maar dan kan je toch nog steeds de hoogte van het hoogste punt invoeren? (Dat is waarschijnlijk waar de meeste mensen aan denken als je vraagt wat de hoogte van een gebouw is.) -- Freek ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] intransparantie m.b.t. rechtmatigheid geimporteerde data
2009/11/24 Stefan de Konink ste...@konink.de: On Tue, 24 Nov 2009, Freek wrote: Ik dacht meer aan een simpele height-tag op elk gebouw... 3dshapes gaat volgens mij over vormen, dus ook schuine daken. Nee, het zijn simpele objecten met een hoogteattribuut. Ik meen dat het niet eens een echt 3D-shapebestand is. Dat hoogteattribuut zouden we dus zo kunnen meenemen in een import. Martijn ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] intransparantie m.b.t. rechtmatigheid geimporteerde data
2009/11/24 Roeland Douma u...@rullzer.com: On Tue, 24 Nov 2009 09:28:45 +0100 (CET), Stefan de Konink ste...@konink.de wrote: On Tue, 24 Nov 2009, Freek wrote: On Monday 23 November 2009 23:02:50 Stefan de Konink wrote: Oftewel kijk eens op onze blog terug; http://blog.openstreetmap.nl/index.php/2009/03/02/een-mirror-en-nieuwe-data Hee, ik lees daar dat er ook hoogte-informatie beschikbaar is, waarom is dat niet meegenomen bij de import? Datamodel osm suckt ;) Probleem is vooral dat de hoogte in 3dShapes wat te wensen overlaat. * Tussen twee huizen kan zomaar 3 meter hoogte verschil zitten. Terwijl het toch vrijwel identieke huizen zijn (voor mijn niet-timmermans oog dan) * Hoogtes zijn relatief ten opzichte van het NAP niet ten opzichte van de grond. En daar we geen mooi hoogte bestand hebben daarvoor is het erg lastig hoogte gokken. --Roeland Wat het eerste punt betreft: er zitten rare dingen in, maar het is nog altijd veel beter dan niks. In de AND-data zaten ook *veel* 'rare dingen'. Punt twee: we kunnen daar SRTM voor gebruiken. Perfect is het niet, maar voor Nederland redelijk geschikt. De resolutie is 45m. Voor meer detail zouden we AHN moeten nemen, maar ik zie niet zo gauw gebeuren dat dat wordt vrijgegeven. Martijn martijn van exel http://schaaltreinen.nl/ twitter / skype: mvexel flickr: rhodes ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] intransparantie m.b.t. rechtmatigheid geimporteerde data
On Tue, 24 Nov 2009, Martijn van Exel wrote: Voor meer detail zouden we AHN moeten nemen, maar ik zie niet zo gauw gebeuren dat dat wordt vrijgegeven. Waarom niet? Stefan ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] intransparantie m.b.t. rechtmatigheid geimporteerde data
On Tuesday 24 November 2009 10:13:05 Martijn van Exel wrote: 2009/11/24 Roeland Douma u...@rullzer.com: Probleem is vooral dat de hoogte in 3dShapes wat te wensen overlaat. * Tussen twee huizen kan zomaar 3 meter hoogte verschil zitten. Terwijl het toch vrijwel identieke huizen zijn (voor mijn niet-timmermans oog dan) * Hoogtes zijn relatief ten opzichte van het NAP niet ten opzichte van de grond. En daar we geen mooi hoogte bestand hebben daarvoor is het erg lastig hoogte gokken. --Roeland Wat het eerste punt betreft: er zitten rare dingen in, maar het is nog altijd veel beter dan niks. In de AND-data zaten ook *veel* 'rare dingen'. Punt twee: we kunnen daar SRTM voor gebruiken. Perfect is het niet, maar voor Nederland redelijk geschikt. De resolutie is 45m. Voor meer detail zouden we AHN moeten nemen, maar ik zie niet zo gauw gebeuren dat dat wordt vrijgegeven. Met 3m afwijking valt nog te leven, 45m lijkt me wat te veel... -- Freek ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] intransparantie m.b.t. rechtmatigheid geimporteerde data
On Tue, 24 Nov 2009, Freek wrote: Met 3m afwijking valt nog te leven, 45m lijkt me wat te veel... En zelfs met dat hoogte bestand. Waarom wil je het materialiseren in OSM. In plaats van een functie in de renderer. Stefan ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] intransparantie m.b.t. rechtmatigheid geimporteerde data
2009/11/24 Freek freek_...@vanwal.nl: On Tuesday 24 November 2009 10:13:05 Martijn van Exel wrote: 2009/11/24 Roeland Douma u...@rullzer.com: Probleem is vooral dat de hoogte in 3dShapes wat te wensen overlaat. * Tussen twee huizen kan zomaar 3 meter hoogte verschil zitten. Terwijl het toch vrijwel identieke huizen zijn (voor mijn niet-timmermans oog dan) * Hoogtes zijn relatief ten opzichte van het NAP niet ten opzichte van de grond. En daar we geen mooi hoogte bestand hebben daarvoor is het erg lastig hoogte gokken. --Roeland Wat het eerste punt betreft: er zitten rare dingen in, maar het is nog altijd veel beter dan niks. In de AND-data zaten ook *veel* 'rare dingen'. Punt twee: we kunnen daar SRTM voor gebruiken. Perfect is het niet, maar voor Nederland redelijk geschikt. De resolutie is 45m. Voor meer detail zouden we AHN moeten nemen, maar ik zie niet zo gauw gebeuren dat dat wordt vrijgegeven. Met 3m afwijking valt nog te leven, 45m lijkt me wat te veel... Sorry, dat is de resolutie in het XY-vlak. Elke cel is 45m groot. De reolutie in de hoogte is vziw 1m. Martijn ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] intransparantie m.b.t. rechtmatigheid geimporteerde data
SRTM is erg onnauwkeurig om de grondhoogte te bapelen. De afwijking zal hier eerder stuk groter van worden. Denk dat we er dan meer aan hebben als mensen gewoon gokken hoe hoog een gebouw is dan proberen het semi automatisch erin te knallen. --Roeland On Tue, 24 Nov 2009 10:49:36 +0100, Martijn van Exel mve...@gmail.com wrote: 2009/11/24 Freek freek_...@vanwal.nl: On Tuesday 24 November 2009 10:13:05 Martijn van Exel wrote: 2009/11/24 Roeland Douma u...@rullzer.com: Probleem is vooral dat de hoogte in 3dShapes wat te wensen overlaat. * Tussen twee huizen kan zomaar 3 meter hoogte verschil zitten. Terwijl het toch vrijwel identieke huizen zijn (voor mijn niet-timmermans oog dan) * Hoogtes zijn relatief ten opzichte van het NAP niet ten opzichte van de grond. En daar we geen mooi hoogte bestand hebben daarvoor is het erg lastig hoogte gokken. --Roeland Wat het eerste punt betreft: er zitten rare dingen in, maar het is nog altijd veel beter dan niks. In de AND-data zaten ook *veel* 'rare dingen'. Punt twee: we kunnen daar SRTM voor gebruiken. Perfect is het niet, maar voor Nederland redelijk geschikt. De resolutie is 45m. Voor meer detail zouden we AHN moeten nemen, maar ik zie niet zo gauw gebeuren dat dat wordt vrijgegeven. Met 3m afwijking valt nog te leven, 45m lijkt me wat te veel... Sorry, dat is de resolutie in het XY-vlak. Elke cel is 45m groot. De reolutie in de hoogte is vziw 1m. Martijn ___ 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] intransparantie m.b.t. rechtmatigheid geimporteerde data
On Tue, 24 Nov 2009, Freek wrote: Horizontale nauwkeurigheid is niet zo boeiend in NL zou ik zeggen :-) Dus je wilt heel de data set als losse XY punten importeren? (Ben ik hier de enige die dat totaal onzinnig vind?) Geeft wel een leuk effect 'waarom staat dat grid met puntjes in NL?' Stefan ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] intransparantie m.b.t. rechtmatigheid geimporteerde data
On Tue, 24 Nov 2009, Rob wrote: Op 24 november 2009 11:54 heeft Stefan de Konink ste...@konink.de het volgende geschreven: Ga je samen met Bas ook invoeren hoe breedt de deuren zijn ;) ik wil er niet aan denken wat er gebeurt als je met je rolmaat voor iemands deur staan te meten ;) bel de ambulance maar alvast Sommige mensen zullen HEEL hulpvaardig zijn las lik laatst op talk-nl :D Stefan ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] intransparantie m.b.t. rechtmatigheid geimporteerde data
Je hebt gelijk. SRTM corrigeert niet voor gebouwen / vegetatie. Is dus onbruikbaar voor corrigeren van de 3dshapes. AHN heeft wel een bestand dat gefilterd is op vegetatie en gebouwen. martijn van exel http://schaaltreinen.nl/ twitter / skype: mvexel flickr: rhodes 2009/11/24 Roeland Douma u...@rullzer.com: SRTM is erg onnauwkeurig om de grondhoogte te bapelen. De afwijking zal hier eerder stuk groter van worden. Denk dat we er dan meer aan hebben als mensen gewoon gokken hoe hoog een gebouw is dan proberen het semi automatisch erin te knallen. --Roeland On Tue, 24 Nov 2009 10:49:36 +0100, Martijn van Exel mve...@gmail.com wrote: 2009/11/24 Freek freek_...@vanwal.nl: On Tuesday 24 November 2009 10:13:05 Martijn van Exel wrote: 2009/11/24 Roeland Douma u...@rullzer.com: Probleem is vooral dat de hoogte in 3dShapes wat te wensen overlaat. * Tussen twee huizen kan zomaar 3 meter hoogte verschil zitten. Terwijl het toch vrijwel identieke huizen zijn (voor mijn niet-timmermans oog dan) * Hoogtes zijn relatief ten opzichte van het NAP niet ten opzichte van de grond. En daar we geen mooi hoogte bestand hebben daarvoor is het erg lastig hoogte gokken. --Roeland Wat het eerste punt betreft: er zitten rare dingen in, maar het is nog altijd veel beter dan niks. In de AND-data zaten ook *veel* 'rare dingen'. Punt twee: we kunnen daar SRTM voor gebruiken. Perfect is het niet, maar voor Nederland redelijk geschikt. De resolutie is 45m. Voor meer detail zouden we AHN moeten nemen, maar ik zie niet zo gauw gebeuren dat dat wordt vrijgegeven. Met 3m afwijking valt nog te leven, 45m lijkt me wat te veel... Sorry, dat is de resolutie in het XY-vlak. Elke cel is 45m groot. De reolutie in de hoogte is vziw 1m. Martijn ___ 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 ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
[OSM-talk-nl] intransparantie m.b.t. rechtmatigheid geimporteerde data (was: Re: Noordelijke mapping party - Update)
++ 23/11/09 22:31 +0100 - Stefan de Konink: Licentie van het moment van downloaden was ccbysa. Gezien Martijn's bedenkingen is het wellicht zinvol om iets uitgebreider te zijn. Zou je misschien kunnen aangegeven op basis waarvan je de claim kunt maken dat het om CC BY-SA gelicentieerd materiaal gaat? Zoals afgesproken niet op de publieke lijst. Eeuh? Ik vind dit persoonlijk een bijzonder vreemd antwoord. Ik weet ook best dat CC BY-SA geen verplichting met zich mee brengt bewijs voor de rechtmatigheid van het gebruik te openbaren. Desondanks lijkt me dat wel een bijzonder gezond uitgangspunt voor een project als OpenStreetMap. Voor mij gaat OpenStreetMap over de openheid, de toegangelijkheid en de transparatie van data. Dat gaat mijn inziens om geografische informatie, maar ook om hetgeen wat daar direct een relatie mee heeft. Het niet- publiekelijke zijn van het bewijs voor de rechtmatigheid van het gebruik van de informatie die aan deze import ten grondslag ligt, is mijn inziens daarmee strijdig. Ik heb geen reden om aan de juridische correctheid te twijfelen. Het tegenovergestelde overigens ook niet. -- Rejo Zenger . r...@zenger.nl . 0x21DBEFD4 . https://rejo.zenger.nl GPG encrypted e-mail prefered. signature.asc Description: Digital signature ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] intransparantie m.b.t. rechtmatigheid geimporteerde data
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Rejo Zenger schreef: ++ 23/11/09 22:31 +0100 - Stefan de Konink: Licentie van het moment van downloaden was ccbysa. Gezien Martijn's bedenkingen is het wellicht zinvol om iets uitgebreider te zijn. Zou je misschien kunnen aangegeven op basis waarvan je de claim kunt maken dat het om CC BY-SA gelicentieerd materiaal gaat? Zoals afgesproken niet op de publieke lijst. Eeuh? Ik vind dit persoonlijk een bijzonder vreemd antwoord. Ik ben blij dat jij het persoonlijk een erg vreemd antwoord vindt. Ik investeer in mijn relaties om voor OSM data te verkrijgen. Ik ga niet al mijn (non-)WOB mailtjes publiceren op talk-nl en alles wat er toedoet staat op bestaande geo data hergebruiken. Oftewel kijk eens op onze blog terug; http://blog.openstreetmap.nl/index.php/2009/03/02/een-mirror-en-nieuwe-data/ Stefan -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.13 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEAREKAAYFAksLBooACgkQYH1+F2Rqwn3F0ACeJzOnTLCaZ2bMpjU/qCIwxYiE xDEAnjAcb7NIaTNpg811OWtKTJN0hReF =gmp/ -END PGP SIGNATURE- ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] intransparantie m.b.t. rechtmatigheid geimporteerde data
On Monday 23 November 2009 23:02:50 Stefan de Konink wrote: Oftewel kijk eens op onze blog terug; http://blog.openstreetmap.nl/index.php/2009/03/02/een-mirror-en-nieuwe-data Hee, ik lees daar dat er ook hoogte-informatie beschikbaar is, waarom is dat niet meegenomen bij de import? -- Freek ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
