negative nodata value loaded as positive in gdal 1.4.0

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

negative nodata value loaded as positive in gdal 1.4.0

Hernán De Angelis-2
Dear all,

I am having a weird problem when importing SRTM data using gdal_translate or
r.in.srtm in GRASS (which also uses gdal_translate): nodata values are loaded
as 32768 (positive) even when -32768 is explicitly set in the script. After
import gdalinfo reports nodata as -32768, but r.info (in GRASS), cmm (in
OSSIM) and OpeneEV all report these cells as 32768 (positive). I am using
gdal 1.4.0. Is anyone else having this problem as well?

Thanks

Hernán
 

--
Hernán De Angelis
Linux user # 397217

_______________________________________________
Gdal-dev mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: negative nodata value loaded as positive in gdal 1.4.0

Maciej Sieczka - old
Hernán De Angelis wrote:

> I am having a weird problem when importing SRTM data using gdal_translate or
> r.in.srtm in GRASS (which also uses gdal_translate)

FWIW, this is not correct. r.in.srtm is a script which uses r.in.gdal,
not gdal_translate.

However, both r.in.gdal and gdal_translate have the problem Hernán
describes, so propapably this is an issue with GDAL itself; unless an
issue with some problematic SRTM tiles, ?. I'm not up to tracing it
down exactly, but anybody who can please read below.

> nodata values are loaded
> as 32768 (positive) even when -32768 is explicitly set in the script. After
> import gdalinfo reports nodata as -32768, but r.info (in GRASS), cmm (in
> OSSIM) and OpeneEV all report these cells as 32768 (positive). I am using
> gdal 1.4.0. Is anyone else having this problem as well?

I confirm. I can reproduce this with some 3" tiles, eg:
ftp://e0srp01u.ecs.nasa.gov/srtm/version2/SRTM3/Eurasia/N49E023.hgt.zip

I checked whether this is related to the SRTM version - it's not; same
problem with the version 1 at:
ftp://e0srp01u.ecs.nasa.gov/srtm/version1/Eurasia/N49E023.hgt.zip

After importing the tile into GRASS with r.in.srtm (ie. r.in.gdal), the
max value of the output raster is 32768 - wrong. Should be circa 1200.
Min is OK - 153.

I have also checked with gdal_translate, and the same issue remains.
The value range is reported as 153-32768, see:

$ gdalinfo N49E023.bil -mm
Driver: EHdr/ESRI .hdr Labelled
Size is 1201, 1201
Coordinate System is `'
Origin = (22.999583333333334,50.000416666666666)
Pixel Size = (0.000833333333333,-0.000833333333333)
Corner Coordinates:
Upper Left  (  22.9995833,  50.0004167)
Lower Left  (  22.9995833,  48.9995833)
Upper Right (  24.0004167,  50.0004167)
Lower Right (  24.0004167,  48.9995833)
Center      (  23.5000000,  49.5000000)
Band 1 Block=1201x1 Type=UInt16, ColorInterp=Undefined
    Computed Min/Max=153.000,32768.000
  NoData Value=-32768

I have put the problematic SRTM V2 tile N49E023 (converted into
bil+hdr) for download here:

http://kufaya.googlepages.com/srtm_v2_N49E023_bil_hdr.tar.bz2

Using GDAL 1.4 CVS 2007-01-14 (today).

Maciek
_______________________________________________
Gdal-dev mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: negative nodata value loaded as positive in gdal 1.4.0

Hernán De Angelis-2
Maciek,

> FWIW, this is not correct. r.in.srtm is a script which uses r.in.gdal,
> not gdal_translate.
Thanks for responding and thanks for pointing out this mistake.

Today I tried a large number of SRTM tiles, including 1" and 3" as well as  
versions 1 and 2 and the problem is still present, so I also came to the
conclusion that it is likely a bug in GDAL. I hope some one else can comfirm
this.

Thanks

Hernán


> However, both r.in.gdal and gdal_translate have the problem Hernán
> describes, so propapably this is an issue with GDAL itself; unless an
> issue with some problematic SRTM tiles, ?. I'm not up to tracing it
> down exactly, but anybody who can please read below.

> > nodata values are loaded
> > as 32768 (positive) even when -32768 is explicitly set in the script.
> > After import gdalinfo reports nodata as -32768, but r.info (in GRASS),
> > cmm (in OSSIM) and OpeneEV all report these cells as 32768 (positive). I
> > am using gdal 1.4.0. Is anyone else having this problem as well?
>
> I confirm. I can reproduce this with some 3" tiles, eg:
> ftp://e0srp01u.ecs.nasa.gov/srtm/version2/SRTM3/Eurasia/N49E023.hgt.zip
>
> I checked whether this is related to the SRTM version - it's not; same
> problem with the version 1 at:
> ftp://e0srp01u.ecs.nasa.gov/srtm/version1/Eurasia/N49E023.hgt.zip
>
> After importing the tile into GRASS with r.in.srtm (ie. r.in.gdal), the
> max value of the output raster is 32768 - wrong. Should be circa 1200.
> Min is OK - 153.
>
> I have also checked with gdal_translate, and the same issue remains.
> The value range is reported as 153-32768, see:
>
> $ gdalinfo N49E023.bil -mm
> Driver: EHdr/ESRI .hdr Labelled
> Size is 1201, 1201
> Coordinate System is `'
> Origin = (22.999583333333334,50.000416666666666)
> Pixel Size = (0.000833333333333,-0.000833333333333)
> Corner Coordinates:
> Upper Left  (  22.9995833,  50.0004167)
> Lower Left  (  22.9995833,  48.9995833)
> Upper Right (  24.0004167,  50.0004167)
> Lower Right (  24.0004167,  48.9995833)
> Center      (  23.5000000,  49.5000000)
> Band 1 Block=1201x1 Type=UInt16, ColorInterp=Undefined
>     Computed Min/Max=153.000,32768.000
>   NoData Value=-32768
>
> I have put the problematic SRTM V2 tile N49E023 (converted into
> bil+hdr) for download here:
>
> http://kufaya.googlepages.com/srtm_v2_N49E023_bil_hdr.tar.bz2
>
> Using GDAL 1.4 CVS 2007-01-14 (today).
>
> Maciek

--
Hernán De Angelis
Linux user # 397217

_______________________________________________
Gdal-dev mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: negative nodata value loaded as positive in gdal 1.4.0

Maciej Sieczka - old
Hernán De Angelis wrote:

> Today I tried a large number of SRTM tiles, including 1" and 3" as well as  
> versions 1 and 2 and the problem is still present, so I also came to the
> conclusion that it is likely a bug in GDAL. I hope some one else can comfirm
> this.

Hi,

I think I have found the reason and solution.

GDAL requires explicitely set "PIXELTYPE SIGNEDINT" in the hdr file to
treat the EHdr as a singed integer.

r.in.srtm follows the guideline at [1] which doesn't mention this keyword.

After adding the "PIXELTYPE SIGNEDINT" into the hdr created by
r.in.srtm GDAL recognizes the value range properly. See:

without "PIXELTYPE SIGNEDINT" - bad:

$ gdalinfo tmp/srtm_v1_N51E016/N51E016.hgt -mm
Driver: EHdr/ESRI .hdr Labelled

<snip>

Band 1 Block=1201x1 Type=UInt16, ColorInterp=Undefined
    Computed Min/Max=37.000,32768.000
  NoData Value=-32768



with "PIXELTYPE SIGNEDINT" - good:

gdalinfo tmp/srtm_v1_N51E016/N51E016.hgt -mm
Driver: EHdr/ESRI .hdr Labelled

<snip>

Band 1 Block=1201x1 Type=Int16, ColorInterp=Undefined
    Computed Min/Max=37.000,484.000
  NoData Value=-32768


Markus,

Should I apply this fix?

Frank,

GDAL-created hdr files don't include the BANDGAPBYTES parameter
mentioned in [1]. Is that OK?

Maciek

[1]
ftp://e0srp01u.ecs.nasa.gov/srtm/version1/Documentation/Notes_for_ARCInfo_users.txt
_______________________________________________
Gdal-dev mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: negative nodata value loaded as positive in gdal 1.4.0

Maciej Sieczka - old
Maciej Sieczka wrote:

> Hernán De Angelis wrote:
>
>> Today I tried a large number of SRTM tiles, including 1" and 3" as well as  
>> versions 1 and 2 and the problem is still present, so I also came to the
>> conclusion that it is likely a bug in GDAL. I hope some one else can comfirm
>> this.
>
> Hi,
>
> I think I have found the reason and solution.
>
> GDAL requires explicitely set "PIXELTYPE SIGNEDINT" in the hdr file to
> treat the EHdr as a singed integer.

Hi,

After sorting this out with Frank and Markus offlist, r.in.srtm has
been fixed accordingly in CVS.

Maciek
_______________________________________________
Gdal-dev mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/gdal-dev