[GRASS-dev] Modules

[Glynn Clements]

Moritz Lennert wrote:

> >>>> Realistically, I think that a 2D CAD package would be more likely to
> >>>> be suitable, but I don't know of any free ones.
> >>> http://www.qcad.org/qcad.html
> >>> (see http://www.qcad.org/qcad_doc_faq.html#36 ff for licensing)
> >> Requires Qt 3.x, the native Windows version of which isn't free. I
> >> suppose that you could build it for Cygwin.
> > 
> > It turns out that you can, but the GPL version doesn't support
> > polylines, which is probably a fairly major omission for a potential
> > v.digit replacement.
> 
> I think I have missed something in the discussion: does it seem too 
> difficult to develop a replacement of v.digit based on v.edit ? It seems 
> a bit overkill to require the use of an external CAD package for 
> digitizing, which IMHO is one of the core functions of a GIS.

Well, v.digit isn't a trivial program, and there's plenty of things
which v.digit doesn't do which might be useful (e.g. undo, coordinate
display, measurements, ...) and which you would normally get with a
CAD program.

In terms of a replacement, Radim's comments in:

	http://grass.itc.it/pipermail/grass-dev/2006-April/022569.html

imply that you really need a monolithic program.

One of the issues is that v.digit uses Vect_get_updated_{line,node} to
only redraw lines which are changed. AFAICT, the "updated" status
isn't persistent, so it has to be called from the same process that
performed the modifications.

[Or maybe v.edit could export the Vect_*_updated_* information?]

The alternatives would be to re-import the entire map after each
change, or to re-implement chunks of the vector library in Tcl (or
Python) so that you can keep the digitiser's internal representation
synchronised with the GRASS database.

OTOH, those issues would also apply if you were using a generic CAD
program (i.e. you would have to re-build the GRASS-specific
information upon import).

It's looking as if the most practical replacement is going to be to
take the existing v.digit, and replace R_*, D_* and Tcl_* with a real
GUI toolkit.

I suppose that you could replace R_* and D_* with calls to Tcl/Tk's C
API, but Tcl/Tk's C API (particularly the Tk part) is quite messy
(compared to e.g. GTK, Qt, wxWidgets etc) and isn't widely understood
(I don't even know if Bob Covill is familiar with it; NVIZ only has a
handful of Tk_* calls outside of togl.c).

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