[GRASS5] nviz-rwatershed-references

Helena Mitasova - staff helena at gis.uiuc.edu
Wed Nov 1 17:01:14 EST 2000


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 at geog.uni-hannover.de with
subject 'unsubscribe grass5'



More information about the grass-dev mailing list