[GRASS-dev] lib/vask [i.points replacement]

[Hamish]

[replies to multiple posts in the thread follow]

Glynn:
> My guess is that the confirm/cancel thing is an artifact of using a
> Vask/XDRIVER GUI, where the application decides what the user can
> change and when. So if the user makes a mistake, the application has
> to offer them the option of and correcting it (re-starting the whole
> process form scratch isn't a sensible option).

A confirm/cancel button is useful when input coordinates are from the
keyboard (exactitude). Placing points with the mouse isn't a problem-
you can see the error as long as the zoom hasn't changed.

A tooltip containing from,to coordinates on mouse-over a GCP might
help? But I stand by the need for a review & confirm step during tedious
keyboard data-entry sessions. Unless the typo is really bad you probably
won't eyeball a subtle error after hitting <enter>. 
x.xxxx<tab>y.yyyyy<enter>[ok? Y/n]<enter>

Random access {delete | disable} of GCPs is required. undo last action
would be nice.


Michael:
> Is the analyze function the same in i.points and i.vpoints? If not,
> what is the difference?

They differ quite a bit, i.vpoints is much more advanced.
[update to the latest CVS bug fixed version and have a look!]

i.vpoints analyze menu will let you change the transform order (updating
RMS calcs accordingly) and optionally delete GCPs as well as disable
them.

Also very importantly the i.vpoints analyze menu will let you test-
overlay a vector map on your source map so you can see what the result
will look like as-you-go. I don't think this is working currently, but
I think it's an easy fix so will try to get it going in the next days.

I don't have any experience with i.points3, i.points.auto, or
i.ortho.photo so I can't say how they differ. Only that some
rationalization of this functionality is long overdue, and I hope
Michael's new GUI can be that.


Glynn:
> Note that i.rectify and i.vpoints each have their own private copy of
> the CRS_ code, which is also the same code that GDAL uses for
> GDALGCPTransform() etc (alg/gdal_crs.c).

"same code" minus any bug fixes applied to the GDAL version?

> Should the imagery modules use GDAL directly, or should we add an
> interface in lib/imagery/georef.c?

use GDAL directly please. It will be better cared for.
see 
 https://intevation.de/rt/webrt?serial_num=3166
 https://intevation.de/rt/webrt?serial_num=3296
 https://intevation.de/rt/webrt?serial_num=2952


Michael:
> A question: is this a good point to add a flag to i.rectify to make it
> georeference INTO the current location/mapset,

I prefer a "i.rectify -r" flag to new parameters= or a new r.rectify
module.


Glynn:
> I wouldn't suggest using the group directory solely because that's
> where the imagery subsystem stores its state. The imagery subsystem is
> quite poorly designed in general, and shouldn't be copied just for
> convenience' sake.

FWIW, I think after you get used to it, it works very well for its
assigned task. And there is great value in maintaining consistency in
non-broken systems. Could you explain what you perceive the deficiencies
to be in the current system?


Glynn:
> E.g. the target/points information appears to be an artifact of the
> i.points/i.rectify workflow.

having GCP data in an easily parsable plain text file is highly
desirable. I see no reason why a $MAPSET/group/$GROUP/points file isn't
the perfect place for this.


Glynn:
> Apart from anything else, there doesn't appear to be any way to have
> multiple GCP files for a given location (so you could rectify to
> multiple locations).

um, define multiple groups?


Glynn:
> It would make more sense if either the GCP files were a separate type
> of entity (like e.g. regions), so you could use the same GCPs on
> multiple imagery groups (e.g. if you had images corresponding with the
> same view taken at different times),

this is just the concept of the "group" and "subgroup" restated !!?

see the GRASS 5 i.group man page. (much info didn't get ported
apparently)
 http://grass.ibiblio.org/grass53/manuals/html53_user/html/i.group.html

Adding maps to a new group is trival versus setting GCPs. Managing GCP
sets needs to be the core feature, not a tag-on file.

this should be updated and html-ized for GRASS 6:
 http://grass.ibiblio.org/grass53/manuals/html53_user/Postscript/imagery.ps

G:
> or could have different GCP files for the same imagery group(s) in
> different locations.

adding maps to the group isn't a hard task and could be easily scripted.

G:
> Or if you could store the projected coordinates in lat/lon then
> combine i.rectify with proj to rectify into any given location.

interesting. but in practice will the result be that much better than
the current i.rectify+r.proj way?


Glynn:
> Or you could just use a filename rather than assuming a specific
> location within the mapset directory.

why make it so fragile? This file is an in-between file between the
interactive GCP editor and the rectifying backend. There is no need to
make it custom file which will get scattered and lost.


Sorry if I sound a bit frustrated, but to me it seems that there is a
lot of reinventing the wheel v1.0 here with little additional benefit.
What is so broken about the imagery system to justify a major overhaul
which will leave us with the same feature set, "but different"? It
borders on not-built-here syndrome. I don't see a compelling need for
anything other than a new i.points GUI which includes some included tabs
that act as a frontend to i.target+i.group setting and a big red
"rectify" button which becomes active once all needed info is correctly
filled in.


regards,
Hamish