Hamish wrote:
[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>
Personally, I don't think that the confirmation will change much; the
user will just habitually press Y every time.
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?
They all appear to derive from a common ancestor. I daresay that
individual versions will have changes which only apply to that version
(and anything which was cloned from it after the change was made).
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.
How about extending [rv].proj to support GCP-based transformations as
an alternative to those provided by proj? Or even building this into
the gproj library?
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?
Primarily inconsistency; almost every other GRASS module writes data
only to the current mapset. [Does i.rectify actually bother to lock
the current mapset before modifying it?]
It isn't beyond the realms of possibility that future changes will
make writing to a mapset other than the current one even more
problematic than it is at present.
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.
That isn't in dispute.
I see no reason why a $MAPSET/group/$GROUP/points file isn't
the perfect place for this.
It might help if I understood exactly what a "group" is meant to be. I
know what raster/vector maps are, what regions are etc, but I'm
unclear on what a group /is/ (if it is anything other than a saved
i.points/i.rectify "session").
> 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?
Which seems like a workaround for the fact that a one-to-one mapping
is being used for something which should arguably be a one-to-many
mapping. IOW, each group only provides one "slot" for GCPs, so you
have to clone the entire group just to get another slot.
> 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 !!?
Is there any advantage to that structure over having a separate
location for each group? If you have multiple groups in a single
location, what do they have in common?
The nature of a location is that everything within it shares a common
coordinate system, so it is meaningful to perform processes which
operate upon multiple maps within the same location.
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.
So, you're saying that a group is essentially a GCP file plus some
other data (e.g. a set of maps) tacked on?
The whole structure sounds like little more than a mechanism to bundle
various parameters together into a "current state".
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?
Both i.rectify and r.proj introduce sampling errors; two separate
steps will produce double the error of a single step.
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.
The GRASS database directory is supposed to be a database of
geospatial information, not a place for individual applications to
store their session files.
For a trivial program, you don't have to give much consideration to
how data is structured. As a system becomes more complex and provides
greater functionality, it becomes more important for data to be
structured correctly.
I'm not sure what benefit the concept of imagery groups provides
beyond that provided by locations. Maybe whoever came up with it
didn't have write permission on the database directory and couldn't
create new locations, so they decided to create a separate hierarchy
using the current mapset as a database directory?
If a group is essentially a collection of maps having the same
coordinate system, then it's just duplicating the location concept.
--
Glynn Clements <glynn@gclements.plus.com>
