<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-15"
http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Hello Brad and Paolo,<br>
<br>
It's been a while since I looked at the code, but the MAX definition I
think is for the number of categories allowed in r.le.pixel, not for
the size the region. Unfortunately, we made a bad programming decision
long ago. We should have used a linked-list structure for categories
(which would have allowed any number of categories memory permits).
Instead, MAX is used to allocate a fixed amount of memory for the
categories structure. That worked fine when r.le.pixel and GRASS were
categorical, but with floating point, there are huge numbers of
categories possible. r.le.pixel will work on large regions (e.g.,
10,000 X 10,0000 pixels) if there are only limited categories. But, to
fix this to work really well for floating point will require
replacement of the structure and associated coding for categories, so
there is no fixed limit (MAX). <br>
<br>
However, one could simply tell the user that it would be best to use
r.le.pixel only with categorical data. It actually is of questionable
scientific value to use it with floating point data, at least if there
are large numbers of possible values. At one point I was going to add a
warning message if the user wanted to analyze a floating point map with
r.le.pixel--I think it is important that users understand that this
module is not really meant for maps with very large numbers of values
where the measures themselves would be of questionable value. I think
this warning message approach is actually the right solution for now.
But, in the long run, it would be nice to replace the structure with a
linked list.<br>
<br>
Paolo, I think there is some value to modularity, but in this case that
is not the problem. It is our poor programming a long time ago!<br>
<br>
Actually, I am not sure I understand why it really matters whether
things are modular or not at the scale of individual measures? I think
the one thing that could be said about r.le is that it is a bit old and
the programming was not so great, so now we have to put some patches on
the holes, rather than make something new that is better written. This
case of MAX is a good example. <br>
<br>
The chief advantage r.le had over FRAGSTATS and other programs not part
of a GIS was r.le.setup, which allowed a diversity of sampling
approaches, the moving window option (now FRAGSTATS has that), and
integration within GRASS where output maps can be analyzed by other GIS
programs. But, I still have not had the time to look at r.li! <br>
<br>
Bill <br>
<br>
Paolo Cavallini wrote:<br>
<blockquote cite="mid451E0ECF.5090405@faunalia.it" type="cite">
<pre wrap="">-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
that's one of the reasons that promptet our investment in r.li. I
seriusly think your expertise and time will produce faster and better
output if you concentrate on r.li. Please note that r.li is fully
functional (it just does not have many modules implemented, but due to
its modularity this should be easy and fast to do).
Or there is a point I'm missing?
All the best.
pc
Brad Douglas ha scritto:
</pre>
<blockquote type="cite">
<pre wrap="">I got everything working last night, but there is one large issue: I
believe the modules needs segmentation. The largest region I have been
able to work with is about 150x150 with MAX defined as 100000. There is
no checking against MAX, so if you run out of allocated memory, it will
segv().
</pre>
</blockquote>
<pre wrap=""><!---->
- --
Paolo Cavallini
email+jabber: <a class="moz-txt-link-abbreviated" href="mailto:cavallini@faunalia.it">cavallini@faunalia.it</a>
<a class="moz-txt-link-abbreviated" href="http://www.faunalia.it">www.faunalia.it</a>
Piazza Garibaldi 5 - 56025 Pontedera (PI), Italy Tel: (+39)348-3801953
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Using GnuPG with Mozilla - <a class="moz-txt-link-freetext" href="http://enigmail.mozdev.org">http://enigmail.mozdev.org</a>
iD8DBQFFHg7P/NedwLUzIr4RAk98AJ4kPHVP0AzP3TOLgiIlOKy49uAUNwCfVU2E
cR9ICPz3s6EwLl+idUfgiiE=
=4mDL
-----END PGP SIGNATURE-----
</pre>
</blockquote>
</body>
</html>