[FWTools] Compressing geoid model?

[Charles Karney]

For egm2008-5.pgm...

Other lossless image compression schemes:

   pamtotiff -flate saves 7.5%
   pnmtopng -compress 9 saves 10%

Other general compression schemes:

   gzip -9 saves 10%
   zip saves 10%
   bzip2 -9 saves 44%
   inno setup + lzma/ultra64 saves 42%

Incidentally the 1" grid file egm2008-1 generally compresses better
(because the data is smoother).  In particular lzma/ultra64 reduces it
size by 74%.

The pgm format is of course wonderful in that it permits random access.
This is potentially important for the 1" grid data (which is about
0.5GB).  (And for GeographicLib, I wanted also to avoid a dependency on
a tiff library.)


On 06/07/11 09:36, Mikael Rittri wrote:
> Hello,
>
> I have been trying to compress the geoid heights of EGM 2008,
> starting from the 5 arc minute resolution that is available
> via GeographicLib, http://geographiclib.sourceforge.net/html/geoid.html
>
> I thought tif would be a nicer format than the pgm format provided by
> GeographicLib, and I hoped that tif compression would help.
>
> However, I have tried these commands:
>
>     gdal_translate -ot UInt16 -co "COMPRESS=NONE" egm2008-5.pgm egm2008-5-uint16-nocompression.tif
>
>     gdal_translate -ot UInt16 -co "COMPRESS=LZW" egm2008-5.pgm egm2008-5-uint16-lzw.tif
>
>     gdal_translate -ot UInt16 -co "COMPRESS=PACKBITS" egm2008-5.pgm egm2008-5-uint16-packbits.tif
>
> and got the following sizes of the tif files:
>
>     egm2008-5-uint16-nocompression.tif	18252 KB
>     egm2008-5-uint16-packbits.tif		18377 KB
>     egm2008-5-uint16-lzw.tif			23659 KB
>
> where the original file was
>
>     egm2008-5.pgm					18235 KB
>
> So, PACKBITS makes the result 0.7 percent larger than NONE,
> which is perhaps not a surprise, since run-length encoding
> should not be suitable for this kind of data.
> However, LZW makes the result 29.6 percent larger than NONE,
> which surprised me.  I would have thought the the geoid data
> should be fairly easy to compress (although I know almost
> nothing about how LZW works).
>
> Am I missing something obvious? Is there some other
> (GDAL-readable) compressed format that would be better
> for this kind of data?