This sounds good to me; I agree that topologically sensible editing should
be enabled by default, and persistent undo would be a really nice feature as
well. Would it be beneficial to have a 'Commit Changes' button or something
to write the current queue of edits to disk so they don't all have to be
committed at the end?
--
Eric Patton
epatton@nrcan.gc.ca
-----Original Message-----
From: grass-dev-bounces@grass.itc.it [mailto:grass-dev-bounces@grass.itc.it]
Sent: Friday, May 26, 2006 11:31 AM
To: Wolf Bergenheim; GRASS developers list
Subject: Re: [GRASS-dev] v.edit initial version
----- Original Message Follows -----
From: Wolf Bergenheim <wolf+grass@bergenheim.net>
To: GRASS developers list <grass-dev@grass.itc.it>
Subject: [GRASS-dev] v.edit initial version
Date: Fri, 26 May 2006 13:47:09 +0300 (EEST)
Hi!
I added v.edit to the CVS. This initial version can only add points
(one or many) to a map. It does not touch the database yet.I have a problem with the field variable in Vect_cat_set and friends.
What does it mean and what does it do? In my tests it seem that it
should be 1... Can someone explain it? Also what does it have to do
with the fields member of the line_cats structure?--Wolf
I've been thinking some more about v.edit and the replacement of v.digit. In
the context of allowing the maximum flexibility to the end user, would it be
a good idea for the future digitizing module to load a light weight copy
(something with minimal topology information) of the vector file in question
and simply process it keeping track of all commands issued, so they could be
sent to v.edit upon exiting or saving. By storing all commands as they are
issued it would theoretically allow a user to undo as many times as they
wished. Then v.edit would simply take a command list at the end of a
digitizing session and issue all the commands in order.
The reason I think that some topology information is desirable is that we
don't want to allow users to create topologically ill formed data, so rather
than simply storing the vectors as spaghetti data and treated as a drawing
program, we need to make sure that end users can't do bad things.
There might be a more elegant solution than this, but I thought it was worth
asking others on the list what they thought of this.
T
--
Trevor Wiens
_______________________________________________
grass-dev mailing list
grass-dev@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass-dev
