[GRASS-dev] GRASS 7 timeline

[Brad Douglas]

On Wed, 2007-03-14 at 23:59 +0000, Glynn Clements wrote:
> Brad Douglas wrote:
> 
> > > AIUI, Brad was planning on doing this to i.class first, as it needs
> > > essentially the same treatment, and i.class is a signficantly simpler
> > > program than i.ortho.photo. The i.class changes haven't happened yet,
> > > so having the i.ortho.photo re-write completed is still a way off.
> > 
> > I don't recall this, but that doesn't mean I didn't say it (I have poor
> > short-term memory).  I haven't touched i.class in this regard.
> > 
> > Part if the reason I haven't proceeded in this direction with
> > i.ortho.photo is because the API was seemingly in flux and there is
> > little documentation for it that I am aware of...not that I've gone out
> > of my way to look.  However, now I have v.digit to use as a reference
> 
> No you don't. v.digit is a hybrid Tcl/Tk+C application, which is a
> poor choice in general. IOW, v.digit should not be used as a
> reference. If you want a reference, look at gis.m's georectifier.

Ok.  How about some documentation to go with gis.m?  It appears that
there is an API in there.  I'm not heavily experienced with Tcl/Tk and
having to parse the directory is going to be a real slowdown.

> The reason that v.digit uses that approach is because that's
> essentially how I found it, and the design of the vector library made
> it hard to implement as anything other than a monolithic application. 
> At least now it's only a hybrid Tcl/Tk+C application, rather than a
> hybrid Tcl/Tk+C+libraster application.

i.class mimics much of the GUI functionality of v.digit.  Is it possible
to go the gis.m route?

> > and I can begin to start working toward that goal.
> > 
> > i.ortho.photo has been reorganized and much of the recoding has taken
> > place, but the legacy curses still exists.  Then there is the small
> > issue of do we want 8 modules or 1 module to complete a single task (ie.
> > a front-end)?  Can we put it to a vote and be done with it?  Glynn, I
> > know you have valid reservations, but I really believe this is the best
> > approach from the user's perspective.
> > 
> > But you're right that i.class will be easier, so I'll start working on
> > that tonight to make sure I know my way around the new GUI scheme.
> 
> There isn't any GUI "scheme" for self-contained applications, beyond
> the general principle that any identifiable process which isn't
> inherently interactive should be accessible from the command line.
> 
> A good example is gis.m's geo-rectifier. Interactive placement of GCPs
> is done through the GUI, which then feeds the GCPs to i.rectify or
> v.transform. If you can obtain the GCPs by other means, then you can
> skip the GUI and just use i.rectify or v.transform directly. 
> Similarly, if you don't have Tcl/Tk installed, i.rectify and
> v.transform still work.

Much of the GUI code for the georectifier should be usable for
i.ortho.photo (point selection), but for each point, residuals need to
be calculated.  Is that appropriate for gis.m?

> The main issue is to avoid locking up useful functionality inside an
> application which can only be used interactively (and which can't even
> be compiled without libraries which aren't inherently required for
> non-interactive use).
> 
> Use Tcl/Tk (or wxPython if you prefer) for interactively editing data,
> and stick to normal command-line-driven C modules for processing the
> data.

I'm still not entirely convinced this is going to be reasonable with all
the "messages" that will get passed back and forth between the GUI and C
code for both i.class and i.ortho.photo.  I'll give it shot, though.


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