[GRASS-dev] grass6.2?

[Michael Barton]

Wolf,

Thanks for the offer.

1. In order to calculate RMS error, it is necessary to transform the GCP's
unprojected coordinates into projected coordinates, and calculate the
diagonal distance between the transformed coordinates and the coordinates
used to define the transformation. Apparently, there is already C-code to do
this in the imagery library. Glynn said that he might be able to do a quick
C-module to accomplish this, using existing code rather than have anyone
write new code to do it.

2. I've combined raster and vector georectification into one module.
However, the set up for georectifying vectors differs from rasters in
several ways. Hamish and others suggested that this is a good time to make
them consistent. This involves modifying v.transform and either extending
i.group or making v.group. Here are the differences...

I.group creates an ascii REF file listing all rasters that will be rectified
using the same set of GCP's (stored in an ascii POINTS file). It also
creates (if necessary) a group directory structure
$GISBASE/group/[groupname] where REF and other georectifing configurations
files are stored.

There is no equivalent v.group

I.target creates an ascii TARGET file that lists the projected
location/mapset into which the files in REF will be projected.

There is no equivalent for vectors. This is needed by i.rectify but not by
v.transform.

I.points interactively creates a 5 column POINTS file that is used for
rectifying rasters. The columns are unprojected x, unprojected y, projected
east, projected north, a boolean (0/1) value that determine whether the row
(a GCP) is used in rectification and RMS calculation. It calculates RMS
error for the GCP's in the points file (those with a 1 in the 5th column).
It saves the POINTS file in $GISBASE/group/[groupname]/

There is no equivalent v.points. V.transform uses an ascii file very similar
to the POINTS file, except that it lacks the 5th column. In other words, all
GCP's in a vector points file are used for georectification. There is no
interactive program like i.points to create a vector points file. The vector
points file can be stored anywhere and have any name.

The georectifier is replacing i.points and serves to create a points file
for vectors too.

The suggestion is to have v.transform and i.rectify read files of identical
5 column format, have v.transform work on groups of vectors rather than just
a single vector, and use a directory structure of $GISBASDE/group/... For
vectors as well as rasters.

This requires something to set up the group structure, REF file and possibly
TARGET file for vectors (extended i.group, or a new v.group), and changing
v.transform to use the group directory/file structure, read a 5 column
POINTS file, and possibly a TARGET file.

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: Wolf Bergenheim <wolf+grass at bergenheim.net>
> Date: Sat, 10 Jun 2006 15:54:34 +0300 (EEST)
> To: Michael Barton <michael.barton at asu.edu>
> Cc: Helena Mitasova <hmitaso at unity.ncsu.edu>, <cavallini at faunalia.it>,
> <grass-dev at grass.itc.it>
> Subject: Re: [GRASS-dev] grass6.2?
> 
> On Fri, 9 Jun 2006, Michael Barton wrote:
>> 
>> georectifier: C script for RMS error, updates to v.transform so that it can
>> read or ignore a 5th column (use gcp) in a points file, creation of v.group
>> (if everyone thinks this is a good idea). The last two are for consistency,
>> but not required for functionality. I have everything running as is now
>> except for RMS.
> 
> I haven't followed the discussions about this so closely. Would you mind
> telling me what it is that you way, then I could maybe whip up a module
> to do the calculations. Do we have some sort of equation(s)?
> 
>> v.digit: I don't think this will get done. Jachym's efforts have been
>> directed towards pyGTK. This is nice for the future, but doesn't help for
>> 6.2. Unless someone jumps into the breach soon, we should just accept that
>> you will need x11 (or QGIS) for digitizing for now.
> 
> Also v.edit would need some more doing. esp. the delete doesn't work, and
> I haven't had time to have a good look at it ): I'm also having strange
> problems with adding adjacent areas. if they are only N-S,E-W it's all
> good, but if not then I'd need to do some voodoo to make it work. why?
> 
> i.e. this works:
> +---+---+
> |   |   |
> +---+---+
> |   |   |
> +---+---+
> 
> This doesn't
>      +---+---+
>     /|  /|  /
>    +-+-+-+-+
>   /  |/  |/
> +---+---+
> 
> Can anyone give me a clue on what is going on?
> 
> --W
> 
> -- 
> 
> <:3 )---- Wolf Bergenheim ----( 8:>
>