[GRASS-dev] lib/vask

Michael Barton michael.barton at asu.edu
Fri Jun 23 20:34:11 EDT 2006


Going through email after a week away. So I'm sure there will be more
commentary in later digests. But this is a good point to insert an answser.

See below

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: Brad Douglas <rez at touchofmadness.com>
> Reply-To: <rez at touchofmadness.com>
> Date: Tue, 20 Jun 2006 03:46:58 -0700
> To: Glynn Clements <glynn at gclements.plus.com>
> Cc: <werchowyna at epf.pl>, Hamish <hamish_nospam at yahoo.com>, grass5
> <grass-dev at grass.itc.it>
> Subject: Re: [GRASS-dev] lib/vask
> 
> On Tue, 2006-06-20 at 09:12 +0100, Glynn Clements wrote:
>> Hamish wrote:
>>>> The selection of GCPs should probably be integrated with Michael's
>>>> i.points replacement.
>>>> 
>>>> Is there any reason why other forms of interaction (other than visual
>>>> selection of coordinates) would be necessary?
>>> 
>>> 
>>> Beyond the mouse, keyboard entry is needed. e.g. set a GCP to where
>>> lat/lon grid lines meet by marking "+" spot and keying in coordinates,
>>> or getting GCPs coords by travelling to a landmark with a good GPS.
>> 
>> Are you referring to entering one point with the mouse and the
>> corresponding point as numerical coordinates? I can see why that would
>> need to be interactive. Can that not be integrated with the i.points
>> replacement?
> 
> Yes.  Yes, but might it have to be reimplemented for other modules?

Check the georectify TclTk module.

So far, I've done this and integrated i.points and i.vpoints (for use with
i.rectify), and as well as creating a points file for v.transform.

Markus just told me that elevation would be needed to fold in information
from i.ortho.photo. This is doable, but I don't know what the work flow is
into i.ortho.photo from there (i.e., not to i.rectify at the moment).

> 
>> Essentially, to what extent is it possible to separate the entry of
>> GCPs and other parameters from the actual rectification? Ideally, you
>> want to have as much code as possible in a non-interactive core, with
>> interaction limited to the outermost layer.
> 
> Getting GCPs is one step.  Rectification is another step (down the
> line).  I would also expect to be able to input GCPs via file, also,
> however rare it would be used.  I plan to implement the rectification
> with GDAL, so one way or another, I'll have to get the GCPs into their
> format.  The input and the "work" would be isolated.

Currently you can read GCP's from an ascii POINTS file for i.rectify and a
points file of any name for vectors. What makes most sense is to merge
formats for raster (i.points/i.vpoints/i.rectify) and vector (v.transform)
points files and their directory structures (currently in the /group
directory for raster and anywhere for  vector).

It would probably be a good idea to also fold in i.ortho.photo if it is not
too difficult.

Glynn has recommended using the GDAL library for rectification. Could we
fold all raster rectification--general purpose and aerial photo--into
i.rectify with appropriate options and flags? If so, we could add the
additional rectification methods Hamish mentioned in an earlier post.

> 
> How is v.digit going to be handled?  That has a similar situation.  If
> we move solely to a command driven methodology, we won't be able to
> digitize/edit [new] vector maps. :(

This is already working in an experimental form using a new v.edit module
and a pyGTK interface. Doesn't look like it will make it to TclTk, though,
unless someone else steps in to do an interface.

> 
>>> various [Confirm][Cancel] buttons are needed...
>> 
>> In most cases, it's preferable to execute operations without
>> confirmation and to provide an undo feature for dealing with mistakes.
> 
> Undo is definitely the way to go here.

I'm not sure what undo would mean for georectification. For GRASS, you
always create a new map with georectification. The original, unrectified,
map remains as it was. Same with the GCP file. So undo is kind of
meaningless. Same with confirm and cancel. If the new map doesn't look
right, just delete it, change the existing GCP's, applying them to original
map, and do it again.

Michael




More information about the grass-dev mailing list