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

Thu May 25 01:59:27 EDT 2006

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
>
>

-- 

<:3 )---- Wolf Bergenheim ----( 8:>