[GRASS5] [bug #4070] (grass) r.in.srtm fails to assign null() to nodata properly - propably a GDAL bug

[Request Tracker]

this bug's URL: http://intevation.de/rt/webrt?serial_num=4070
-------------------------------------------------------------------------

Subject: r.in.srtm fails to assign null() to nodata properly - propably a GDAL bug

Platform: GNU/Linux/x86
grass obtained from: Trento Italy site
grass binary for platform: Compiled from Sources
GRASS Version: CVS 2006.02.07

NOTE: this doesn't happen with all SRTM 3' tiles. But e.g. this one is affected. I'm pretty sure it's not a problem of the tile itself - only r.in.srtm fails (due to r.in.gdal failure), however r.in.bin handles it fine. Please read below.

# Download ftp://e0srp01u.ecs.nasa.gov/srtm/version1/Eurasia/N51E016.hgt.zip

# Import it in a WGS84 ll location (first you might need to add "-o" switch
# to r.in.gdal command in r.in.srtm script, as there is some error preventing
# GDAL from recognizing Grass location settings anymore).

$ r.in.srtm input=N51E016 output=N51E016_v1
Extracting N51E016...
Archive:  N51E016.hgt.zip
  inflating: N51E016.hgt
Converting input file to BIL...
Over-riding projection check.
Proceeding with import...
 100%
CREATING SUPPORT FILES FOR N51E016_v1
SETTING GREY COLOR TABLE FOR N51E016_v1 (16bit, image range)
r.in.gdal complete.
WARNING: Your color rules do not cover the whole range of data!

							^
							|
						  # NOTE THIS!!!


Color table for [N51E016_v1] set to srtm
Done: generated map N51E016_v1
(Note: Holes in the data can be closed with 'r.fillnulls' using splines)




# Indeed, the max value is wrong:

$ r.info -r N51E016_v1
min=55
max=32768




# The problem is somwhere in the GDAL - the intermediate .bil file that
# r.in.srtm creates, has wrong value range reported by gdalinfo:

$ gdalinfo -mm N51E016.bil
Driver: EHdr/ESRI .hdr Labelled
Size is 1201, 1201
Coordinate System is:
GEOGCS["wgs84",
    DATUM["WGS_1984",
        SPHEROID["wgs84",6378137,298.257223563],
        TOWGS84[0.000000,0.000000,0.000000]],
    PRIMEM["Greenwich",0],
    UNIT["degree",0.0174532925199433]]
Origin = (15.999583,52.000417)
Pixel Size = (0.00083333,-0.00083333)
Corner Coordinates:
Upper Left  (  15.9995833,  52.0004167) ( 15d59'58.50"E, 52d 0'1.50"N)
Lower Left  (  15.9995833,  50.9995833) ( 15d59'58.50"E, 50d59'58.50"N)
Upper Right (  17.0004167,  52.0004167) ( 17d 0'1.50"E, 52d 0'1.50"N)
Lower Right (  17.0004167,  50.9995833) ( 17d 0'1.50"E, 50d59'58.50"N)
Center      (  16.5000000,  51.5000000) ( 16d30'0.00"E, 51d30'0.00"N)
Band 1 Block=1201x1 Type=UInt16, ColorInterp=Undefined
    Computed Min/Max=55.000,32768.000
  NoData Value=-32768
				^
				|
			  # WRONG !!!



# But - importing the same N51E016.bil with r.in.bin in XY location works like
# a charm, thus proves the problem is somewhere in GDAL:

$ r.in.bin input=/home/john/tmp/srtm_v1/N51E016.bil output=N51E016_v1_rinbin bytes=2 rows=1201 cols=1201 -b
Byte Swapping Turned On!
Using N=1201.000000 S=0.000000 E=1201.000000 W=0.000000
Percent Complete:  100%
CREATING SUPPORT FILES FOR N51E016_v1_rinbin



# See how CORRECT min/max differs now from the r.in.gdal output:

$ r.info -r N51E016_v1_rinbin
min=-32768
max=483



# And here's what it should be after setting -32768 to null:

$ r.null map=N51E016_v1_rinbin setnull=-32768
Writing new data for [N51E016_v1_rinbin]...  100%

$ r.info -r N51E016_v1_rinbin
min=55
max=483



Maciek

-------------------------------------------- Managed by Request Tracker