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

Thu May 25 02:45:58 EDT 2006

what about adding the -n flag or --no-topology? This would make it
usable for external programs and also for single command line operations

Jachym

On Wed, May 24, 2006 at 11:13:45PM -0700, Michael Barton wrote:
> I don't know whether multiple edits or single edits work better from the
> standpoint of a v.edit module.
> 
> Michael
> 
> 
> On 5/24/06 10:59 PM, "Wolf Bergenheim" <wolf+grass at bergenheim.net> wrote:
> 
> > On Wed, 24 May 2006, Michael Barton wrote:
> > 
> >> These would be very good functions to build in. The undo, would probably
> >> best be implemented in the GUI/display management system. It could store up
> >> changes and implement them on command. I'm not sure how this could be done,
> >> but it probably could be.
> > 
> > I agree I would also like to see this undo feature, and exit without
> > saving. the GUI part could simply store a queue of v.edit commands to
> > execute for the save part, and somehow put the drawn objects in a display
> > queue. In the event of an undo it could simply remove the last item from
> > both queues and then redraw the screen.
> > 
> > One concern I have before I start to design the interface, is that will it
> > be an expensive operation to execute an external program for each object
> > to digitize? I mean the program will have to be launched, then it will do
> > its thing and then it will recalculate the topology, right? I'm mainly
> > wondering whether it would make sense to allow multiple edit commands in
> > one go of v.edit? Would it increase the speed? On the other hand the
> > v.edit commands can be executed in the background, and the user doesn't
> > have to sit and wait for them to complete.
> > 
> > --W
> > 
> >> 
> >> Michael
> >> 
> >> 
> >> On 5/24/06 9:01 PM, "Trevor Wiens" <twiens at interbaun.com> wrote:
> >> 
> >>> 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
> >>> 
> >> 
> >> ___________________________
> >> 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
> >> 
> >> 
> 
> ___________________________
> 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

-- 
Jachym Cepicky
e-mail: jachym.cepicky at centrum.cz
URL: http://les-ejk.cz
GPG: http://les-ejk.cz/gnupg_public_key/jachym_cepicky-gpg_public_key.asc
-----------------------------------------   
OFFICE:                                     
GDF-Hannover
Mengendamm 16d
30177 Hannover
Germany
e-mail: cepicky at gdf-hannover.de
URL:    http://gdf-hannover.de
Tel.:   +49 511-39088507
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.osgeo.org/pipermail/grass-dev/attachments/20060525/d01836a6/attachment.bin