Details Ticket 784


Comment | Reply | Open


Serial Number 784
Subject r.in.gdal doesn't handle NULL values properly.
Area bug
Queue grass
Requestors warmerdam@pobox.com
Owner fwarmerdam
Status resolved
Last User Contact Never contacted
Current Priority 30
Final Priority 70
Due No date assigned
Last Action Wed Aug 8 23:12:48 2001 (7 yr ago)
Created Tue Aug 7 20:14:54 2001 (7 yr ago)

Transaction History Ticket 784


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.
Comment | Reply | Open

You are currently authenticated as guest.
[Show Configuration] [Login as another user]

Users Guide - Mail Commands - Homepage of RequestTracker 1.0.7 - list any request