wxgrass gui status: was [GRASS-dev] Vect_snap_lines (list of lines)

[Michael Barton]

This is a good place to give a quick update and lookahead for the
development gui. Jachym, Martin, Daniel, and others have done a real bang up
job of collaborating to get this new interface up and running so fast. It's
been a really big job.

I'm now working on a profiling module and will subsequently go through the
tedious work of adding the rest of the commands to the menu--unless someone
finds a faster way to do this or takes pity and does it for me ;-). This
should happen soon--within the next month probably.

This will bring wxgrass pretty much up to serious testing/production status.
In order to completely transition from TclTk to wxPython, we will need the
following:

1. wxPython replacement for v.digit. As indicated below, Martin is working
on this.

2. wxPython replacement for the nice r.edit module that Glynn did. This
could be done pretty easily if we had an r.cell.edit module. This
hypothetical module would accept coordinate(s), cat value(s), and label
value(s), and change the cell or cells at the coordinates. e.g.

r.edit.cell map=[raster map] coords=[x,y] cat=[new catnum] label=[new label]
There would be some advantage of allowing batch changing of multiple cells,
but this is not essential if it is too complicated (e.g.,
coords=[x1,y1,x2,y2,...] cat=[cat1,cat2,...] label=[label1,label2,...]

I can immagine r.edit.cell being be used in a variety of other script
applications too, especially dynamic modeling.

3. A non-interactive version of g.setproj OR a further expansion of g.proj
to allow it to use the same kind of input data on projections, datums, etc
from the lists that GRASS provides. We've got an almost functional
location-setting wizard that is really nice. But we're stuck on not being
able to replicate the functionality of g.setproj with currently available
tools.

4. A wxPython replacement for the georectify module. I will start working on
that after the profile module.

5. A new implementation of nviz functionality in the wxPython GUI
environment. This doesn't need to be  direct port of the current stand-alone
nviz module (which dates back a decade). It could well appear to users as an
nviz toolbar (code structure already in place for different toolbars) which
displays its 3D images on an existing canvas and makes use of existing tools
for zooming, panning, and querying for example. This should involve some
thought and planning.

I think that we are quite close on all but #5. I don't know what #5 would
entail but think that it requires expertise that I at least don't
have--although I am willing to help however I can and I'm sure that the rest
of the team feels the same.


Michael

On 5/11/07 8:30 AM, "Martin Landa" <landa.martin at gmail.com> wrote:

> Hi all,
> 
> working on v.edit I need snapping fn which does not operate globally
> but only on the list of selected lines. I modified snap.c, added
> Vect_snap_lines_list(), current Vect_snap_lines () calls
> Vect_snap_lines_list(). Behaviour of Vect_snap_lines () fn should be
> untouched.
> 
> Any objections to commit these changes?
> 
> Martin

__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics and Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton