[GRASS-dev] Re: v.generalize and interpolation, dmax problem

Fri Aug 17 13:33:21 EDT 2007

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 <hmitaso at unity.ncsu.edu> 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 <paul-grass at stjohnspoint.co.uk> 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 at grass.itc.it
> >> http://grass.itc.it/mailman/listinfo/grass-dev
> >>
> >
> > _______________________________________________
> > grass-dev mailing list
> > grass-dev at grass.itc.it
> > http://grass.itc.it/mailman/listinfo/grass-dev
>
>