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 > [email protected] > http://grass.itc.it/mailman/listinfo/grass-dev > _______________________________________________ grass-dev mailing list [email protected] http://grass.itc.it/mailman/listinfo/grass-dev
