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

[Hamish]

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.


* 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.



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]



+______________

no need to reinvent the wheel.


Hamish