[GRASS-dev] lib/vask

[Glynn Clements]

Brad Douglas wrote:

> > > > The selection of GCPs should probably be integrated with Michael's
> > > > i.points replacement.
> > > > 
> > > > Is there any reason why other forms of interaction (other than visual
> > > > selection of coordinates) would be necessary?
> > > 
> > > 
> > > Beyond the mouse, keyboard entry is needed. e.g. set a GCP to where
> > > lat/lon grid lines meet by marking "+" spot and keying in coordinates,
> > > or getting GCPs coords by travelling to a landmark with a good GPS.
> > 
> > Are you referring to entering one point with the mouse and the
> > corresponding point as numerical coordinates? I can see why that would
> > need to be interactive. Can that not be integrated with the i.points
> > replacement?
> 
> Yes.  Yes, but might it have to be reimplemented for other modules?

Why? Entering GCPs sounds like something which should be done by a
single tool rather than several similar tools. Any modules which use
GCPs should simply read GCP files created by that tool.

> > Essentially, to what extent is it possible to separate the entry of
> > GCPs and other parameters from the actual rectification? Ideally, you
> > want to have as much code as possible in a non-interactive core, with
> > interaction limited to the outermost layer.
> 
> Getting GCPs is one step.  Rectification is another step (down the
> line).  I would also expect to be able to input GCPs via file, also,
> however rare it would be used.  I plan to implement the rectification
> with GDAL, so one way or another, I'll have to get the GCPs into their
> format.  The input and the "work" would be isolated.

Obviously the input step needs to be interactive, but the
rectification step shouldn't require interaction, right? Or am I
missing something?

> How is v.digit going to be handled?  That has a similar situation.  If
> we move solely to a command driven methodology, we won't be able to
> digitize/edit [new] vector maps. :(

v.digit is inherently interactive. It's essentially all input and no
processing, i.e. a data editor.

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