michael.barton at asu.edu
Sat Jun 24 11:58:37 EDT 2006
Do you (or anyone else reading this) know if v.transform will ignore a 5th
column in a points file (i.e., a use gcp column with a value of 0 or 1) or a
5th column will cause it to choke?
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University
> From: Glynn Clements <glynn at gclements.plus.com>
> Date: Sat, 24 Jun 2006 15:39:40 +0100
> To: Michael Barton <michael.barton at asu.edu>
> Cc: <rez at touchofmadness.com>, grass5 <grass-dev at grass.itc.it>, Maciek Sieczka
> <werchowyna at epf.pl>, Hamish <hamish_nospam at yahoo.com>
> Subject: Re: [GRASS-dev] lib/vask
> Michael Barton wrote:
>> 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.
> The rectification aspects of i.orpho.photo should probably remain
> separate. AFAIK, it's completely different to the other rectification
>>>>> 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.
> My guess is that the confirm/cancel thing is an artifact of using a
> Vask/XDRIVER GUI, where the application decides what the user can
> change and when. So if the user makes a mistake, the application has
> to offer them the option of and correcting it (re-starting the whole
> process form scratch isn't a sensible option).
> With a "real" (i.e. event-driven) UI, the user can normally change
> anything at any time. An undo option may still make sense; e.g. if you
> accidentally delete a GCP which took some time to place accurately,
> being able to press an undo button is preferable to having to do it
> all over again.
> Glynn Clements <glynn at gclements.plus.com>
More information about the grass-dev