[GRASS5] r.le in GRASS-5?

[William L. Baker]

Hi Markus and Eric,

Oops...I think Markus dug up the wrong old
message.  That NaN stuff was cleared up for me
some time ago.  The remaining problem has to do
with the monitor getting hung when a particular
function is used.  I can't get to it right now,
but will re-send the message about the problem
when I return from fieldwork at the end of July.

Thanks for your interest and concern to help
solve r.le bugs...

Bill Baker

-----Original Message-----
From: grass5-admin at geog.uni-hannover.de
[mailto:grass5-admin at geog.uni-hannover.de]On Behalf Of Eric G. Miller
Sent: Thursday, July 05, 2001 7:15 PM
To: grass developpers
Subject: Re: [GRASS5] r.le in GRASS-5?


On Thu, Jul 05, 2001 at 05:20:35PM +0000, Michel Wurtz wrote:
> Markus Neteler wrote:
> >
> > On Wed, Jul 04, 2001 at 10:39:50AM -0600, William L. Baker wrote:
> > > Hello Rich and others,
> > >
> > > I am indeed working on a version of r.le for
> > > GRASS 5.  I have a version of r.le.patch and
> > > r.le.pixel that seem to run fine.  The only
> > > serious remaining bug is in r.le.setup.  I wrote
> > > to the programmer's list about this one a couple
> > > of months ago, but no-one had a solution.  Until
> > > I can solve this one, r.le.setup is unusable.
> >
> > Here is the old mail (I think so):
> >
http://www.geog.uni-hannover.de/mailinglisten/grass5/archive/2000/12/17/7
> >
http://www.geog.uni-hannover.de/mailinglisten/grass5/archive/2000/12/18/1
>
> And one more time, it's a null file related problem... It seems that a
> good null values management is becomming an urgent need.
> BTW, nobody commented my last proposal, which either means that everybody
> agrees or that I'm way off out out of topic ;-)

Frankly, the only problem I really see with the current NULL file
management is that for old maps, the user has to be concerned about
whether 0 == NULL or not.  "r.null" fixes up that problem.

I still don't understand what it is that William Baker needs that
isn't already provided.  There are functions that ascertain whether
any given cell is "NULL".  How would it be different using NaN? You
still have to use IS_NAN() or some such.  If using the newer interfaces,
all new files are created with a clear separation of NULL and 0.
There are functions for specifying that a cell should be NULL.  You can
get the flag array for NULL values for any given row if you need it.  If
you want to use some temp file with your own variant of NULL for easier
comparison, go for it.

I certainly don't think it gets any simpler if you move the
handling of the NULL representation to outside of libgis,
or if the values are embedded.  Your modules still have to be prepared
to handle NULL, and NULL could be anything, so use G_is_null_value().

I don't see anything particularly wrong with wanting to embed NULL
values, but I certainly don't feel like diving into that raster code
again.  It isn't broken.  Lots of other things are.  Is GRASS 5.0 ever
going to get released?  Leave it for 5.1.  It's just too dangerous to be
mucking in that territory if GRASS 5.0 is ever going to be released
before the next millenium.

--
Eric G. Miller <egm2 at jps.net>
_______________________________________________
grass5 mailing list
grass5 at geog.uni-hannover.de
http://www.geog.uni-hannover.de/mailman/listinfo/grass5