[GRASS-dev] lib/vask

[Michael Barton]

What is needed is a predictable place to put GCP files--for RMS calculations
(i.e., projected xy or distance between projected xy and specified e/n for
that point) and for rectification.

I'm assuming that you'd need all the GCP's to do the forward projection of
GCP's. What form would you want to return them in?

I think the only things that goes into a $GISBASE/group/[mapname] folder are
a POINTS file with GCP's and a REF file with a list of raster maps to be
rectified with the POINTS file in the directory. Any suggestions for a
location if not $GISBASE/group? If we move the GCP's then i.rectify will
have to be changed or an r.rectify will have to be created to read GCP's
from the new location.

If an r.rectify module could specify an input file for GCP's like
v.transform does, it would be somewhat more flexible and multiple GCP files
can be used and reused for multiple rectifications. That is, a single GCP
file could be used for multiple raster (including image bands) and vector
files.

Michael
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton



> From: Glynn Clements <glynn at gclements.plus.com>
> Date: Sat, 24 Jun 2006 20:37:03 +0100
> To: Michael Barton <michael.barton at asu.edu>
> Cc: <grass-dev at grass.itc.it>, Maciek Sieczka <werchowyna at epf.pl>, Hamish
> <hamish_nospam at yahoo.com>, <rez at touchofmadness.com>
> Subject: Re: [GRASS-dev] lib/vask
> 
> 
> 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>