[Gdal-dev] processing SRTM-3?
Thom DeCarlo
t.r.decarlo at LARC.NASA.GOV
Wed Jul 28 15:40:20 EDT 2004
I wrote:
>
> Frank Warmerdam wrote:
> >
> > Thom DeCarlo wrote:
> > > Oops, found another... issue. The SRTM documentation states that the
> > > NODATA value is -32768 and the shell script accommodates that by
> > > setting the appropriate value in the header file. However, it appears
> > > that the rest of the gdal software assumes that the NODATA value is
> > > -9999. Is there any way to tell the gdal_translate program to change
> > > any NODATA values it encounters to be -9999?
> >
> > Thom,
> >
> > The GDAL libraries should not assume a nodata value of -9999. The data
> is
> > being imported via the ESRI BIL format, right? What does the .hdr file
> > have for a NODATA value? What does gdalinfo report about a dataset?
> >
> > Best regards,
> > --
>
> Unfortunately, I need to use geotiff format for the output terrain data
> and
> I don't think geotiff has a defined NODATA value. One use of this terrain
> is
> to feed a couple different 3D model builders and construct terrain models.
> It seems that some of these tools fall back to a default NODATA value of
> -9999 for datasets that do not define their own value. That causes
> incorrect
> interpretation of the -32768 value in the geotiff files as being valid
> data.
>
ACK! I should have checked this first. (I was working from old, outdated,
memories.) running gdalinfo on the geotiff files shows that there *is* a
NODATA value of -32768 in there. I'd better check the other applications to
make sure that they are handling this properly and not just assuming that
the NODATA value is -9999.
Sorry,
Thom
More information about the Gdal-dev
mailing list