Re: [Talk-ca] GeoTiff in JOSM
-Original Message- Subject: Re: [Talk-ca] GeoTiff in JOSM On Fri, Sep 2, 2011 at 12:55 PM, penorman penor...@mac.com wrote: I'm at work and going on vacation so I can't give a detailed answer for a few days, but this might help No problem, any help is appreciated. Once the tiles are made you can serve the directories with apache or another web server. Ah, okay I didn't realize it was that simple. I believe you can also have JOSM get files directly from your hard drive, but I'm not sure the syntax to do so on the Mac. xjjk from the OSM IRC channel has a parallized version of gdal2tiles which can significantly help processing times if you have a multi-core CPU. Would that be maptiler? Maptiler is essentially a graphical front-end to gdal2tiles. Xjjk's version is the command line version modified. My iMac broke awhile back so I'm not sure how easy/hard GDAL is to set up with python bindings on OS X. I've got a dual quad-core Xeon Mac Pro with 14 gb of ram so a parallelized version would be a must. :) You'll still be limited by your CPU :P I'll have to give it a shot and see how long it takes to process some portion of my GeoTiff. The tiled GeoTiff is about 16 GB, where the original MrSid is 1.9GB. Might be doable. :) What I did for testing was work on a small section downloaded separately and benchmarked with different image scaling methods. The three worth considering are nearest, antialias, and lanczos. Nearest is fastest, preserves sharp edges but has the worst quality. Antialias is decently fast, decent quality. Lanczos is the best quality, preserves edges but is extremely slow. ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] GeoTiff in JOSM
I believe you can also have JOSM get files directly from your hard drive, but I'm not sure the syntax to do so on the Mac. I did a render with gdal2tiles and was able to get it working fine in Merkaator. Something about the tile number origin being opposite in JOSM. Maptiler is essentially a graphical front-end to gdal2tiles. Xjjk's version is the command line version modified. My iMac broke awhile back so I'm not sure how easy/hard GDAL is to set up with python bindings on OS X. Ah, okay. I'll have to drop Xjik a line and see if I can get a copy of the modified command line file. It seems there WAS a version of gdal2tiles tat was optimized for multi-core, but the author seems to be charging for it. There is a pre-made gdal install package for OSX, so it was extremely easy to get up. Click and install. You'll still be limited by your CPU :P On a single core my 1.9GB image took around 6 hours. So not too bad but faster would be nice. What I did for testing was work on a small section downloaded separately and benchmarked with different image scaling methods. The three worth considering are nearest, antialias, and lanczos. Nearest is fastest, preserves sharp edges but has the worst quality. Antialias is decently fast, decent quality. Lanczos is the best quality, preserves edges but is extremely slow. I'll have to try modifying the render settings and see how it goes. I'll probably want to get the parallelized version first though. THanks! Tyler ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] BC Open Data License compatibility
On 9/4/2011 6:51 PM, john whelan wrote: The issue with using data like this with OSM is when you contribute it under the new contribution terms you accept that OSM can change the license at a later date. Practically speaking it makes it impossible to respect any other license so currently only PD data and things you have explicitly mapped yourself are safe. In the OSM talk thread there are people who seem to think that all imports are bad and I suspect the license change clause was put in by them to discourage imports. No, it was put in because we didn't want to have a rerun of all this mess if something better came along next time. Steve Cheerio John On 4 September 2011 19:35, Russell Porter cont...@russellporter.com mailto:cont...@russellporter.com wrote: Hi, What is the status on the BC Open Data site launched earlier this year? License: http://www.data.gov.bc.ca/dbc/admin/terms.page? It looks fine to me, but i know licensing is a big problem with osm. In particular, i am looking at doing a manual import of protected areas amd hiking trails (I imported a bunch of NrCan protected areas a while back) Finally, another license question. Since Sam V. (across canada trails) released his contribs as PD, cant i just re-import them into OSM on my account under odbl? Thanks, Russell ___ Talk-ca mailing list Talk-ca@openstreetmap.org mailto:Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] BC Open Data License compatibility
No, it was put in because we didn't want to have a rerun of all this mess if something better came along next time. Steve Unfortunately it had implications that don't seem to have been thought through especially for imports which I think are important for Canada where we seem to have lots of places to map and a lower density of mappers on the ground than some areas. Cheerio John ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] BC Open Data License compatibility
Maybe it wasn't thought through and maybe it has implications, but that wasn't the point. Steve stevecoast.com On Sep 7, 2011, at 17:56, john whelan jwhelan0...@gmail.com wrote: No, it was put in because we didn't want to have a rerun of all this mess if something better came along next time. Steve Unfortunately it had implications that don't seem to have been thought through especially for imports which I think are important for Canada where we seem to have lots of places to map and a lower density of mappers on the ground than some areas. Cheerio John ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] BC Open Data License compatibility
Thanks for the clarification Steve and John. I'm a software developer, not a lawyer, but hearing this really killed OSM for me. PD would solve all the license shit we have to put up with - I won't list the reasons why, we have all heard them before. Too bad some people are hellbent on making sure corporations don't use OSM data as they please. It is a detriment to the project, and for most people, they would probably be happy to see their road being used in google maps, attribution or not. Better than not seeing the road on any popular map at least. I can't say I will be contributing to the project any more if the switch to ODBL and new CT goes ahead as planned. It is painful enough a transition, we might as well just take the leap to PD. Too bad, because the opportunities for software development with OSM are just beginning. Legalese is killing us when we should be focusing on making OSM better in all respects. Regards, Russell On Wed, Sep 7, 2011 at 9:32 PM, talk-ca-requ...@openstreetmap.org wrote: Send Talk-ca mailing list submissions to talk-ca@openstreetmap.org To subscribe or unsubscribe via the World Wide Web, visit http://lists.openstreetmap.org/listinfo/talk-ca or, via email, send a message with subject or body 'help' to talk-ca-requ...@openstreetmap.org You can reach the person managing the list at talk-ca-ow...@openstreetmap.org When replying, please edit your Subject line so it is more specific than Re: Contents of Talk-ca digest... Today's Topics: 1. CANVEC data and .odbl (john whelan) 2. Re: GeoTiff in JOSM (Tyler Gunn) 3. Re: BC Open Data License compatibility (SteveC) 4. Re: BC Open Data License compatibility (john whelan) 5. BC Highway tagging (Paul Norman) 6. Re: BC Open Data License compatibility (Steve Coast) -- Message: 1 Date: Wed, 7 Sep 2011 07:47:48 -0400 From: john whelan jwhelan0...@gmail.com To: Talk-CA OpenStreetMap talk-ca@openstreetmap.org Subject: [Talk-ca] CANVEC data and .odbl Message-ID: CAJ-Ex1HCu-wTaeT=qhuyn1b+ogquddywjm-7ravdj5ejllc...@mail.gmail.com Content-Type: text/plain; charset=iso-8859-1 I was in JOSM and noticed some data that looked as if it was CANVEC imports but had been done by someone who has drifted off and not agreed to the new CT. Is it worth someone doing a search for source CANVEC and CT not agreed for the whole of Canada so this data could be reimported whilst it can still be easily identified? The alternative is its gets deleted then its more difficult to identify which bits need to be reimported. I'm not volunteering by the way merely identifying a possible problem area. Cheerio John -- next part -- An HTML attachment was scrubbed... URL: http://lists.openstreetmap.org/pipermail/talk-ca/attachments/20110907/1914ceed/attachment-0001.html -- Message: 2 Date: Wed, 7 Sep 2011 08:44:47 -0500 From: Tyler Gunn ty...@egunn.com To: Paul Norman penor...@mac.com Cc: talk-ca@openstreetmap.org Subject: Re: [Talk-ca] GeoTiff in JOSM Message-ID: CAPUij2uVRBHea8fK8xkNLHHjpA8i=shf5sbm0tb569fbugi...@mail.gmail.com Content-Type: text/plain; charset=ISO-8859-1 I believe you can also have JOSM get files directly from your hard drive, but I'm not sure the syntax ?to do so on the Mac. I did a render with gdal2tiles and was able to get it working fine in Merkaator. Something about the tile number origin being opposite in JOSM. Maptiler is essentially a graphical front-end to gdal2tiles. Xjjk's version is the command line version modified. My iMac broke awhile back so I'm not sure how easy/hard GDAL is to set up with python bindings on OS X. Ah, okay. I'll have to drop Xjik a line and see if I can get a copy of the modified command line file. It seems there WAS a version of gdal2tiles tat was optimized for multi-core, but the author seems to be charging for it. There is a pre-made gdal install package for OSX, so it was extremely easy to get up. Click and install. You'll still be limited by your CPU :P On a single core my 1.9GB image took around 6 hours. So not too bad but faster would be nice. What I did for testing was work on a small section downloaded separately and benchmarked with different image scaling methods. The three worth considering are nearest, antialias, and lanczos. Nearest is fastest, preserves sharp edges but has the worst quality. Antialias is decently fast, decent quality. Lanczos is the best quality, preserves edges but is extremely slow. I'll have to try modifying the render settings and see how it goes. I'll probably want to get the parallelized version first though. THanks! Tyler -- Message: 3 Date: Wed, 07 Sep 2011 17:24:19 -0600 From: SteveC st...@asklater.com To: talk-ca@openstreetmap.org Subject: Re
