On Tue, Aug 07, 2001 at 08:14:54PM +0200, Request Tracker wrote:
this bug's URL: http://intevation.de/rt/webrt?serial_num=784
-------------------------------------------------------------------------Subject: r.in.gdal doesn't handle NULL values properly.
Summary: r.in.gdal doesn't handle NULL values properly.
GDAL can't report on NULL values used in some datasets, including
SDTS dems, and this should be used by r.in.gdal to set up proper
handling of null values.Richard Shepard writes:
> I imported a USGS 24K DEM into GRASS5 using r.in.gdal. [...]
> all I see is a red rectangle[...]I had the same problem. There is apparently a problem with those DEMs where
the null values are set to huge negative numbers, screwing up the choice of
color map.If you look at the GRASS FAQ web site there's a (somewhat outdated)
description of how to import USGS DEMs in SDTS format. In there they describe
a procedure where you have to use sed to strip out the strange large negative
numbers. In that procedure you use sdts2ascii to convert the stds file to
something GRASS can read (roughly) then edit it by hand and with sed to
massage it into something GRASS can read (actually).As I recall, when I used r.in.gdal to do exactly what you're doing, I followed
the r.in.gdal run with r.out.ascii, then used a sed script to replace the
things like -32768 with 0. If you dump out your raster file with r.out.ascii
and look at it for a few seconds it should be pretty obvious what to do to get
it fixed up.Once you get the strange large negatives out and re-import the DEM, the
colormap looks sane.Now, there may well be a way to specify how the nulls are handled by r.in.gdal
or to process the raster file within GRASS, but I haven't figured it out yet.
Since I've already imported most of the DEMs I needed to work with and this
procedure works well enough for the odd ones I may have to import from time to
time, I have pretty much stopped trying to figure it out.
It's possible that the gdal library could do something different since
these sentinel values are discoverable via the xxxxDDOM.DDF file. I'm
not sure that gdal should exhibit different behavior though (might be
someone wants those values). You can view the various SDTS files as
text with m.stds.read. Anyway, there is a distinction in the DEM
between real NODATA cells and edge fill cells (used for rectangularity).
Should gdal treat anything outside the defined MIN/MAX as NULL? I don't
know...
BTW: Probably much easier to change those sentinel values via r.null
or r.mapcalc. Then just update the colormap...
P.S.: Request Tracker needs it's address updated too.
--
Eric G. Miller <egm2@jps.net>