[GRASS-dev] Re: v.generalize

[Daniel Bundala]

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
>