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

[Michael Barton]

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