[GRASS-dev] lib/vask

[Michael Barton]

I.points/i.vpoints/i.rectify are general-purpose rectifying modules. Except
for calculating RMS error, I've replaced  them with a new TclTk
georectifier.

I.ortho.photo (AFAIK) is a special purpose georectifier for aerial photos.

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: Sat, 17 Jun 2006 10:42:12 -0700
> To: Maciek Sieczka <werchowyna at epf.pl>
> Cc: Glynn Clements <glynn at gclements.plus.com>, <grass5 at grass.itc.it>
> Subject: Re: [GRASS-dev] lib/vask
> 
> On Sat, 2006-06-17 at 12:04 +0200, Maciek Sieczka wrote:
>> On Fri, 16 Jun 2006 07:55:22 +0100
>> Glynn Clements <glynn at gclements.plus.com> wrote:
>> 
>>> i.orpho.photo is one of those "applications" for which the only
>>> sensible solution is a complete rewrite (or complete disposal; how
>>> important is it?)
>> 
>> Very. I don't know of any other FOSS tool than can can orthorectify
>> aerial photographs using an already existing DEM.
>> 
>> The only similar one is e-foto project, but their philosophy is a bit
>> different - DEM is created from stereo aerial photographs, then they
>> are orthorectified using that DEM.
>> 
>> Unique and good thing about i.orpho.photo is that you can orthorectify
>> even a single photo, or a set of photos which don't overlap enough to be
>> used for extracting DEM in e-foto or other photogrammetry software.
>> 
>> Please don't remove i.orpho.photo.
> 
> Agreed.  This module is extremely important to me.  If I can't rectify
> images, GRASS becomes somewhat unusable to me.  Most of the imagery
> commands are quite important to me.
> 
> I believe i.ortho.photo will require input from one method or another.
> I don't see it working without interactive input, either.  This is one
> of the other reasons I brought up the subject of lib/vask again.  I'm
> honestly stumped as to how to resolve this without rewriting the module
> as GRASS advances.
> 
> 
> -- 
> Brad Douglas <rez touchofmadness com>                      KB8UYR
> Address: 37.493,-121.924 / WGS84    National Map Corps #TNMC-3785
> 
>