[GRASS-dev] lib/vask

Michael Barton michael.barton at asu.edu
Sat Jun 24 11:15:17 EDT 2006


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.

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?

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?

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 15:28:22 +0100
> To: Michael Barton <michael.barton at asu.edu>
> Cc: Hamish <hamish_nospam at yahoo.com>, <rez at touchofmadness.com>, Maciek Sieczka
> <werchowyna at epf.pl>, <grass-dev at grass.itc.it>
> Subject: Re: [GRASS-dev] lib/vask
> 
> 
> Michael Barton wrote:
> 
>> Is the analyze function the same in i.points and i.vpoints? If not, what is
>> the difference?
> 
> i.vpoints uses the CRS_ version, which supports higher-order
> transformations.
> 
> Note that i.rectify and i.vpoints each have their own private copy of
> the CRS_ code, which is also the same code that GDAL uses for
> GDALGCPTransform() etc (alg/gdal_crs.c).
> 
> Should the imagery modules use GDAL directly, or should we add an
> interface in lib/imagery/georef.c?
> 
> -- 
> Glynn Clements <glynn at gclements.plus.com>




More information about the grass-dev mailing list