[GRASS5] nviz-rwatershed-references

Markus Neteler neteler at geog.uni-hannover.de
Thu Nov 2 03:55:01 EST 2000


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



More information about the grass-dev mailing list