On 07/08/08 06:54, Michael Barton wrote:
On Aug 6, 2008, at 9:29 PM, Glynn Clements wrote:
**i.class - This seems important. Not replicated in GUI.
**i.ortho.photo - Important. Not replicated in GUI
Important or not, i.class is fairly complex, i.ortho.photo is very
complex. Both are substantial GUI applications using curses and
libraster as a GUI toolkit.
Even a crude hack job (like the conversion of v.digit to Tcl/Tk) would
be a fair amount of work. It would be better if someone who understood
the processes involved were to re-design the UI from scratch. I would
expect that any non-trivial UI built with curses and libraster is
bound to have significant usability defects.
I'm not sure how to best go about replacing i.class. One way to start
might be to use v.edit code, since we don't need large, complex vectors.
The added value of i.class is not the training area creation. You can do
that with v.digit + v.to.rast. Its added value is the functionality it
provides around the area creation, i.e. immediately showing the spectral
signature, displaying matching cells, etc.
So, IMHO it's a (very helpful) "convenience" module, but not more. It
might be the occasion to rethink the image processing work processes and
identify which types of convenience functionalities we would like to see
and then to implement them from scratch (maybe cannibalising some of
i.class).
Moritz
_______________________________________________
grass-dev mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/grass-dev
