Hi,
while working on the WCS limits I found an odd result
that I thought I'd pass on to the list.
Using this sample WCS 1.0 request
http://sigma.openplans.org/~aaime/wcsGetCoverage.xml
running against the sample data we have in the release
data directory I get this TIFF as an output:
http://sigma.openplans.org/~aaime/original.tiff
Now, the output looks good but the size is twice
as much as my WCS limits code predicted.
I run a gdalinfo on it getting this output:
Driver: GTiff/GeoTIFF
Files: original.tiff
Size is 545, 490
Coordinate System is `'
Metadata:
TIFFTAG_XRESOLUTION=1
TIFFTAG_YRESOLUTION=1
TIFFTAG_RESOLUTIONUNIT=1 (unitless)
Image Structure Metadata:
INTERLEAVE=BAND
Corner Coordinates:
Upper Left ( 0.0, 0.0)
Lower Left ( 0.0, 490.0)
Upper Right ( 545.0, 0.0)
Lower Right ( 545.0, 490.0)
Center ( 272.5, 245.0)
Band 1 Block=544x16 Type=Byte, ColorInterp=Gray
Now, one byte, 454x490 -> around 260k, but
the file is actually twice as big (there is no CRS
too, but that's because I asked for TIFF, not a geotiff...
yeah, it was a mistake but allowed to find out an
odd output)
Then I run gdal_translate on it, without params,
getting:
http://sigma.openplans.org/~aaime/transformed.tiff
The output from gdalinfo is almost perfectly equal
(almost, the block size is 544x15 after the translation)
but the file size magically halved.
The size discrepancy could be explained if the
original output was using short integers instead
of bytes, but I find it odd that gdalinfo insists
they are bytes instead.
Hummm... does anyone have a clue about what's
going on? And, is there anything we can do to make
GS output minimal size files?
Not that pure TIFF are much of interest in the WCS
case, but since we have them as an output option...
Cheers
Andrea
--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.