[GRASS-dev] lib/vask

[Glynn Clements]

Michael Barton wrote:

> I don't follow the subtleties of implementing this in C. However, there are
> some complications to simply using gdal_transform over GRASS's i.recctify.
> So I'm guessing that the last option might be the best.
> 
> A question: is this a good point to add a flag to i.rectify to make it
> georeference INTO the current location/mapset, rather than georeference OUT
> of the current location/mapset? This would be consistent with v.tranform,
> r.proj, and v.proj.

Yes. I'm not sure whether it should be a flag, or a combination of a
location= option to specify the source location (and either a mapset=
option or allowing group=group at mapset) and making the destination
location/mapset the target for the group.

If the existing mechanism of allowing rectification from the current
location to a given target location is to be retained alongside
rectification from a given source location into the current location,
then you essentially have the ability to rectify from any location to
any other location.

> A second question: is it better to keep changing i.rectify or to create
> "r.rectify" with somewhat different functionality (given all the changes
> proposed) and begin to phase out i.rectify?

Probably. There might still be a need for an i.rectify module, but
there's no reason (AFAICT) why it couldn't just run r.rectify for each
band.

> Finally, I like Hamish's suggestion to have vector georectification conform
> to $GISBASE/group/[mapname] structure that i.points and i.rectify now use. I
> can pretty easily do this in the georectifier (though it wouldn't be
> 'enforced' the way it is with i.rectify). However, simulating v.transform
> recognizing a group of vector files is a little more complicated. Should I
> try to do this or just wait for changes to v.transform?

I wouldn't suggest using the group directory solely because that's
where the imagery subsystem stores its state. The imagery subsystem is
quite poorly designed in general, and shouldn't be copied just for
convenience' sake.

E.g. the target/points information appears to be an artifact of the
i.points/i.rectify workflow. Apart from anything else, there doesn't
appear to be any way to have multiple GCP files for a given location
(so you could rectify to multiple locations).

It would make more sense if either the GCP files were a separate type
of entity (like e.g. regions), so you could use the same GCPs on
multiple imagery groups (e.g. if you had images corresponding with the
same view taken at different times), or could have different GCP files
for the same imagery group(s) in different locations. Or if you could
store the projected coordinates in lat/lon then combine i.rectify with
proj to rectify into any given location.

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