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

[Glynn Clements]

Michael Barton wrote:

> Here are a couple of possibly clarifying things and suggestions responding
> to the various items below.
> 
> GROUP:
> Just an list of raster maps that will be rectified by a single set of GCP's.
> A group directory stores the ascii list of maps to be rectified (REF file),
> the ascii file of GCP's to use (POINTS file), and an ascii file with the
> mapset and location (TARGET file) that the maps will be rectified and
> reprojected into.
> 
> If i.rectify (or r.rectify or g.rectify) could be made to work like
> v.transform, v.proj, and r.proj (i.e., rectify INTO the current mapset),
> then we could dispense with the target file.
> 
> A list of maps, raster or vector, to rectify at the same time and with the
> same set of GCP's is handy. However, if i.rectify/r.rectify allowed you to
> simply specify the GCP file to use, rather than entire group, then you could
> use a single GCP file to rectify lots of different maps--or just a single
> one--without having to first build the REF file.
> 
> So here's the suggestion. Just have a rectification algorithim (I'm liking
> g.rectify better) look for a user specified POINTS file (like v.transform)
> in a standard location (like i.rectify) in a source mapset and location
> (specified like in v.proj and r.proj) and rectify into the current mapset.
> 
> One module would do both raster and vector, work in a manner consistent with
> v.proj and r.proj, allow for alternate rectification algorithms, and allow a
> POINTS file to be used with multiple raster and vector files.
> 
> How does this sound.

Firstly, at the lowest level, the utility should allow the use of an
arbitrary GCP file (i.e. no restrictions on the name or location of
the file). Given that, it would be trivial to construct a script which
calls the utility for a GCP file with a specific name and location.

I'm not so sure about a single module for both rasters and vectors. 
There are significant differences between projecting the two; e.g. 
rasters use the backward projection but vectors the forward
projection, rasters can use various interpolation methods, etc.

My inclination would be to either extend r.proj and v.proj to support
GCP-based transformations as well as those provided by the proj
library, or to extend the gproj library itself.

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.

Rectifying /out/ of the current mapset might be tricker, but that
particular behaviour is arguably a bug which should be fixed.

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.

The main reason for not implementing it at that time was that, on the
one hand, it should probably be made more general, but on the other
hand, a more general version would require various options, and you
can't (currently) use G_parser() for a command which has an open-ended
list of options. Thus it would be necessary to extend G_parser() to
allow unknown options to be accepted.

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