Daniel, Wolf

many thanks for a great new module.
I wanted to write just a few comments but I ended up doing a small "research project".
My main interest was to find out how we can use line generalization
to preprocess contours or profiles to avoid some notorius interpolation problems -
I will write about that in my next message,  first some comments:

1. It would be great if you could use the new data set at least for some
examples in the tutorial and manual, Markus has just released version 06
- it is available from here:
http://www.grassbook.org/data_menu3rd.php

It has detailed streams and streets data where the differences
between different methods nicely show up. I haven't tried any areas, but urban
areas, soils and planimetry would be good candidates for generalization.

2. The module indeed needs a tutorial but make sure that you put sufficiently
detailed description, notes and examples in the man page.
The past experiences show that the man pages are being kept relatively
up-to-date but the tutorials updates tend to be neglected.

3. On technical note - when I tried stream generalization with -r flag
many internal stream segments got removed (the streams essentially fell appart)
I assume I did not use this option as intended, you may want to explain
the right use in the manual.

4. In relation to your answer to Paul's comments below -
built-in functions for the work with the single points
would be huge help and could eliminate the current mixture of old
and new get-arounds / left-overs from the old site format and troubles
with topology building for larger point data sets. I found the current handling
of points really confusing and not very efficient.

I would like to encourage others to test the module too so that it can be included into CVS. I have tried only very little from the rich set of options that the modules offers so more
testing will help,

Helena


Helena Mitasova
Dept. of Marine, Earth and Atm. Sciences
1125 Jordan Hall, NCSU Box 8208,
Raleigh NC 27695
http://skagit.meas.ncsu.edu/~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

Reply via email to