[GRASS-dev] lib/vask

GRASS GIS GRASS GIS developer
1

Hello code warriors,

Yep...Bringing up a long-standing unresolved topic. :slight_smile:

Can we have some discussion about a replacement for lib/vask? This is
the library that handles input from the console (used extensively in 5.x
and is on its way out).

The "easiest" way to handle it is by passing in parameters via text
file, but is far from user-friendly. Some small portion of this can
also be resolved by adding options for G_parser().

In reality, I believe there needs to be something a little more advanced
that is transparent to whether it is being 'called' from the GUI or CLI.
I don't pretend to have any decent answers (I've never had to code for
both before), but maybe the group of us can come up with something
that's easy for users and developers alike to use without the pitfalls
of the current implementation.

Searching the archive, I see a fair amount of discussion about why not
to use V_*() functions, but no long-term solutions.

This is holding up many modules being ported to 6.x and I suspect it
will have impact on the GUI projects currently in development. I'd also
like to develop some module(s) for handling metadata, but I cannot
continue until I have some direction as to handling input/editing,
globally.

Suggestions?

--
Brad Douglas <rez touchofmadness com> KB8UYR
Address: 37.493,-121.924 / WGS84 National Map Corps #TNMC-3785

2

Brad Douglas wrote:

Hello code warriors,

Yep...Bringing up a long-standing unresolved topic. :slight_smile:

Can we have some discussion about a replacement for lib/vask? This is
the library that handles input from the console (used extensively in 5.x
and is on its way out).

The "easiest" way to handle it is by passing in parameters via text
file, but is far from user-friendly.

IMHO, it's probably more user-friendly than using vask. Most text
editors are simpler and more functional than vask forms. There's no
reason why you can't pre-create the text file with the field labels
and (optionally) default values.

The only real advantage of vask is that you can prevent some basic
errors, e.g. entering a value which is too long, entering a value
which isn't a valid integer, etc. Note that the validation is limited
to what is built into vask itself; the application can't perform its
own checks as fields are entered, as the entire input process is
handed off to the vask library until the user indicates completion
using Esc-Enter.

Some small portion of this can
also be resolved by adding options for G_parser().

In reality, I believe there needs to be something a little more advanced
that is transparent to whether it is being 'called' from the GUI or CLI.
I don't pretend to have any decent answers (I've never had to code for
both before), but maybe the group of us can come up with something
that's easy for users and developers alike to use without the pitfalls
of the current implementation.

Searching the archive, I see a fair amount of discussion about why not
to use V_*() functions, but no long-term solutions.

This is holding up many modules being ported to 6.x and I suspect it
will have impact on the GUI projects currently in development. I'd also
like to develop some module(s) for handling metadata, but I cannot
continue until I have some direction as to handling input/editing,
globally.

Suggestions?

First, let's look at what actually uses it:

grass=> SELECT DISTINCT object FROM obj_imp WHERE symbol ~ '^V_' ;
                                 object
-------------------------------------------------------------------------
imagery/i.ortho.photo/photo.camera/OBJ.i686-pc-linux-gnu/mod_cam_info.o
imagery/i.ortho.photo/photo.elev/OBJ.i686-pc-linux-gnu/ask_elev.o
imagery/i.ortho.photo/photo.elev/OBJ.i686-pc-linux-gnu/mod_elev.o
imagery/i.ortho.photo/photo.init/OBJ.i686-pc-linux-gnu/mod_info.o
imagery/i.ortho.photo/photo.rectify/OBJ.i686-pc-linux-gnu/ask_elev.o
imagery/i.ortho.photo/photo.rectify/OBJ.i686-pc-linux-gnu/ask_files.o
imagery/i.ortho.photo/photo.rectify/OBJ.i686-pc-linux-gnu/ask_files2.o
imagery/i.ortho.photo/photo.rectify/OBJ.i686-pc-linux-gnu/ask_wind.o
imagery/i.ortho.photo/photo.target/OBJ.i686-pc-linux-gnu/ask_target.o
lib/edit/OBJ.i686-pc-linux-gnu/edit_cats.o
lib/edit/OBJ.i686-pc-linux-gnu/edit_cellhd.o
lib/edit/OBJ.i686-pc-linux-gnu/edit_hist.o
lib/imagery/OBJ.i686-pc-linux-gnu/ask_bands.o
lib/imagery/OBJ.i686-pc-linux-gnu/ask_colors.o
lib/imagery/OBJ.i686-pc-linux-gnu/tape_info.o
lib/imagery/OBJ.i686-pc-linux-gnu/v_exec.o
lib/imagery/OBJ.i686-pc-linux-gnu/vask_group.o
lib/init/OBJ.i686-pc-linux-gnu/set_data.o
lib/vask/OBJ.i686-pc-linux-gnu/V_acc.o
lib/vask/OBJ.i686-pc-linux-gnu/V_call.o
lib/vask/OBJ.i686-pc-linux-gnu/V_clear.o
lib/vask/OBJ.i686-pc-linux-gnu/V_const.o
lib/vask/OBJ.i686-pc-linux-gnu/V_line.o
lib/vask/OBJ.i686-pc-linux-gnu/V_ques.o
raster/r.le/r.le.setup/OBJ.i686-pc-linux-gnu/ask_group.o
raster/r.support/modhead/OBJ.i686-pc-linux-gnu/ask_format.o
vector/v.transform/OBJ.i686-pc-linux-gnu/ask_trans.o
(27 rows)

IOW:
  i.orpho.photo
  r.le.setup
  v.transform
  etc/set_data
  etc/support/modhead
  lib/edit
  lib/imagery

Michael is already working on a v.transform replacement.

Both gis_set.tcl and the option of specifying the mapset directory on
the command line are available as alternatives to etc/set_data.

The etc/support/modhead program only uses it directly if you want to
change the format details for the [f]cell file, which should only be
necessary if the file is somehow broken (if it isn't, changing any of
those parameters will break it). There's no reason that can't be done
with a command-line module; the more useful feature of changing a
map's boundaries or resolution can already be done using r.region.

r.le.setup uses it for a single form which obtains 9 parameters; this
could be done with either a command-line tool or by editing a text
file.

lib/edit provides options to edit the cellhd, cats or history for a
map. This is used by set_data and etc/support/mod{head,cats,hist}
only. All of these could be implemented via editing a text file.

As for the parts of lib/imagery which use it:

grass=> SELECT * FROM obj_imp WHERE symbol ~ '^I_v?ask' ;
                             object | symbol
-----------------------------------------------------------------+--------------------------
imagery/i.class/OBJ.i686-pc-linux-gnu/ask_files.o | I_ask_signature_file_any
imagery/i.class/OBJ.i686-pc-linux-gnu/ask_files.o | I_ask_signature_file_old
imagery/i.class/OBJ.i686-pc-linux-gnu/ask_files.o | I_vask_subgroup_old
imagery/i.ortho.photo/menu/OBJ.i686-pc-linux-gnu/menu.o | I_ask_group_old
imagery/i.ortho.photo/photo.camera/OBJ.i686-pc-linux-gnu/main.o | I_ask_camera_any
imagery/i.points/OBJ.i686-pc-linux-gnu/main.o | I_ask_group_old
imagery/i.vpoints/OBJ.i686-pc-linux-gnu/main.o | I_ask_group_old
lib/imagery/OBJ.i686-pc-linux-gnu/ask_bands.o | I_ask_group_any
(8 rows)

Again, i.[v]points should be made redundant by Michael's current
project.

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?). Actually, that applies in large measure to the
whole "imagery" subsystem.

--
Glynn Clements <glynn@gclements.plus.com>

3

Important clarification. I've done a TclTk GUI wrapper for v.transform. I
haven't replaced it. I have replaced i.points and i.vpoints.

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: Glynn Clements <glynn@gclements.plus.com>
Date: Fri, 16 Jun 2006 07:55:22 +0100
To: <rez@touchofmadness.com>
Cc: GRASS Devel <grass5@grass.itc.it>
Subject: Re: [GRASS-dev] lib/vask

IOW:
i.orpho.photo
r.le.setup
v.transform
etc/set_data
etc/support/modhead
lib/edit
lib/imagery

Michael is already working on a v.transform replacement.

4

Michael Barton wrote:

> IOW:
> i.orpho.photo
> r.le.setup
> v.transform
> etc/set_data
> etc/support/modhead
> lib/edit
> lib/imagery
>
> Michael is already working on a v.transform replacement.

Important clarification. I've done a TclTk GUI wrapper for v.transform. I
haven't replaced it. I have replaced i.points and i.vpoints.

Good point.

OTOH, the use of vask by v.transform isn't critical; it's only used if
you don't supply either pointsfile= or -s.

For entering a table of points, any decent text editor will be better
than the vask option. Actually, even "ed" is probably better than the
vask option.

--
Glynn Clements <glynn@gclements.plus.com>

5

Well, the points file is being handled by the georectifier. So no need for
vask there.

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: Glynn Clements <glynn@gclements.plus.com>
Date: Fri, 16 Jun 2006 16:51:37 +0100
To: Michael Barton <michael.barton@asu.edu>
Cc: <rez@touchofmadness.com>, GRASS Devel <grass5@grass.itc.it>
Subject: Re: [GRASS-dev] lib/vask

Michael Barton wrote:

IOW:
i.orpho.photo
r.le.setup
v.transform
etc/set_data
etc/support/modhead
lib/edit
lib/imagery

Michael is already working on a v.transform replacement.

Important clarification. I've done a TclTk GUI wrapper for v.transform. I
haven't replaced it. I have replaced i.points and i.vpoints.

Good point.

OTOH, the use of vask by v.transform isn't critical; it's only used if
you don't supply either pointsfile= or -s.

For entering a table of points, any decent text editor will be better
than the vask option. Actually, even "ed" is probably better than the
vask option.

--
Glynn Clements <glynn@gclements.plus.com>

6

On Fri, 16 Jun 2006 07:55:22 +0100
Glynn Clements <glynn@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.

Maciek

------------------------------------------------------------------------
CIEP?E KRAJE - CIEP?E MORZA. Szukasz atrakcyjnego wypoczynku w przyst?pnej cenie, zapoznaj si? z nasz? ofert?.
ZAPRASZAMY

www.skarpatravel.pl

7

On Sat, 2006-06-17 at 12:04 +0200, Maciek Sieczka wrote:

On Fri, 16 Jun 2006 07:55:22 +0100
Glynn Clements <glynn@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

8

Brad Douglas 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.

Ok, if disposal is out of the question, it will need to be re-written
if vask is to be eliminated.

I believe i.ortho.photo will require input from one method or another.
I don't see it working without interactive input, either.

Could you explain why?

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.

You can't resolve it without re-writing the module.

This is probably a good example of why it's important to separate
functionality from interface.

--
Glynn Clements <glynn@gclements.plus.com>

9

On Sun, Jun 18, 2006 at 06:10:38AM +0100, Glynn Clements wrote:

Brad Douglas 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.

Ok, if disposal is out of the question, it will need to be re-written
if vask is to be eliminated.

I am also user of i.ortho.photo...

> I believe i.ortho.photo will require input from one method or another.
> I don't see it working without interactive input, either.

Could you explain why?

> 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.

You can't resolve it without re-writing the module.

This is probably a good example of why it's important to separate
functionality from interface.

Agreed.

The occasion of rewriting it could go along with the re-integration of the
GRASS 5's image3 library which offers ortho-recitifcation of LANDSAT to
some extent. Something like this:

Merge of image libraries:
  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.*)
  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)
  C)
    - merge of i.points, i.vpoints, i.points3, i.points.auto
    - merge of i.rectify and i.rectify3
    - addition of new resampling algorithms such as bilinear, cubic convolution
      (take from r.proj?)
    - add other warping methods (maybe thin splines from GDAL?)
    - implement/finish linewise ortho-rectification of satellite data (from image3)
    - remove lots of cloned code

Markus

10

On Sun, 2006-06-18 at 06:10 +0100, Glynn Clements wrote:

Ok, if disposal is out of the question, it will need to be re-written
if vask is to be eliminated.

> I believe i.ortho.photo will require input from one method or another.
> I don't see it working without interactive input, either.

Could you explain why?

It is sometimes the case that the imagery being rectified (warped) has
no GCPs (ground control points) and sometimes we have to resort to
visual inspection and selection of points between images to transform
them. It is also sometimes the case that we have to supplement supplied
GPCs (maybe only the corner and center points are provided) to yield
desired results. This makes heavy use of the primitive GUI (images in
subwindows, zooming, menus, etc).

> 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.

You can't resolve it without re-writing the module.

I expect that. I just want to do it only once. :slight_smile:

--
Brad Douglas <rez touchofmadness com> KB8UYR
Address: 37.493,-121.924 / WGS84 National Map Corps #TNMC-3785

11

Brad Douglas wrote:

> Ok, if disposal is out of the question, it will need to be re-written
> if vask is to be eliminated.
>
> > I believe i.ortho.photo will require input from one method or another.
> > I don't see it working without interactive input, either.
>
> Could you explain why?

It is sometimes the case that the imagery being rectified (warped) has
no GCPs (ground control points) and sometimes we have to resort to
visual inspection and selection of points between images to transform
them. It is also sometimes the case that we have to supplement supplied
GPCs (maybe only the corner and center points are provided) to yield
desired results. This makes heavy use of the primitive GUI (images in
subwindows, zooming, menus, etc).

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?

--
Glynn Clements <glynn@gclements.plus.com>

12

Glynn Clements 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.

various [Confirm][Cancel] buttons are needed...

or do you mean some sort of human interaction between the data entry
frontend and "the libraries" backend?

What "forms of interaction" did you have in mind?

slightly lost,
Hamish

13

Glynn Clements wrote on 06/19/2006 07:41 AM:

Brad Douglas wrote:

Ok, if disposal is out of the question, it will need to be re-written
if vask is to be eliminated.

I believe i.ortho.photo will require input from one method or another.
I don't see it working without interactive input, either.
       

Could you explain why?
     

It is sometimes the case that the imagery being rectified (warped) has
no GCPs (ground control points) and sometimes we have to resort to
visual inspection and selection of points between images to transform
them. It is also sometimes the case that we have to supplement supplied
GPCs (maybe only the corner and center points are provided) to yield
desired results. This makes heavy use of the primitive GUI (images in
subwindows, zooming, menus, etc).
   
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?

... not sure - maybe GCPs from GPS measurements in a CSV list?

Markus

14

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?

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.

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.

Confirmation should be reserved for cases where undo is either
impossible (e.g. permanent deletion of data or other irrevocable
actions) or impractical (e.g. if the operation will leave the
application unresponsive for an extended period).

Confirmation shouldn't be used solely because it's easier to implement
than undo.

--
Glynn Clements <glynn@gclements.plus.com>

15

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?

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.

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. :frowning:

> 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.

--
Brad Douglas <rez touchofmadness com> KB8UYR
Address: 37.493,-121.924 / WGS84 National Map Corps #TNMC-3785

16

Glynn:

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.

Yes.

Glynn:

> In most cases, it's preferable to execute operations without
> confirmation and to provide an undo feature for dealing with
> mistakes.

Brad:

Undo is definitely the way to go here.

For entering GCPs precision and exactitude are much more important than
speed. Each point needs to be carefully checked and double checked.
And, at the risk of using a bad cliche, checked again. "Review &
confirm" is desired here, as well as delete (any) GCP and disable (any)
GCP. "Undo last point" seems like the knitting nightmares my mother used
to have undoing the whole row trying to get back to that dropped stitch.

But this is just the data-entry frontend [i.points] and nothing to do
with the non-interactive rectifying process [i.rectify] which happens
sometime after the digitizing sessions are done.

The tricky & important interactive task is the warped vector (or sampled
raster 50% alpha'd) overlay as-you-go. In i.vpoints this is in the
analyze menu, the code for it is there, but it doesn't seem to draw for
me (you supposedly can pick order=1,2,3 for that too). Having this
feature working would be a huge plus for GRASS. Esp. if merged with the
experimental auto-GCP code into a single i.uber_points.

Hamish

17

Brad Douglas 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?

Why? Entering GCPs sounds like something which should be done by a
single tool rather than several similar tools. Any modules which use
GCPs should simply read GCP files created by that tool.

> 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.

Obviously the input step needs to be interactive, but the
rectification step shouldn't require interaction, right? Or am I
missing something?

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. :frowning:

v.digit is inherently interactive. It's essentially all input and no
processing, i.e. a data editor.

--
Glynn Clements <glynn@gclements.plus.com>

18

Hamish wrote:

> > In most cases, it's preferable to execute operations without
> > confirmation and to provide an undo feature for dealing with
> > mistakes.
Brad:
> Undo is definitely the way to go here.

For entering GCPs precision and exactitude are much more important than
speed. Each point needs to be carefully checked and double checked.
And, at the risk of using a bad cliche, checked again. "Review &
confirm" is desired here, as well as delete (any) GCP and disable (any)
GCP. "Undo last point" seems like the knitting nightmares my mother used
to have undoing the whole row trying to get back to that dropped stitch.

Being able to undo the last operation doesn't exclude the possibility
of modifying any previous input. Rather, you ought to be able to
change any operation at any time, not just the last operation.

To me, "confirmation" implies modality, i.e. the application decides
to force the user to accept or reject something at a specific point in
time.

The only time when confirmation should be necessary is if the
application is about to do something which cannot be undone or
subsequently modified (e.g. permanently discarding data); i.e. if it
is the user's "last chance".

Wherever possible, the user should always be able to change their
mind, even much later. E.g. if a point is wrong, the user should be
able to change or delete it at any time, not just immediately after
having entered it.

In that sense, an "undo" operation is primarily a short-cut. E.g. if
you accidentally delete a point, you could just re-enter it, but an
undo operation would be quicker. If it's likely that the user will
want to "delete" points for the purpose of conducting what-if trials,
the interface should allow points to be "marked as deleted" (and
subsequently unmarked, i.e. reinstated).

But this is just the data-entry frontend [i.points] and nothing to do
with the non-interactive rectifying process [i.rectify] which happens
sometime after the digitizing sessions are done.

Right. But my main question is whether the same structure can be
applied to i.orpho.photo.

The tricky & important interactive task is the warped vector (or sampled
raster 50% alpha'd) overlay as-you-go. In i.vpoints this is in the
analyze menu, the code for it is there, but it doesn't seem to draw for
me (you supposedly can pick order=1,2,3 for that too). Having this
feature working would be a huge plus for GRASS. Esp. if merged with the
experimental auto-GCP code into a single i.uber_points.

That requires that you can perform the transformation fast enough to
be useful for interactive purposes.

If you update after specific operations (e.g. a mouse click or
pressing return in a coordinate field), there probably wouldn't be
much difference between building the rectification code into the UI
program and having the UI execute and external transformation program.

OTOH, if you're talking about transforming in "real time" (e.g. during
mouse motion or dragging), then you really need a monolithic program
(for polynomial or rational transformations, you would probably want
to use OpenGL Beziér or NURBS operations).

--
Glynn Clements <glynn@gclements.plus.com>

19

Glynn wrote:

v.digit is inherently interactive. It's essentially all input and no
processing, i.e. a data editor.

well it has to update nodes color etc when a boundary is open/closed,
etc. That might take some processing, esp with a complex unclean vector
polygon. (if an island opens, multi centroids in larger area, ...?)

Hamish

20

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@touchofmadness.com>
Reply-To: <rez@touchofmadness.com>
Date: Sat, 17 Jun 2006 10:42:12 -0700
To: Maciek Sieczka <werchowyna@epf.pl>
Cc: Glynn Clements <glynn@gclements.plus.com>, <grass5@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@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