A forward concerning the G3D modules and lib.
The changes described below are in CVS HEAD.
It may be a good idea to contact Alfonso directly for
questions (he is probably not on this list)
Markus
----------------------------------------------------------------
Subject: summary of grass r3.* modules
From: Alfonso Vitti <alfonso.vitti@ing.unitn.it>
To: Helena Mitasova <hmitaso@unity.ncsu.edu>
Cc: paolo.zatelli@ing.unitn.it, jhofier@unity.ncsu.edu, neteler@itc.it
In-Reply-To: <3D64DF9E.69211BDC@unity.ncsu.edu>
X-Mailer: Evolution/1.0.2-5mdk
Date: Tue, 17 Sep 2002 18:03:34 +0100 01:00:00 +0000 (GMT)
Hi everybody, here a summary on r3.* modules:
what I've done is:
r3.out.ascii now works, values are written in the right order and the
module even works on any region;
r3.out.v5d now works with rows!=cols and the output of vis5d is the same
of r3.showdspf;
s.vol.idw and s.vol.rst now have consistent output;
r3.null works properly and on any region;
g3.region gives the right warning if the current top value is greater
than the one of the default region;
r3.mapcalc "row()" gives the right number of the current row;
r3.mapcalc "y()" gives the right value of the current y coordinate.
In the attach you'll find the tar.gz of the files I changed, it is the
same I sent you on June.
I've packaged the modified files from the code directory of
"grass50_exp_2002_05_10".
You can easily find where I've modified the code: all my comments are
capitals and they begin with the string: /*AV*/, first you'll find the
original code commented and then mine.
So, now the first thing could/should be to have all the 3D for-loops
like 2D ones and to check the order of the functions parameters. About
the z for-loop the idea was to have it working from bottom to top. Then
the work could move to s.vol.rst and r3.mapcalc and so on...
s.vol.rst if I've understood correctly the current module doesn't work
properly so Jaro's written a version which doesn't use the
grass libraries (is it right?). After the work on the
libraries, if the problems will not disappear, we should
find what is wrong until the output of the two modules is
the same.
r3.mapcalc someone is re-writing r.mapcalc (sorry, I don't remember the
name) and could be a good idea to introduce the news in the
3D version. I don't now anything about the changing on
r.mapcalc; add the possibility to have absolute reference to
the cells and not only relative;
find out why the module crashes when the number of levels is
increased over a certain value;
add the possibility to use 2D maps
question/suggestion: could be an idea to have only one
r.mapcalc able to work with 2D and 3D rasters?
r3.showdspf.openGL some of its features don't work, if you change the
vertical resolution using g3.region and set it different by
x-y and then you re-run r3.mkdspf the visualization of
r3.showdspf is wrong, higher vertical resolution compacts
the vertical hight, compare to the x-y base, lower vertical
resolution (compared to x-y) increase the vertical hight; no
cross section, no re-defining volume walls, volume-rendering
not correct displayed, (or at least difficult to be
obtained) first isosurface is often not-displayed (yet, I
have not understood why...) you've suggested to check the
porting from r3.showdspf.sgi, which uses GL libraries (is it
right?)
g3.region no parser
time series I've talked with Paolo about that, could be an idea to
add to the header files a row containing the time
information? of course this is not a trivial issue but we
think that could be better to have a structured approach to
the problem, but I do know nothing about this issue, perhaps
some solution is already available.
directory-structure Markus told me to send an email to the developers
mailing list asking about it. What do you think about the
difference between the 2D and 3D? Do you know why who wrote
the r3.* modules and library had made this choice?
so, wow!
if I've forgot something and/or misunderstood something else please tell
me!
could you suggest me a priority-list? it can help me to organize my work
Alfonso
