[GRASS5] nviz-rwatershed-references

GRASS GRASS developer
1

I am back from the GIScience2000 and here are my answers/comments:

{s.surf.rst} problem is in output of references (Helena ?):
              -> should have extra flag
{r.resamp.rst} problem is in output of references (Helena ?):
             -> should have extra flag
{v.surf.rst} problem is in output of references (Helena ?):
             -> should have extra flag
{r.flow} problem is in output of references (Helena ?):
               -> should have extra flag

I will look at it - check also NVIZ because -help and -q does not
work there and it has the references too.

applied with the opengl function glNormal found in gsd_prim.c. I suspect
that there is a problem with how the normal vectors are calculated and
normalized. With a large Z range the normal XY values span -1 to 1, and
the normal Z values span 0 -1. With lat / long data and data with a low
Z range, the normal Z (temp[Z]) component is not normalized to the 0-1
range but rather a small component of it.

You are right that there is a problem with normals for surfaces with values
<0-1>- I have already reported it, it seems that it is also causing parts of
the surface to disapear for larger values of z for higher resolution/higher
zscale case. Bill fixed it for the SGI-GL version - if the GL version
is available it would be good to compare them. I will check with Bill,
but I would like him to finish the legends first.

Update of /grassrepository/grass/src/raster/r.flow
In directory intevation.de:/tmp/cvs-serv3114
Modified Files:
       calc.13.c
Log Message:
Floating point exception fixed.
let zero be 0.000001 right before dividing by this value.

This is not based on hydrologic knowledge.
Any idea?

this has nothing to do with hydrology, the algorithm is purely
geometrical - drawing lines in the direction of surface gradient.
As far as I remember this just shifts the flowline a small distance from the
grid point to avoid its passing through it and then have to
deal with many special cases. However, this may be introducing some
noise into the output map. If you don't like it, use the program
based on the original algorithm which takes care of all the special
cases - r.flowmd.

for all: I have found that r.watershed supports CELL only. It seems
to be a big task to update it to FP due to the code structure.
Do you consider r.watershed to
be reliable or to you use another watershed algorithm?
As r.watershed is quite old and not yet updated to FP,
we might replace it.

r.watershed is a pretty good program in spite of the fact that it is
slow and uses D8 algorithm. I use it occasionally, but we have also used
ARCINFO tools for watershed analysis. I would keep r.watershed
in the release. If it would be easy to find
a better program and implement it with less effort than it would
require to update r.watershed that may be a better solution.
Even then, I would still keep the un-updated r.watershed in GRASS.
I met Chuck who has written the program at GIScience2000 - I will
send him an email to see whether he could help with the FP update.
He plans to use GRASS5. I will also write to Laura from Duke -
David Finlayson writes that she was quite enthusiastic about
working with them and GRASS, however I need to read her paper in
more detail to see whether her program does all what is in r.watershed.

Helena

P.S. If you are interested, you can check out some new
GRASSonLINUX-made movies at
http://www2.gis.uiuc.edu:2280/modviz/gisc00/duality.html

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

2

On Wed, Nov 01, 2000 at 04:01:14PM -0600, Helena Mitasova - staff wrote:

I am back from the GIScience2000 and here are my answers/comments:

>{s.surf.rst} problem is in output of references (Helena ?):
> -> should have extra flag
>{r.resamp.rst} problem is in output of references (Helena ?):
> -> should have extra flag
>{v.surf.rst} problem is in output of references (Helena ?):
> -> should have extra flag
>{r.flow} problem is in output of references (Helena ?):
> -> should have extra flag

I will look at it - check also NVIZ because -help and -q does not
work there and it has the references too.

Helena,

if possible, please switch to the CVS version. The NVIZ is already
fixed (entire new and improved startup script from Bob Covill)
which you can download from the CVS server. The help is implemented
now.

>applied with the opengl function glNormal found in gsd_prim.c. I suspect
>that there is a problem with how the normal vectors are calculated and
>normalized. With a large Z range the normal XY values span -1 to 1, and
>the normal Z values span 0 -1. With lat / long data and data with a low
>Z range, the normal Z (temp[Z]) component is not normalized to the 0-1
>range but rather a small component of it.

You are right that there is a problem with normals for surfaces with values
<0-1>- I have already reported it, it seems that it is also causing parts of
the surface to disapear for larger values of z for higher resolution/higher
zscale case. Bill fixed it for the SGI-GL version - if the GL version
is available it would be good to compare them. I will check with Bill,
but I would like him to finish the legends first.

Perhaps you could send the file(s) for comparison. Then Bob might fix
it himself. The legends are very important, too!

>Update of /grassrepository/grass/src/raster/r.flow
>In directory intevation.de:/tmp/cvs-serv3114
>Modified Files:
> calc.13.c
>Log Message:
>Floating point exception fixed.
>let zero be 0.000001 right before dividing by this value.
>
>This is not based on hydrologic knowledge.
>Any idea?

this has nothing to do with hydrology, the algorithm is purely
geometrical - drawing lines in the direction of surface gradient.
As far as I remember this just shifts the flowline a small distance from the
grid point to avoid its passing through it and then have to
deal with many special cases. However, this may be introducing some
noise into the output map. If you don't like it, use the program
based on the original algorithm which takes care of all the special
cases - r.flowmd.

Do you think this change should be reverted? But a floating point exception
is somewhat severe and would confuse users.

>for all: I have found that r.watershed supports CELL only. It seems
>to be a big task to update it to FP due to the code structure.
>Do you consider r.watershed to
>be reliable or to you use another watershed algorithm?
>As r.watershed is quite old and not yet updated to FP,
>we might replace it.

r.watershed is a pretty good program in spite of the fact that it is
slow and uses D8 algorithm. I use it occasionally, but we have also used
ARCINFO tools for watershed analysis. I would keep r.watershed
in the release. If it would be easy to find
a better program and implement it with less effort than it would
require to update r.watershed that may be a better solution.
Even then, I would still keep the un-updated r.watershed in GRASS.
I met Chuck who has written the program at GIScience2000 - I will
send him an email to see whether he could help with the FP update.
He plans to use GRASS5. I will also write to Laura from Duke -
David Finlayson writes that she was quite enthusiastic about
working with them and GRASS, however I need to read her paper in
more detail to see whether her program does all what is in r.watershed.

This sounds very good. I would be glad to welcome more GRASS programmers
as the workload (according to plenty of ideas for GRASS) is quite
high.

Helena

P.S. If you are interested, you can check out some new
GRASSonLINUX-made movies at
http://www2.gis.uiuc.edu:2280/modviz/gisc00/duality.html

Thanks for the URL - your paper is looking exciting!

Markus

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'