RE: [OSGeo-Discuss] 'lossless' JPEG2000
Christopher - You will very likely find that using different LZW compression options (particularly setting a small strip size) will slightly degrade compression performance while significantly improving read time. While I think your test data are valid, they only address one of many possible configurations and I wouldn't necessarily make broad generalizations about LZW from them. However, I have generally found that LZW compression for photographic data is indeed not a good choice; I'm surprised you got it to perform as well as you did (in compression). - Ed Ed McNierney Chief Mapmaker Demand Media / TopoZone.com 73 Princeton Street, Suite 305 North Chelmsford, MA 01863 Phone: 978-251-4242, Fax: 978-251-1396 [EMAIL PROTECTED] -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Christopher Schmidt Sent: Monday, February 25, 2008 8:57 PM To: discuss@lists.osgeo.org Subject: Re: [OSGeo-Discuss] 'lossless' JPEG2000 On Mon, Feb 25, 2008 at 04:31:34PM -0800, Michael P. Gerlek wrote: Yup: Kakadu is not Open Source, as per the OSI definition of the term. The only FOSS package I know of is OpenJpeg2000 (or something like that); unfortunately, however, it is not suitable for geo-sized imagery last time I looked. Yep. (LZW tiffs are a reasonable option, as they are lossless and the LZW patent issues have faded into the sunset.) The level of compression from LZW is poor by comparison, on aerial imagery: a test dataset compressed from 169MB to 83MB, and time to serve up a small portion was approximately the same as with JPG (6.1s jpg, 6.5s lzw, .5s uncompressed), but the JPG was compressed to 13MB, making it worth the cost; lzw doesn't pay for itself in the same way. (See numbers on http://wiki.openaerialmap.org/Serving_Data) Regards, -- Christopher Schmidt Web Developer ___ Discuss mailing list Discuss@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/discuss ___ Discuss mailing list Discuss@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/discuss
RE: [OSGeo-Discuss] 'lossless' JPEG2000
Christopher - Let me add the evidence that I have found that reducing the strip size in LZW-compressed GeoTIFFs has, not surprisingly, a VERY large effect on read performance - about a factor of 10 in the particular cases I used. That indicates that the data you report might not be a good 'order of magnitude' measure of performance. I'm not talking about subtler effects of memory, caching, etc. but the substantial effect of changing the LZW strip size in a large image; the amount of work required to decompress a portion of that image is very, very different from the case in which the entire file is treated as one strip, due to the dictionary-building nature of the LZW algorithm. You're welcome to draw conclusions based on one data point; I am concerned that readers of your post may unreasonably extrapolate from them. You're welcome to stick to them, but I'm not sure I'd recommend that other users stick to them, at least in situations outside of your test environment. - Ed -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Christopher Schmidt Sent: Monday, February 25, 2008 9:18 PM To: discuss@lists.osgeo.org Subject: Re: [OSGeo-Discuss] 'lossless' JPEG2000 On Mon, Feb 25, 2008 at 09:04:59PM -0500, Ed McNierney wrote: Christopher - You will very likely find that using different LZW compression options (particularly setting a small strip size) will slightly degrade compression performance while significantly improving read time. While I think your test data are valid, they only address one of many possible configurations and I wouldn't necessarily make broad generalizations about LZW from them. However, I have generally found that LZW compression for photographic data is indeed not a good choice; I'm surprised you got it to perform as well as you did (in compression). Yeah, I think we've stumbled back and forth across these numbers before. I'm aware that they're essentially 'back of the envelope': they weren't run entirely in isolation, they were only repeated a couple of times (half dozen rather than an order of magnitude more), they might have been cached in memory, etc. etc. etc. However, they do seem to serve as a good 'order of magnitude' measure of size and performance for compressing aerial imagery based on other similar experiments, and I have no evidence to seriously discount them, so I'm sticking to them. Regards, -- Christopher Schmidt Web Developer ___ Discuss mailing list Discuss@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/discuss ___ Discuss mailing list Discuss@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/discuss
Re: [OSGeo-Discuss] Is there an Open Source software application that will draw a graticule on a map?
Brent - I'm not quite sure it suits your needs, but have you looked at the dlgv32 viewer the USGS distributes at http://mcmcweb.er.usgs.gov/drc/dlgv32pro/index.html ? I haven't used it in a while, but it does offer graticule overlay, large-format printing, and comes with a source distribution; I don't recall the details of the source license, and my memory may be a bit weak on the features. It's a Windows application and you can certainly download it and give it a shot. - Ed -- Ed McNierney Chief Mapmaker Demand Media / TopoZone.com 73 Princeton Street, Suite 305 North Chelmsford, MA 01863 Phone: (978) 251-4242 Fax: (978) 251-1396 [EMAIL PROTECTED] From: Brent Fraser [EMAIL PROTECTED] Reply-To: OSGeo Discussions discuss@lists.osgeo.org Date: Thu, 6 Sep 2007 15:36:26 -0600 To: OSGeo Discussions discuss@lists.osgeo.org Subject: [OSGeo-Discuss] Is there an Open Source software application that will draw a graticule on a map? Hi all, I've been looking for an Open Source desktop application that will: 1. Combine raster and vector spatial data, and (re)project them 2. Render a graticule (lines and labels showing latitude and longitude) (and no, I don't want to create a shapefile to do that) 3. Print to a large format plotter (paper 24 inches wide or greater) So far I've looked at uDig, Quantum GIS, and gvSig. As far as I can tell, none of them can do Step 2, and only gvSig does Step 3 successfully. Any pointers would be appreciated! Brent Fraser GeoAnalytic Inc. Calgary, Alberta ___ Discuss mailing list Discuss@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/discuss ___ Discuss mailing list Discuss@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/discuss
