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

[Michael Barton]

Glynn and Hamish,

Here are a couple of possibly clarifying things and suggestions responding
to the various items below.

GROUP:
Just an list of raster maps that will be rectified by a single set of GCP's.
A group directory stores the ascii list of maps to be rectified (REF file),
the ascii file of GCP's to use (POINTS file), and an ascii file with the
mapset and location (TARGET file) that the maps will be rectified and
reprojected into.

If i.rectify (or r.rectify or g.rectify) could be made to work like
v.transform, v.proj, and r.proj (i.e., rectify INTO the current mapset),
then we could dispense with the target file.

A list of maps, raster or vector, to rectify at the same time and with the
same set of GCP's is handy. However, if i.rectify/r.rectify allowed you to
simply specify the GCP file to use, rather than entire group, then you could
use a single GCP file to rectify lots of different maps--or just a single
one--without having to first build the REF file.

So here's the suggestion. Just have a rectification algorithim (I'm liking
g.rectify better) look for a user specified POINTS file (like v.transform)
in a standard location (like i.rectify) in a source mapset and location
(specified like in v.proj and r.proj) and rectify into the current mapset.

One module would do both raster and vector, work in a manner consistent with
v.proj and r.proj, allow for alternate rectification algorithms, and allow a
POINTS file to be used with multiple raster and vector files.

How does this sound.

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 at gclements.plus.com>
> Date: Mon, 26 Jun 2006 13:41:32 +0100
> To: Hamish <hamish_nospam at yahoo.com>
> Cc: <michael.barton at asu.edu>, <grass-dev at grass.itc.it>
> Subject: Re: [GRASS-dev] lib/vask  [i.points replacement]
> 
> 
> 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 at gclements.plus.com>