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

Fri Aug 17 01:19:46 EDT 2007

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