[GRASS-dev] Request to add a GCP file in vector directories
Michael Barton
michael.barton at asu.edu
Wed Jun 7 13:14:45 EDT 2006
Hamish,
Haven't read through all my mail from overnight yet, so there might be
comments by others. But I'll start with my own.
See below.
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: Hamish <hamish_nospam at yahoo.com>
> Date: Wed, 7 Jun 2006 22:34:00 +1200
> To: Michael Barton <michael.barton at asu.edu>
> Cc: <grass-dev at grass.itc.it>
> Subject: Re: [GRASS-dev] Request to add a GCP file in vector directories
>
> Michael Barton wrote:
>
>> I¹m integrating vector georectification (v.transform) into the GIS
>> Manager georectifier. It would be nice if a GCP file could be saved in
>> a vector folder so that it could be called up, edited, and reused and
>> a user doesn¹t have to re-enter GCP¹s every time they start the
>> georectifier. This is the case now for rasters, because a GCP file
>> (POINTS) is saved inside the group folder for a raster group.
>>
>> I¹m proposing to have the georectifier (at the user¹s option) save a
>> file named ³gcp² (points might be confusing in a vector folder) in the
>> appropriate vector folder to be rectified. It would be a simple ascii
>> text file and take the format of the standard file needed by
>> v.transform, with the addition of a header indicating the target
>> location and mapset it is aimed at. For example...
>>
>> # target: /Users/shared/grassdata/spearfish60/newvector
>> -584 585 598000 4920770
>> 580 585 598020 4920770
>> 580 -600 598020 4920750
>> -584 -600 598000 4920750
>
>
> a couple of points:
>
> * "group" isn't (or shouldn't be) limited to raster maps.
>
> It's a common thing to have a bunch of maps in one projection and need
> them in another. (e.g. multiple satellite channels)
> I have a dozen XY vectors here which all exist in the same CAD space, it
> would be grand if I could transform them all without diving into the
> MAPSET dir & copying the file by hand..
>
> I suggest you reuse group/ folder & structure.
This seems fine and is the reason I wanted to save a vector gcp file.
However, v.transform won't read a 'group'. I could emulate it in TclTk, but
if this is what we want to do, it would be better to have v.transform simply
work like i.rectify.
>
>
> * reuse the POINTS file format. It's the same thing with different
> whitespace & comments. It's not so bluky that there's a real need to
> simplify it. The "status" column gets set to 0 when you disable a point
> in i.rectify, this is a good thing.
>
> The less divergence the better until a full rewrite.
Again, v.transform might have problems with the 1 or 0 at the end of each
GCP line. Otherwise, the formats are the same. Again, altering v.transform
to read a standard POINTS file makes for nice consistency.
>
>
>
> mind that gdal uses different row convention to GRASS. (flipped)
> See my i.warp script,
>
> http://bambi.otago.ac.nz/hamish/grass/gdal/sidescan_warp.html
> (also a demo of the broken CRS order=3 in GDAL there)
>
> note 6.1/6.0 difference, IIRC it comes from r.in.gdal in 6.0 importing
> the entire thing in negative coordinates. The difference is on the
> GDAL_GCP= line?? (-r reverse sort). It's a bit of a mess .. was trying
> to debug a GDAL memory problem without a clue. [in the end running
> gdalwarp -tps via electric fence and removing some GCPs helped the most;
> run in two passes and r.patch the results together rather that fix the
> breakage for the full scene]
This and other issues make me shy away from trying to add in the abilty to
use gdalwarp right now. It needs very different parameters, requires more
file manipulation, and doesn't do vectors (AFAIK). I kind of like your idea
better to use gdal libraries.
>
>
>
> +______________
>
> no need to reinvent the wheel.
Rather, lets have the same wheels all around the vehicle.
Michael
>
>
> Hamish
More information about the grass-dev
mailing list