[GRASS-dev] Request to add a GCP file in vector directories

[Michael Barton]

Currently, I've got the gcp file stored in $GISDBASE/vector/[vector name].
It is no problem to put into $GISBASE/group/[vector group].

But to do this, it would be better if...

--i.group (or a new v.group) could create the group structure and the group
file

--v.transform could read a group file and act on the vectors listed

--v.transform could read a standard POINTS file and use or ignore the "use
gcp" column.

I could emulate steps 1 & 2 in TclTk (and probably hack step 3), but it
would be better in the long run if the GRASS C modules acted in a consistent
way for vectors and rasters.

I'll keep the 'test version' of the rectifier as is for the moment, but can
change it to use a group structure if that's what we want and can make the
changes to i.group/v.group and v.transform.

Michael
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics and 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: Wed, 7 Jun 2006 12:15:14 +0100
> To: Hamish <hamish_nospam at yahoo.com>
> Cc: Michael Barton <michael.barton at asu.edu>, <grass-dev at grass.itc.it>
> Subject: Re: [GRASS-dev] Request to add a GCP file in vector directories
> 
> 
> Hamish wrote:
> 
>>> This is a good point. Should a generic gcp file just be stored in
>>> PERMANENT? What about maps with different extents--especially
>>> non-overlapping maps--in the same location?
>> 
>> I'm not a fan.
>> 
>> e.g. I've got a mapset:
>> 
>> grassdata/simple_xy/charts/
>> 
>> where I have scanned versions of nautical charts imported.
>> 
>> For each new chart I have it's own group with its own GCP info.
>> 
>> I don't want a new mapset, let alone location, for each new scan.
> 
> Right. It depends largely on whether the location is being used as a
> general purpose container or like a normal (georeferenced) location
> except that it has a non-standard projection.
> 
> Even in the latter case, you might need multiple transformations, as
> one which is a good fit for one map might not be a good fit for
> another. Producing a transformation which is a good fit for the entire
> location would be difficult if you can only set reference points over
> a single map.
> 
> Support for locations with user-defined (polynomial) projections would
> need to be in addition to the existing transformation tools, not a
> replacement. But it may be worth considering at this point.
> 
>> The group thing is good logically & works well in practice.
>> Again I'd suggest we keep using the same method, just make a nice
>> front end for it which merges and hides the gritty details.
>> (I can picture a tabbed GUI with target in one, registed maps in
>> another, etc..)
> 
> Command-line front-ends for some of the tools would also be nice.
> 
> [By "command-line", I mean input via command-line options and/or
> files/stdin, rather than via curses forms.]
> 
> -- 
> Glynn Clements <glynn at gclements.plus.com>