[GRASS5] [bug #784] (grass) r.in.gdal doesn't handle NULL values properly.

[Eric G. Miller]

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 at jps.net>