[GRASS-dev] lib/vask

[Glynn Clements]

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 at gclements.plus.com>