[GRASS-dev] Modules

[Michael Barton]

I wonder if it would be fairly easy just to make "aerial photo" a 3rd option
for the georectifier (i.e., add a 3rd radio button). Then there could be a
button (only activated if "aerial photo" is selected) that would bring up an
entry widget to put in ortho-photo-specific information.

Michael


On 2/19/07 10:50 AM, "Glynn Clements" <glynn at gclements.plus.com> wrote:

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

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

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