[GRASS-dev] Re: v.generalize

Paul Kelly paul-grass at stjohnspoint.co.uk
Sat Aug 4 12:35:35 EDT 2007


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.

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?

I am curious too as to the spelling of alfa rather than alpha!

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.

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?

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.

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




More information about the grass-dev mailing list