Tue, Aug 7 2001
20:14:54
|
|
Request created by guest
|
|
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.
--
Tom Russo KM5VY QRPL #1592 K2#398 http://www.swcp.com/~russo/
Tijeras, NM DM64ux SOC #236 ICQ#97201722 http://www.qsl.net/~km5vy/
"Never put off until tomorrow what you can do today, because if you like it
today you can do it again tomorrow." |
|
Wed, Aug 8 2001
07:02:25
|
|
Comments added by egmiller
|
|
Not sure that r.in.gdal's behavior should change. I've looked at the
xxxxDDOM.DDF file which contains MIN, MAX and two unlabeled fields for "void"
areas and "fill" areas. Anyway, I don't know that r.in.gdal can easily make
a
distinction between these two types of "NULL" areas and it may be that someone
would want to retain those values (anyone??).
Anyway, the simple solution is to use r.null to change the selected values to
NULLS. You can examine the SDTS files with m.stds.read for any special
sentinel values. |
|
Wed, Aug 8 2001
14:37:42
|
|
Taken by fwarmerdam
|
|
Wed, Aug 8 2001
14:39:50
|
|
Comments added by fwarmerdam
|
|
The distinction between null and fill values for SDTS may be a bit of a
problem, but GDAL is picking one of these as the GDAL null value, and
r.in.gdal should utilize that. The other value may need to be handled
manually by the user as suggested.
It isn't my intention to implement proper null support for GRASS 5.0, but
I would like to do it once this has been finalized. This is as much a
feature improvement as a bug fix.
|
|
Wed, Aug 8 2001
23:11:41
|
|
Status changed to resolved by fwarmerdam
|
|
Wed, Aug 8 2001
23:12:48
|
|
Comments added by fwarmerdam
|
|
Updated r.in.gdal (and html docs) to support nulls if they can
be identified via the GDALRasterGetNoDataValue() call.
Seems to work fine for SDTS now.
|
|