[GRASS-dev] PROPOSAL: v.edit WAS: d.* commands

Trevor Wiens twiens at interbaun.com
Thu May 25 00:01:20 EDT 2006


On Wed, 24 May 2006 20:50:20 -0700
Michael Barton <michael.barton at asu.edu> wrote:

> This is along the lines of what I thought would be a good replacement for
> v.digit. Glynn had some ideas too, so I hope he offers an opinion here. This
> kind of command line module for modifying vector objects could then be
> accessed by any GUI/display management system that could draw on a display,
> capture coordinates, and pass them to the relevant vector. The on-screen
> vector could then be redrawn to reflect the change.
> 

Would this type of implementation also allow for adding functions like
joining polygons in a digitizing window environment. This might be
really elegant if one could specify which of the two or more objects
attributes of the objects being merged would be retained. Right, AFAIK
we need to manually delete the common boundary and one of the
centroids. Since there is a function to dissolve common boundaries in
v.extract, perhaps this might be a nice addition. I've used v.reclass
and v.extract for this, but sometimes it is necessary to do some of
this interactively. I suppose I could assign attributes accordingly and
then extract to dissolve, but it would be nice to do this interactively.

Also, it would be really nice to have an undo function built in. I find
using v.digit very frustrating because I can't just "undo" my mistakes
or exit without saving.

> On 5/24/06 2:49 PM, "Wolf Bergenheim" <wolf+grass at bergenheim.net> wrote:
> 
> > On Wed, 24 May 2006, Michael Barton wrote:
> >>> 
> >>> If this is something that I can do, I would like to try and get a few
> >>> of the more important ones updated before the feature freeze. I am not
> >>> a great C coder, however, so this could get ugly.
> >> 
> >> Thanks very much for offering to help. IMHO, the most valuable thing anyone
> >> could do to make GRASS 6.2 a complete system would be to port i.points
> >> and/or v.digit to the new architecture so that they could work in a TclTk
> >> canvas rather than requiring X11. NVIZ seems already on track to get there
> >> soon.
> >> 
> > 
> > How about making a v.edit that would work a bit like this:
> > 
> > v.edit task=[add,del,move,etc..] what=[point,line,centroid]
> >         db=[an SQL statement for UPDATE
> >         args=[task and what specific]
> > 
> > so for example to add a new point one could call
> > 
> > v.edit task=add what=point db='name="survey location 73" depth=34'
> > args=x=25.242424,y=34.45634
> > 
> > and to add a line one could call
> > 
> > v.edit task=add what=line db='name="road #73" speed=70'
> > args=25.242424:34.45634,25.34343:34.34353,25.6754:34.6453
> > 
> > delete is trivial
> > 
> > v.edit task=del what=line args=345
> > ^This is the cat ID.
> > 
> > Just as an idea. If you like this I can start working on defining the
> > syntax so that one can edit all sorts of shapes. Another possibility would
> > be that it would read commands from a file (or stdin). Which would you
> > guys prefer?
> > 
> > If reading from a file then the syntax can be more complex (even XML if we
> > want it to).
> > 
> > --Wolf
> 
> ___________________________
> Michael Barton, Professor of Anthropology
> School of Human Evolution & Social Change
> Center for Social Dynamics & Complexity
> Arizona State University
> 
> WWW - http://www.public.asu.edu/~cmbarton
> Phone: 480-965-6262
> Fax: 480-965-7671
> 
> _______________________________________________
> grass-dev mailing list
> grass-dev at grass.itc.it
> http://grass.itc.it/mailman/listinfo/grass-dev


-- 
Trevor Wiens 
twiens at interbaun.com

The significant problems that we face cannot be solved at the same 
level of thinking we were at when we created them. 
(Albert Einstein)




More information about the grass-dev mailing list