[GRASS-dev] GRASS 7 timeline

[Glynn Clements]

Brad Douglas wrote:

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

Only superficially. What makes v.digit different is that any changes
are immediately applied to the vector map being edited. v.digit
doesn't have its own copy of the vector data; it's all either in the
vector map itself or the Tk canvas. Also, v.digit is "pure" interface;
there isn't any processing.

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

This sounds much like the relationship between i.points, g.transform,
and the gis.m georectifier. g.transform was written specifically to
extract the "processing" portion of i.points as a command-line module,
leaving the Tcl/Tk code to handle the interactive aspects.

I don't know whether g.transform will be useful as-is. It is
essentially a command-line wrapper around a more advanced version of
I_compute_georef_equations(), the difference being that the CRS code
used by g.transform also supports biquadratic and bicubic
transformations in addition to bilinear transformations.

Can someone describe (briefly) how the rectification performed by
photo.rectify differs from that performed by i.rectify?

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