[GRASS-dev] Re: i.ortho.photo

GRASS GIS GRASS GIS developer
1

On Oct 22, 2008, at 1:03 AM, <grass-dev-request@lists.osgeo.org> <grass-dev-request@lists.osgeo.org > wrote:

Date: Wed, 22 Oct 2008 09:03:35 +0200
From: "Markus Neteler" <neteler@osgeo.org>
Subject: Re: [GRASS-dev] Re: i.ortho.photo
To: hamish_b@yahoo.com
Cc: GRASS developers list <grass-dev@lists.osgeo.org>
Message-ID:
  <86782b610810220003v15746773md766816f4e0172b9@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1

On Wed, Oct 22, 2008 at 8:05 AM, Hamish <hamish_b@yahoo.com> wrote:

I had thought about leaving i.ortho.photo/libes/ in trunk, as that has
some hope of being reused (ie all but ask_camera.c to be merged into
lib/imagery/).

From grass64/TODO:

A)
   - lib/imagery/: standard lib, in use (i.* except for i.points3, i.rectify3)
   - imagery/i.ortho.photo/libes/: standard lib, in use
(i.ortho.photo, photo.*)

I.points, i.points3, etc should be replaced by the wxPython rectification module that does interactive control point creation and maintenance. If features need to be added to make it work with i.orthophoto, they should probably go into an enhancement ticket to keep track of it.

Currently, both TclTk and wxPython rectification modules use i.rectify. IMHO, we should have one rectification module. IIRC, i.rectify3 has some enhanced features relative to i.rectify, but never was finished to a point that it was useable. Can we simply upgrade i.rectify or replace it with i.rectify3?

The main issues for this working with the GUI is to make sure that there is compatibility in the control points files it reads and the way it deals with locations/mapsets. Notably with respect to the latter, i.rectify assumes that you start in an xy location/mapset and rectify into a projected location/mapset. However, interactive control point creation/management works better if you start in a projected location/mapset and rectify from the xy location/mapset. This is the way that r.proj and v.proj work too. If there is to be work on i.rectify, I'd like to suggest that it be changed to work in this way (start in projected mapset and rectify from the xy mapset).

Michael

B)
   - lib/image3/: never finished improvement which integrated the
standard lib and
                  the ortho lib. Seems to provide also ortho rectification for
                  satellite data (i.points3, i.rectify3)

Possibly a lot is already done in lib/image3/ ?

Markus

2

On 22/10/08 17:25, Michael Barton wrote:

However, interactive control point creation/management works better if you start in a projected location/mapset and rectify from the xy location/mapset. This is the way that r.proj and v.proj work too. If there is to be work on i.rectify, I'd like to suggest that it be changed to work in this way (start in projected mapset and rectify from the xy mapset).

I don't know enough about the reasoning behind the original procedure, but maybe it can simply take from_location/mapset= and to_location/mapset= arguments which would allow for greater flexibility and probably make i.target obsolete ?

Moritz

3

On Oct 22, 2008, at 8:45 AM, Moritz Lennert wrote:

On 22/10/08 17:25, Michael Barton wrote:

However, interactive control point creation/management works better if you start in a projected location/mapset and rectify from the xy location/mapset. This is the way that r.proj and v.proj work too. If there is to be work on i.rectify, I'd like to suggest that it be changed to work in this way (start in projected mapset and rectify from the xy mapset).

I don't know enough about the reasoning behind the original procedure, but maybe it can simply take from_location/mapset= and to_location/mapset= arguments which would allow for greater flexibility and probably make i.target obsolete ?

I don't know the programming ins and outs of this, but it sure sounds like a great idea to me.

Michael