[GRASS-dev] Modules

Paul Kelly paul-grass at stjohnspoint.co.uk
Wed Feb 21 11:54:01 EST 2007


Hello Moriz

On Wed, 21 Feb 2007, Moritz Lennert wrote:

> On 21/02/07 09:00, Glynn Clements wrote:
>> Glynn Clements wrote:
>> 
>>> It's looking as if the most practical replacement is going to be to
>>> take the existing v.digit, and replace R_*, D_* and Tcl_* with a real
>>> GUI toolkit.
>> 
>> To this end, I've started refactoring v.digit in the hope of making it
>> easier to use a conventional GUI toolkit.
>> 
>> So far, I've modified attr.c and line.c, corresponding to the
>> following "tools":
>> 
>> 	copy cats
>> 	display attributes
>> 	display cats
>> 	new line
>> 	edit line
>> 	move line
>> 	delete line
>> 
>> Although I've tried to test it as much as possible, I'm not
>> particularly familar with v.digit (never having used it before this
>> week), so I would appreciate it if people who are familiar with it
>> could check that I haven't broken anything (there shouldn't be any
>> user-visible differences as a result of the changes).
>> 
>
> How is this to be understood in relation to v.edit ? Are these complementary 
> ?

I may or may not be able to see the whole picture here, but what I took 
from the recent discussions was that v.edit is not usable as a backend for 
a v.digit replacement because of its requirement to commit all changes and 
re-build topology after every edit. v.digit functionality needs to include 
undo/redo, incremental topology building etc. which means it needs to be 
programmed in C with direct access to the vector library functions.

But as Maciek pointed out v.edit is really useful for small scale use in 
scripts. In fact creating simple vector maps for little experiments and 
tests sounds like a killer application for it.

Disclaimer: I may have misunderstood the capabilities of either module...

Paul




More information about the grass-dev mailing list