[GRASS5] 0 != no data

[Helena Mitasova]

Justin,

treating 0 as NULL by default for the maps which do not have a null file is a
historical issue
and was requested by overhelming majority of old GRASS users who used 0 for
NULL before
NULL was implemented.  I don't like it either but I lost - too many people
wanted it.
The import program which you have used to import your data should have
created the null file and allowed you to treat 0 as 0 and not NULL.
I would like to see this behavior changed, however the users have to be
consulted because
they may still prefer it.


Helena

Bob Covill wrote:

> Justin Hickey wrote:
> >
> > Hi all
> >
> > Recently we experienced a problem with using aerial photographs as
> > raster maps. The photographs are grayscale and thus range in value from
> > 0 to 255. Here 0 is a valid CELL value, however, Grass 5 treated it as a
> > "no data" value. So, displaying our maps, these white areas appeared
> > (where they should have been black) that were displayed as "(Null) no
> > data" in d.what.rast. Initially, we thought that the data had been
> > corrupted somehow, but it was only Grass interpreting 0 as "no data".
> >
> > For me, this is a show stopper for Grass5.0. Since Grass now has well
> > defined values for Null, 0 should never be considered as "no data". This
> > only leads to confusion to users who have no idea that in previous grass
> > versions, 0 was associated with "no data". Like us, they will assume
> > that their files have been corrupted somehow.
> >
> > The fix for this was to run r.support and create a null file. This leads
> > me to another problem, namely, r.support has the option to consider 0 as
> > "no data". I think this option should be removed. Also, I don't see a
> > reason for having a null file. The value in the raster file should
> > indicate whether it is null or not. Thus, I think that the option to
> > r.support to set 0 as valid data by creating a null file, should also be
> > removed. Basically, Grass should simply read the raster file and if any
> > values are equal to our defined Null values they are Null, straight
> > forward and simple. Note that if some users have a reason for wanting 0
> > to be "no data" then they can simply use r.mapcalc to convert 0 to Null.
> >
> > Finally, d.what.rast currently reports the value 0 as "no data" even
> > after the null file is created. I think this needs to be changed as
> > well.
> >
> > Unfortunately, I have no idea how to fix this problem. The ideal
> > solution is to find the code that interprets 0 as "no data" and
> > eliminate it. However, I don't even know how to search for this type of
> > code. Does anyone have any ideas on how to solve this?
> >
> > Thanks for listening.
> >
> > --
> > Sincerely,
> >
> > Jazzman (a.k.a. Justin Hickey)  e-mail: jhickey at hpcc.nectec.or.th
> > High Performance Computing Center
> > National Electronics and Computer Technology Center (NECTEC)
> > Bangkok, Thailand
> > ==================================================================
> > People who think they know everything are very irritating to those
> > of us who do.  ---Anonymous
> >
> > Jazz and Trek Rule!!!
> > ==================================================================
>
> Justin,
>
> Zero should (hopefully) be imported as zero. I wonder if the problem is
> actually with the import program. What program did you use to import the
> images? Maybe as a test, try converting an image to another supported
> format (eg. TIFF, SunRaster) and re-importing to see how the zeroes are
> handled.
>
> Hope this helps.
>
> --
> Bob Covill
>
> Tekmap Consulting
> P.O. Box 2016 Fall River, N.S.
> B2T 1K6
> Canada
>
> E-Mail: bcovill at tekmap.ns.ca
> Phone: 902-860-1496
> Fax: 902-860-1498
> _______________________________________________
> grass5 mailing list
> grass5 at geog.uni-hannover.de
> http://www.geog.uni-hannover.de/mailman/listinfo/grass5