glynn at gclements.plus.com
Mon Feb 19 12:50:49 EST 2007
Brad Douglas wrote:
> > Counterintuitively, we can make GRASS much more interactive only by making
> > it possible to completely turn off any interaction built into the functional
> > modules that make up GRASS. For some modules, this is pretty easy. For
> > others, like v.digit and i.ortho.photo, it is more difficult.
> I'm slowly getting through the imagery modules, but have not committed
> anything, in part because of BLAS/LAPACK. IIRC, little things like
> i.ask can be removed simply by updating the code to use Option, etc.
> Most of the imagery modules have not been touched in many years.
> Making the modules non-interactive is not terribly difficult. In the
> case of i.ortho.photo, coordinates could be passed in either in vector
> or text format. But I insist that an interactive point selection option
> be made available when coordinates are not known in advance (especially,
> in the case of i.ortho.photo where residuals are calculated).
The problem is that we have maybe a dozen modules all implementing
interactive editing of point data themselves. If you wanted to add a
particular feature to all of them (e.g. select all points within a
circle, or select the closest point to a user-specified x,y
coordinate), you have to implement it separately for all of them.
> > V.digit specifically is the second issue. For convenience and to ensure that
> > there is always a tool to create and edit GRASS files, a digitizing package
> > built into or accompanying GRASS is highly desirable. However, Glynn's point
> > questioning the current team's ability to create and support such a package
> > is well taken. If something like v.edit can be further developed, it may
> > make this possible. But we are not there yet and it will require
> > considerable work to make it function as we need it to. QGIS may offer
> > another alternative. It is farther along, but still has a way to go (at
> > least on my Mac). As I recently said to Glynn offlist, a third possibility
> > that might be almost as desirable would be if someone in the OSGEO world
> > decided to create a multi-platform, multi-format, dedicated digitizing
> > package that could create and edit various OS GIS files.
> At least I understand the point of the discussion, now. Option 3 would
> be ideal, but probably not very realistic. I would only consider QGIS a
> serious option if the projects were merged, which is probably not
> likely, either.
> I have no good solution (or bad solution, for that matter :-) other than
> settling on a single GUI that works well across platforms and
> deprecating others. I imagine that wouldn't go over very well with
Don't consider the issue in isolation. So long as the raster graphics
architecture continues to serve as both a graphics library and a UI
library, the graphics side is going to remain incredibly primitive.
Also, anything using the modal R_get_location_* input model is
guaranteed to suck. GUI libraries have universally adopted an
event-driven input model because it produces better software (as you
don't have to explicitly handle all possible options in each
individual modal loop; or rather, cull the set of possible options to
the most critical ones).
Glynn Clements <glynn at gclements.plus.com>
More information about the grass-dev