[GRASS-dev] Modules

[Michael Barton]

Brad,

These are 2 different issues actually, though related.

The first has to do with interactive use generally. GRASS absolutely
requires interactive use. I couldn't agree more. AFAIC, any useable,
full-featured GIS package should permit the user to directly manipulate
geospatial data. In fact, the more and richer interaction the better for me.

The question on interactive use is how best to program this. While you
probably know much of the following, it seems a good time to review to the
list the trajectory for getting such interactivity in GRASS. Dating back to
its use on Unix workstations of the 1980's, GRASS managed this through: 1)
question and reply text sent to a terminal window and 2) in an old-style
graphics xterminal that involved a combination of on-screen menus,
question/reply in text, and key/mouse button combinations. Any interaction a
module needed was programmed into it in C.

We now have a much richer suite of interaction tools to use if we employ
interface design packages like TclTk, GTK, QT, wx.Widgets, and wx.Python.
However, to use them, we either have to 1) rewrite all GRASS modules that
need interaction to call the programming language and libraries of these
packages (e.g., TclTk C libraries, C++ for QT or wx.Widgets, Python for
wx.Python), or 2) create the interaction independently in a GUI platform and
have it interface to GRASS via shell calls to existing GRASS C modules.
Given the development team's programming resources and expertise (limited
and almost exclusively in C), option 2 seems like the most realistic way to
approach this. However, to make all GRASS functions accessible (and
accessible interactively where appropriate) to an independent GUI platform,
GRASS modules must be scriptable--i.e., it must be possible to 'turn off'
any interaction built into the GRASS C modules. Otherwise, they cannot be
used in an independent GUI platform.

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.

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.

We enough rambling.

Michael


On 2/18/07 8:27 PM, "Brad Douglas" <rez at touchofmadness.com> wrote:
>> So why are we still maintaining v.digit?
> 
> Because QGIS is not part of GRASS?
> 
> Until all other modules that require interactivity (i.ortho.photo,
> i.vpoints, i.cca, i.spectral and others come to mind) are "ported"
> there's no reason to not support v.digit unless it's broken.
> 
> No matter how much you may not like it, there are parts of GRASS that
> *require* interactive input.
> 
> FWIW, I think offloading to another package or removing imagery support
> is shortsighted.  GRASS would become useless to me for the majority of
> my work.
> 

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

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