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

[Glynn Clements]

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

There's still the issue that you have to figure out exactly what will
be changed by the edit. Otherwise, every time you make an edit, you
would have to re-build the contents of the canvas from scratch.

You also need some way to get the data from the map into the UI. At a
minimum, you only want the portion which falls inside the current
region (not the entire map), but being able to retrieve only the
changed parts would be preferable (v.digit uses
Vect_get_num_updated_lines() and Vect_get_updated_line()).

It would be a lot simpler to build a v.digit replacement around an
immediate-mode canvas (e.g. GtkDrawingArea) and the vector library. 
Whenever you change anything, you just invalidate the canvas, which
would then be redrawn somewhat like d.vect, except using GDK/etc
instead of the raster library. The main issue there is whether the
vector library is fast enough for full redraws.

-- 
Glynn Clements <glynn at gclements.plus.com>