[GRASS-dev] Modules (was: Cygwin winGRASS 6.2 Errors! [SUCESS})

[Glynn Clements]

Brad Douglas wrote:

> > In scanning through the --helps to see if the cygwin modules worked
> > I found it got stuck on i.ortho.photo. I've now changed the main menu of
> > that to use G_parser().
> > 
> > (the i.ortho.photo menu could easily be rewritten BTW, it just lists 8
> > programs and runs the one you ask for. But then the ones it calls will
> > generally call I_ask() and want a interactive terminal, so there might
> > be little gained in the short term..)
> 
> I had completed the majority of rewriting i.ortho.photo, but quit
> working on it when it became clear that there was no consensus as to
> whether I should A) break it up into 6-7 separate modules or B) a single
> module with an 'option='. (My tree is full of incomplete work :-)

or C) delete it, then bang your head against a hard surface until
you've forgotten that it ever existed in the first place.

i.ortho.photo is the 100-tonne anchor weighing down GRASS. When
considering any non-trivial API change, the first question is always:
does i.ortho.photo rely upon existing behaviour? If it does, then the
change isn't going to happen. If it doesn't, then the worst that can
happen is that you merely have to re-write everything except
i.ortho.photo.

Oddly enough (not!), most of the lesser "anchors" are also to be found
in the imagery directory.

I've been looking at the work involved in updating the graphics API to
something more useful. The main issue isn't writing a new API, but
modifying existing clients to make use of it. In terms of existing
usage of the R_* functions, the top 10 users are:

     79 imagery/i.ortho.photo/photo.2image
     72 imagery/i.vpoints
     69 imagery/i.ortho.photo/photo.2target
     63 imagery/i.points
     45 imagery/i.class
     38 display/d.vect
     32 display/d.histogram
     27 display/d.profile
     19 imagery/i.ask
     18 raster/r.le/r.le.setup

In spite of the "d." prefix being intended for display modules, the
first d.* module (d.vect) is in 6th place, behind 5 imagery modules (2
of which are part of i.ortho.photo).

The above is limited to modules; for libraries, the statistics
are:

     78 lib/display
     25 lib/raster
     15 lib/D

Yep, photo.2image is a heavier user of the raster library than
lib/display.

In summary, unless we can either find a very dedicated volunteer, or
are willing to accept much of i.* being dumped altogether, we're stuck
with the existing graphics API.

-- 
Glynn Clements <glynn at gclements.plus.com>