[GRASS-dev] i.points, i.vpoints now use G_parser()

[Hamish]

Glynn Clements wrote:

> > %.2f isn't very useful if you are registering a scan of a lat/lon
> > map (eg nautical chart). This has always been a pain in i.[v]points,
> > you only judge to include/exclude a point based on what lines are
> > colored red.
> > 
> > maybe a check?
> >   if(G_projection() == PROJECTION_LL)
> >      %.5f
> > 
> > or G_trim_decimal() ??
> 
> Seems reasonable enough.
> 
> What would be an appropriate precision for the reverse error (i.e. 
> distances in X-Y coordinates)?

XY is unitless so no answer for sure, but generally it will be pixels
of an imported image file with resolution=1, so 1.00 (or 1.000) would
probably be ok for that.


H:
>> 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>
G:
> Personally, I don't think that the confirmation will change much; the
> user will just habitually press Y every time.

I can only speak from experience. In the past, on a number of occasions,
I have picked up subtle errors during the confirmation step. If the
coordinate text is redrawn somewhere else on the display, trigging a
"brain refresh" of some kind, then even better.


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

how similar or dissimilar are the methods? If they are basically clones 
of the same thing but working in different directions then sure, merge
them. If the numerics are fundamentally different I think they should
stay separate.


H:
> Could you explain what you perceive the deficiencies to be in the
> current [imagery group] system?
G:
> Primarily inconsistency; almost every other GRASS module writes data
> only to the current mapset.

ok, can't argue with moving i.rectify to "pull" mode. but that doesn't
mean you should get rid of groups! in code

struct {
   char **maps;
   struct {
      char *location;
      char *mapset;
   } source
   struct {
      char *location;
      char *mapset;
   } target
   struct {
      double *x_source;
      double *y_source;
      double *x_target;
      double *y_target;
      int npoints;
   } GCPs
} group


All these fields are required. *You still need to save the to/from
projection info ("units") of GCPs*, regardless of if you are pulling or
pushing the data. I guess you could replace target loc+mapset with just
location if pulling (or perhaps even EPSG code/full proj_info).

But you still need POINTS, REF, TARGET info stored together somehow.
 

> [Does i.rectify actually bother to lock the current mapset before
> modifying it?]


imagery/i.rectify/target.c
    select_target_env();
    G__setenv ("LOCATION_NAME", location);
    stat = G__mapset_permissions(mapset);
    if (stat > 0)
    {
        G__setenv ("MAPSET", mapset);
        G_get_window (&target_window);
        select_current_env();
        return 1;
    }


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

I have no problems with having the rectify module to "pull" data.


> It might help if I understood exactly what a "group" is meant to be.

see above struct. Better: have a quick look through this CERL document
for the original authors' take:

http://grass.ibiblio.org/gdp/html_grass5/Postscript/imagery.ps

 I have put a PDF version here for easier reading:
http://bambi.otago.ac.nz/hamish/grass/grass_imagery_CERL.pdf

see section 10 (page 25). i.rectify is covered in section 13.

basically imported imagery will be at minimum split into R,G,B bands;
LANDSAT has 7 bands; newer sats have more. You only want to set GCPs
once for all images (bands) of the same group and rectify them together.
Sometimes there is just one band, but usually you have a "group" of
bands.


G:
>>> 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).
H:
>> um, define multiple groups?
G:
> 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.

you would need to redo the GCPs for each new location, and that is 95+%
of the work. "one-to-many locations" requires as many GCP sets as you
have target locations. There could be a method of just setting LL/WGS84
GCPs and then projecting the target GCP coordinates from LL to whatever.
I think in most cases images need to be projected only once. I am not
sure that this idea is acceptable for all projections though.

re "one-to-many": groups let you process many sibling maps in one
operation, "many-to-one".


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

I am not sure I follow, but an example use:

I have raw 300dpi color scans of all of our national nautical charts.
As needed I use r.in.tiff or r.in.gdal to load into a simple_xy
location, mapset=charts. Each chart is roughly s=0,w=0 to n=10000,
e=15000, res=1 pixel. Each chart is destined for WGS84 lat/lon target,
but will have its own set of GCPs. I load into i.points and start
marking GCPs where grid lines cross, then key in coordinates. Finally
i.rectify. So source and target mapset/locations are common in this
example, but the GCPs are different for each map.

I've another mapset for unrecified (but optically flat) ortho photos,
in this case I use i.vpoints to set GCPs with just the mouse and vector
coastline,road data from the target mapset.


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

see above. The settings need to be persistent on the disk. You need to
come back to them the next day or year, either to finish setting GCPs,
redo GCPs from a better target map, redo rectification, whatever...
current situation is ideal for this.


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

I really don't like mixing projections in the same location.
Plus you are left with the copying the map over, which (currently)
isn't easy to do for rasters.


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

For sub-groups this is just i.rectify with and without -a flag and
input=,,,, ? For random images see POINTS+TARGET+REF as one entity
arguments. I don't think i.group is much work; anyway the GUI could
streamline this so the user didn't have to bother with i.group and the
issue goes away.


M:
> and allow a POINTS file to be used with multiple raster and vector
> files.

It's a nice idea, but how often is this the case? only when you have a
chunk of data with consistent but unknown projection? I think major use
for a rectify module is a scanned raster map or something like
unrefenced DXF vector data. I'm all for parallel workflows though- the
user only has to learn one way of doing the task for all data types.


main points:
* POINTS+{SOURCE,TARGET}+RASTER_LIST are a unique set that need to travel
together.
* imagery groups are in fact useful and well thought out. fix bad bits
(pushing data) but don't throw it all out just because of a few flaws.
* a nice GUI could hide the clunky i.target,i.group parts while
preserving the overall usefulness. Best of both worlds.



Hamish