Helena, Your results seem very interesting and very encouraging. I did not expect such a wide aplications...
-r flag removes lines which are shorter (after simplifiaction) than threshold. In your situations, it is very likely that the individual streams consist of many short segments/lines. Daniel On 8/17/07, Helena Mitasova <[EMAIL PROTECTED]> wrote: > As I have mentioned I hoped that generalization will help > to solve some problems when interpolating by v.surf.rst from > oversampled contours > (as is the case for example when they are scanned) > and the results were well beyond my expectations > (at least for the small data set I used). > > First some test: > Even with very small threshold, large number of points is eliminated > without noticeable change in the contour geometry > http://skagit.meas.ncsu.edu/~helena/grasswork/elcont1m_gen00.png > (from 40,000 to 3,000 points) > result with threshold 5 is more radical > http://skagit.meas.ncsu.edu/~helena/grasswork/elcont1m_gen05.png > (from 40,000 to 500 points) > each line is generalized independently so eventually contours will > cross, so small threshold > is what we want to use (animation from threshold of 0.5 to 12) > http://skagit.meas.ncsu.edu/~helena/grasswork/gencontanim2.gif > > Interpolation from given data (40,000 pts) using default parameters > (note that the points along contours are practically continuous, > there are visible segments > on the top of the hill and the computation runs 8 min) > http://skagit.meas.ncsu.edu/~helena/grasswork/rstint_default_pts.png > There are many small segments and the data are not very well > distributed within the segments > http://skagit.meas.ncsu.edu/~helena/grasswork/rstint_default_seg.png > > we can improve the results by tuning dmin, npmin, tension and > smoothing as we have done for years, > but there is a better solution now, by running v.generalize first , > with small threshold we have fewer than 3000 points : > http://skagit.meas.ncsu.edu/~helena/grasswork/rstint_gen_pts.png > Segments are larger and fewer - computation runs under 1 min > http://skagit.meas.ncsu.edu/~helena/grasswork/rstint_gen_seg.png > > and the most important - the results are much better > default interpolation with original data (there are visible segments > and waves along contours) > http://skagit.meas.ncsu.edu/~helena/grasswork/elev_rstcontdef3d.jpg > > default interpolation with generalized data (no segments and no waves) > http://skagit.meas.ncsu.edu/~helena/grasswork/elev_rstcontgen013d.jpg > BUT I had to set dmax to a large number (1000) - the default value > added 100,000 (!) points right back on the contours. > > which brings me to the main question - are there any objections to > make dmax default value > as large as the region to make sure that it does not add any points > (currently it is set to 1.25 resolution value which is obviously not > enough)? > I have been trying to eliminate this parameter for years > as it usually causes more problems than it solves. > > Helena > > > On Aug 4, 2007, at 4:57 PM, Daniel Bundala wrote: > > > Hello Paul, Wolf and List > > > > On 8/4/07, Paul Kelly <[EMAIL PROTECTED]> wrote: > >> On Thu, 26 Jul 2007, Wolf Bergenheim wrote: > >> > >>> v.generalize: > >>> ~~~~~~~~~~~~~ > >>> v.generalize is fully functional complete with manual and > >>> smoothing and > >>> simplification operations. The module works with both areas and > >>> lines. > >>> Attribute tables are also copied and cats are preserved. Please > >>> give the > >>> module a try and send us feedback! > >>> The rest of SoC will be spent in implementing other generalization > >>> operations and getting all the rest of the bugs out. > >> > >> Hello Wolf and Daniel > >> Now I've had time to look at v.generalize too and am very > >> impressed. The > >> amount of easily-accessible functionality that this module adds to > >> the > >> GRASS vector capabilities really seems to be something > >> significant. At > >> first glance the amount of options seemed overwhelming but on reading > >> through the man page and looking at the references there it became > >> much > >> more obvious. I think it could still be made clearer, but there is > >> already > >> a lot of information and explanation there and also in the source > >> code, > >> which is good. > > > > This is true. Actually, the man page does not contain any examples. I > > will try to improve this... Moreover, I am planning to write a > > tutorial/GSoC Final Report which will demonstrate the capabilities of > > this module with a lot of examples and nice pictures... > > > >> > >> The main thing I was wondering about is whether the threshold > >> parameter is > >> dual-purpose? If I understand correctly, is it used in some > >> algorithms but > >> then again also at the end to remove lines left that are shorter > >> and areas > >> that are smaller than the threshold? Is that dual purpose use > >> likely to > >> cause any problems? Or should these be different parameters? > > > > Yes, you understand it correctly. But this happens only if you > > simplify the lines. Just few days ago, I added new flag (-r) to the > > module which specifies whether the small/short linear features are > > romeved. It is also mentioned somewhere in the newest version of the > > man page. > > > >> I am curious too as to the spelling of alfa rather than alpha! > > > > Oops. I think that this caused me some problems with TeX as well.... I > > will change it. > > > >> > >> Compiling with -Wall I see quite a lot of missing function > >> prototypes - as > >> for the other Summer of Code module I feel putting in a > >> local_proto.h for > >> the functions that can be called from other source files, and marking > >> the functions local to each file as static, would make things a bit > >> clearer. Also perhaps Doxygen-style documentation for the > >> functions? This > >> one's not a big deal at all. I know it's a bit of work but the > >> functions > >> look well organised already, so presumably there is a lot of thought > >> behind the way they are and it should be easy enough to put that into > >> words. But in general the code comments are really good and > >> helpful - only > >> there where they are needed and left out where it is obvious by > >> reading > >> the code, what is going on. > > Glad you like me style of comments... You know, *the* most boring part > > of the project. And I will check that -Wall stuff. > > > >> > >> Was thinking too about all the matrix stuff in the matrix.c file - > >> sorry > >> for this lazy question, as if I had more time to look through and > >> was more > >> familiar with these things I could answer it myself - but is it > >> better > >> than the G_matrix_* functions in lib/gmath, or just an alternative? > > > > It is probably just an alternative, but it was meant to better:) In > > the beginnings, it seemed that I will be working with the special type > > of sparse matrices only. But this is no more the case. > > > >> Would also be interesting to hear if Daniel has any suggestions for > >> improvements and tidying of the vector API in GRASS. I enjoyed > >> reading the > >> code and it seems to utilise the existing API very well, which > >> makes me > >> think it's possible suggestions for enhancements and further > >> development > >> of the API could even come out of this work. > > > > Hmmm, maybe, I was really missing built-in functions for the work with > > the single points/vectors. (Vector from > > mathematical/geometrical/physical point of view) Something I have > > implemented in point.* > > > >> But in summary, I had to search hard to find these few suggestions > >> for > >> improvement! It looks like a really excellent piece of work and it > >> will be > >> great to have it in GRASS. > >> > >> Paul > > > > Thanks Paul for your feedback! > > > > I dont know what commit/version did you use, but from the above, it > > seems that it was not the very last commit. Well, there were no > > changes in the code, but I documented displacement and "network > > generalization" operations. Just to keep you informed about the newest > > functionalities of v.generalize:) To tell the truth, "displacement" > > has very impressive results! (Stay tuned for the tutorial, everything > > will be there:) > > > > Daniel > >> _______________________________________________ > >> grass-dev mailing list > >> grass-dev@grass.itc.it > >> http://grass.itc.it/mailman/listinfo/grass-dev > >> > > > > _______________________________________________ > > grass-dev mailing list > > grass-dev@grass.itc.it > > http://grass.itc.it/mailman/listinfo/grass-dev > > _______________________________________________ grass-dev mailing list grass-dev@grass.itc.it http://grass.itc.it/mailman/listinfo/grass-dev
