[GRASS-dev] Modules

Hamish hamish_nospam at yahoo.com
Sun Feb 18 22:39:30 EST 2007


> Maciej Sieczka wrote:
> > Getting back to your previous "not enough manpower for v.digit"
> > argument, please note that there is already a nice v.digit
> > replacement in QGIS 0.8:

Glynn Clements wrote:
> So why are we still maintaining v.digit?

because it doesn't cost us much in development time to maintain and it
gives us a mostly functional solution now.

 * QGIS would be a very big (too big?) new dependancy,
 * the two projects have different focus, goals, & target audiences,
 * at that point the debate could(should) easily morph into why we need
   our own GUI at all.

But side stepping those questions, 

If the v.digit replacement must be some full featured 2D CAD program,
and we don't want to write our own, then we might as well use QGIS.
Qcad is functional, but I wouldn't say I enjoy using it. No idea about
PythonCAD, but it would be interesting to try. If it is simple enough
maybe we could rip out the core and port it to GRASS.

If all we need is something simple, I don't think it is too far beyond
our reach to write a working v.digit replacement, preferably using
Python + SWIG. Maybe Jachym already has a prototype?? I don't see it
being /that/ hard of a chore. Especially if we start out with digitizing
new maps over raster backdrops, but not allow editing of existing data.
(gui creates v.out.ascii standard format or r.in.poly format)

Anyway, because of the QGIS solution I consider the v.digit replacement
to be a low WxPython priority. Perhaps with the experience & SWIG
maturity that will come from porting the other GUIs we can revisit the
problem after the other components are done & more easily write our own
digitizer then. Or at least be in a better position to decide.


Hamish




More information about the grass-dev mailing list