[GRASS-dev] lib/vask [i.points replacement]

[Glynn Clements]

Michael Barton wrote:

> > As for processing multiple maps: the calculations involved in
> > computing the projection from the GCPs are trivial (in terms of CPU
> > usage) compared to the actual projection. It wouldn't be noticeably
> > less efficient to have a script call the projection utility once for
> > each map.
> > 
> > If you had an r.rectify command (or an extended r.proj) which
> > rectified a single map using an explictly-specified GCP file, it
> > shouldn't be much work to re-implement i.rectify as a script which
> > runs r.rectify on each map in the REF file, using the POINTS file from
> > the "group" directory.
> 
> I was thinking of having it work more like g.remove. You could simply list a
> set of maps in the input argument. e.g.,
> 
> r.rectify input=map[,map,map,...] points=file location=source_location
> mapset=source_mapset method=[method (default to 1st order)]

The mapset= option should be unnecessary; you should be able to use
map at mapset for the input maps.

There should also be an output= option (this can default to the same
name as the input, but it should be possible to override it).

> either have a v.rectify that works the same way (currently v.transform only
> works with maps in the same mapset for source and target) or have a
> g.rectify that would replace input= with vect= and rast=

I think that raster and vector transformation are too different to
bother having a common utility. Given that the actual transformation
code would be in a library (either the imagery library or GDAL), they
wouldn't really have much in common.

OTOH, each one would have quite a lot in common with [rv].proj.

> > Aside:
> > 
> > I've wondered whether it would be worth having a general-purpose
> > "g.multi" command which executes a command "template" on multiple
> > maps. This first occurred to me in the context of handling colour
> > images as R/G/B channels; i.e. having a g.rgb command which would be
> > used like e.g. "g.rgb r.rescale in=inmap.% out=outmap.% ...", where
> > the % would be replaced with r/g/b on each run.
> 
> Interesting, but is this necessary when you can have multiple inputs?

No. But there are plenty of commands which only accept a single input. 
A separate utility is likely to be easier than extending all of those
commands to allow multiple inputs.

OTOH, typing a "for" loop isn't really much effort.

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