michael.barton at asu.edu
Tue Feb 20 09:59:58 EST 2007
I haven't looked at i.ortho.photo for a long time, and so maybe I am just
forgetting. But I think that the primary graphics interaction is setting
ground control points, like in georectifying. If so, this is a quite
different task from digitizing, and one that is much easier to accomplish in
any GUI platform.
Digitizing means that you need to create/edit the geographic data in a GRASS
vector/raster file, and requires some sophisticated programming.
Setting GCP's, however, just means that you need to grab the xy coordinates
and the geographic coordinates of a spot on the display. No need to change
any geographic data files. Because it was necessary in the past to include
code for user/screen interaction in each module that required it, we have
various block of code for doing some aspects of this task (grabbing
coordinates of a spot clicked on a screen) in i.points, i.vpoints,
i.ortho.photo, d.rast.edit, various query modules, and possibly i.class
(depending on whether classification needs an actual vector map or not).
Grabbing point coordinates from the screen and doing something with them
(storing them as a GCP file, sending them to a query module, using them to
recode raster map values, etc) is probably most easily done in a GUI. For
example, the same code in the TclTk georectifier could be reused for all of
AFAICT, true digitizing only occurs in v.digit and maybe i.class for
vectors, and r.digit for rasters.
Hopefully, this can help make the task of moderizing and regularizing
interaction somewhat easier.
On 2/19/07 4:24 PM, "Hamish" <hamish_nospam at yahoo.com> wrote:
> I have never used the ortho photo modules, so I'm not really sure how
> compatible the needs are. I agree that it is silly to have a dozen
> duplicate digitizing modules.
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University
More information about the grass-dev