[Gdal-dev] GTOPO30 problem

Clay, Bruce bclay at ball.com
Thu May 6 16:04:50 EDT 2004


Frank:
  Thanks for the update.  After nearly a week of debugging and pulling
my hair out (what little is left that is), I think I found the problem.
It appears to be in the least likely of all places, Winzip.  All of the
GTOPO30 files are tarred and gzipped.  I have been using Winzip to
unpack the files and that appears to be the mistake.  MicroDem has the
ability to uncompress and untar files.  When I used MicroDem to unpack
the files I get the correct min and max values as defined in the GTOPO30
document (at least for the file in question).  As a sanity check I went
back to Winzip and checked the files out of the same compressed data
file the run the latest gdalinfo I get
   "Computed Min/Max=-32768.000,32767.000"

I can't explain why this is the case just that it certainly appears to
be.  I would be real happy to have independent confirmation from anyone
that has the time to run the same test "gdalinfo -mm e020n90.dem" on a
dem file extracted with Winzip version 8.1 

Another interesting tidbit I just tried is a freeware program
(PowerArchiver 2001, v6.1) unpacks the data correctly such that the
results of the above test are "Computed Min/Max=-137.000,5483.000"

Thanks again for your help.

Bruce


-----Original Message-----
From: gdal-dev-admin at remotesensing.org
[mailto:gdal-dev-admin at remotesensing.org] On Behalf Of Frank Warmerdam
Sent: Thursday, May 06, 2004 11:42 AM
To: gdal-dev at remotesensing.org
Subject: Re: [Gdal-dev] GTOPO30 problem


Clay, Bruce wrote:
> Frank
>   the file in biggest question is E20N90.tar.gz from 
> edcftp.cr.usgs.gov/pub/data/gtopo30/global.  It looks like all of the 
> data sets are Motorola type.  The min and max values returned by GDAL 
> don't match the min and max values shown in the GTOPO30 documentation.

Bruce,

Gdalinfo was modified March 19th to compute and report exact min/max
values for -mm.  Before that it would request the min/max with
"approximate ok" set to TRUE.  This means that only a subset of the
image would be sampled to compute the min/max.

So, don't trust the min/max values of older gdalinfo's.  A new build
from CVS should give exact results.

Best regards,
-- 
---------------------------------------+--------------------------------
---------------------------------------+------
I set the clouds in motion - turn up   | Frank Warmerdam,
warmerdam at pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | Geospatial Programmer for Rent

_______________________________________________
Gdal-dev mailing list
Gdal-dev at remotesensing.org
http://remotesensing.org/mailman/listinfo/gdal-dev



More information about the Gdal-dev mailing list