[GRASS-dev] Modules

[Brad Douglas]

On Sun, 2007-02-18 at 21:08 -0700, Michael Barton wrote:
> Brad,
> 
> These are 2 different issues actually, though related.

Fair enough.

> 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.

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).

> 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
users.


-- 
Brad Douglas <rez touchofmadness com>                    KB8UYR/6
Address: 37.493,-121.924 / WGS84    National Map Corps #TNMC-3785