Hi,
I just changed i.points and i.vpoints to use the parser, making them
into "normal" modules.
This means that, like r.digit, if you try and "Run" them from their GUI
windows you'll have problems. They need to be invoked in an xterm. I hope
the GUI experts have a solution.
Hamish
Hamish wrote:
I just changed i.points and i.vpoints to use the parser, making them
into "normal" modules.This means that, like r.digit, if you try and "Run" them from their GUI
windows you'll have problems. They need to be invoked in an xterm. I hope
the GUI experts have a solution.
The solution to all "needs an xterm" problems is to remove the code
which tries to interact with the user via stdin.
--
Glynn Clements <glynn@gclements.plus.com>
I've written a TclTk replacement to i.points and i.vpoints that is in the
CVS (look under the file menu). I just need some help from someone to do a
module that will let me calculate RMS error. There are some other bells and
whistles I can add, but the RMS error calculations are the main item at the
moment.
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: Hamish <hamish_nospam@yahoo.com>
Date: Sat, 17 Jun 2006 18:29:09 +1200
To: grass5 <grass-dev@grass.itc.it>
Subject: [GRASS-dev] i.points, i.vpoints now use G_parser()Hi,
I just changed i.points and i.vpoints to use the parser, making them
into "normal" modules.This means that, like r.digit, if you try and "Run" them from their GUI
windows you'll have problems. They need to be invoked in an xterm. I hope
the GUI experts have a solution.Hamish
Michael Barton wrote:
I've written a TclTk replacement to i.points and i.vpoints that is in the
CVS (look under the file menu). I just need some help from someone to do a
module that will let me calculate RMS error. There are some other bells and
whistles I can add, but the RMS error calculations are the main item at the
moment.
I can do that, if you can tell me how to get the GCPs.
--
Glynn Clements <glynn@gclements.plus.com>
They are in a POINTS file: 5 columns,
x,y,e(projected),n(projected),use(1/0).
I'll make the vector POINTS file the same.
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@gclements.plus.com>
Date: Sat, 24 Jun 2006 15:05:22 +0100
To: Michael Barton <michael.barton@asu.edu>
Cc: Hamish <hamish_nospam@yahoo.com>, grass5 <grass-dev@grass.itc.it>
Subject: Re: [GRASS-dev] i.points, i.vpoints now use G_parser()Michael Barton wrote:
I've written a TclTk replacement to i.points and i.vpoints that is in the
CVS (look under the file menu). I just need some help from someone to do a
module that will let me calculate RMS error. There are some other bells and
whistles I can add, but the RMS error calculations are the main item at the
moment.I can do that, if you can tell me how to get the GCPs.
--
Glynn Clements <glynn@gclements.plus.com>
Glynn Clements wrote:
> I've written a TclTk replacement to i.points and i.vpoints that is in the
> CVS (look under the file menu). I just need some help from someone to do a
> module that will let me calculate RMS error. There are some other bells and
> whistles I can add, but the RMS error calculations are the main item at the
> moment.I can do that, if you can tell me how to get the GCPs.
I've added g.transform. Currently:
1. It requires an imagery group (I avoided parsing the points file by
using I_get_control_points()).
2. It contains yet another copy of the CRS code.
3. I haven't tested it yet.
--
Glynn Clements <glynn@gclements.plus.com>
Thanks much. A couple of questions.
What information does it return and in what format?
Also, will it work with any POINTS file in a $GISBASE/group/[mapname]/
directory?
Finally, does it require the presence of a REF file too--or just needs a
POINTS file? I'm asking this so that I can have it working with vectors too.
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@gclements.plus.com>
Date: Sat, 24 Jun 2006 22:07:14 +0100
To: Michael Barton <michael.barton@asu.edu>, Hamish <hamish_nospam@yahoo.com>,
grass5 <grass-dev@grass.itc.it>
Subject: Re: [GRASS-dev] i.points, i.vpoints now use G_parser()Glynn Clements wrote:
I've written a TclTk replacement to i.points and i.vpoints that is in the
CVS (look under the file menu). I just need some help from someone to do a
module that will let me calculate RMS error. There are some other bells and
whistles I can add, but the RMS error calculations are the main item at the
moment.I can do that, if you can tell me how to get the GCPs.
I've added g.transform. Currently:
1. It requires an imagery group (I avoided parsing the points file by
using I_get_control_points()).2. It contains yet another copy of the CRS code.
3. I haven't tested it yet.
--
Glynn Clements <glynn@gclements.plus.com>
Michael Barton wrote:
Thanks much. A couple of questions.
What information does it return and in what format?
Number of active points: %d
Forward:
x[%d] = %.2f
y[%d] = %.2f
g[%d] = %.2f
RMS = %.2f
Reverse:
x[%d] = %.2f
y[%d] = %.2f
g[%d] = %.2f
RMS = %.2f
The "x[%d] = %.2f" etc indicates the index of the point with the
greatest x/y/diagonal error and the corresponding error value.
I can change the format or add certain additional information (e.g.
the error for every point) easily enough.
Also, will it work with any POINTS file in a $GISBASE/group/[mapname]/
directory?
I think so.
Finally, does it require the presence of a REF file too--or just needs a
POINTS file? I'm asking this so that I can have it working with vectors too.
I don't think so.
Actually, modifying it read a specific file is straightforward; I just
need to either take the code from v.transform and modify it to read
into a Control_Points structure, or modify I_read_control_points() to
allow 4-column data (if the data will always have 5 columns, I can
just use I_read_control_points() directly).
--
Glynn Clements <glynn@gclements.plus.com>
Glynn,
Thanks much. See below.
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@gclements.plus.com>
Date: Sun, 25 Jun 2006 11:19:47 +0100
To: Michael Barton <michael.barton@asu.edu>
Cc: Hamish <hamish_nospam@yahoo.com>, grass5 <grass-dev@grass.itc.it>
Subject: Re: [GRASS-dev] i.points, i.vpoints now use G_parser()Michael Barton wrote:
Thanks much. A couple of questions.
What information does it return and in what format?
Number of active points: %d
Forward:
x[%d] = %.2f
y[%d] = %.2f
g[%d] = %.2f
RMS = %.2f
Reverse:
x[%d] = %.2f
y[%d] = %.2f
g[%d] = %.2f
RMS = %.2fThe "x[%d] = %.2f" etc indicates the index of the point with the
greatest x/y/diagonal error and the corresponding error value.I can change the format or add certain additional information (e.g.
the error for every point) easily enough.
Is g[%d] the diagonal distance?
I'd prefer to see the values for each point.
Sorry for being dense, but does it return a string that includes newlines
like the following...
"Number of active points: 5\nForward:\nx = 999999.999\ny = 9999999.999\n..."
...or just the values like the following...
"5 999999.999 9999999.999..."
Also, will it work with any POINTS file in a $GISBASE/group/[mapname]/
directory?I think so.
Finally, does it require the presence of a REF file too--or just needs a
POINTS file? I'm asking this so that I can have it working with vectors too.I don't think so.
Actually, modifying it read a specific file is straightforward; I just
need to either take the code from v.transform and modify it to read
into a Control_Points structure, or modify I_read_control_points() to
allow 4-column data (if the data will always have 5 columns, I can
just use I_read_control_points() directly).
Since 5 columns isn't a problem for v.transform, I'll just make all points
files the same. The only difference for the vector one is that it will only
contain valid points (i.e., the last column will always be 1); raster points
files can have 1 or 0 in the last column (with RMS calculations only being
on the lines with a 1 in the last column)
Michael
Hi,
I am glad to see this is coming along so well. I am still fixing some
outstanding bugs in i.vpoints; I hope that is not seen as a dilution of
effort -- just bug fixes.
[g.transform]
> What information does it return and in what format?
Number of active points: %d
Forward:
x[%d] = %.2f
y[%d] = %.2f
g[%d] = %.2f
RMS = %.2f
%.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() ??
2. It contains yet another copy of the CRS code.
:-/
Hamish
Michael Barton wrote:
>> What information does it return and in what format?
>
> Number of active points: %d
> Forward:
> x[%d] = %.2f
> y[%d] = %.2f
> g[%d] = %.2f
> RMS = %.2f
> Reverse:
> x[%d] = %.2f
> y[%d] = %.2f
> g[%d] = %.2f
> RMS = %.2f
>
> The "x[%d] = %.2f" etc indicates the index of the point with the
> greatest x/y/diagonal error and the corresponding error value.
>
> I can change the format or add certain additional information (e.g.
> the error for every point) easily enough.Is g[%d] the diagonal distance?
Yes ("g" for "ground" distance).
I'd prefer to see the values for each point.
That's easy enough to generate. Do you need the disabled points as
well? Currently, the errors are only being computed for valid points.
Presumably disabled points shouldn't be included in the RMS error,
even if the individual errors are being displayed.
Sorry for being dense, but does it return a string that includes newlines
like the following..."Number of active points: 5\nForward:\nx = 999999.999\ny = 9999999.999\n..."
...or just the values like the following...
"5 999999.999 9999999.999..."
The format should be exactly as described above, except with the
%d/%.2f specifiers replaced with actual values.
I can change the format to whatever is easiest to process.
--
Glynn Clements <glynn@gclements.plus.com>
Hamish wrote:
> > What information does it return and in what format?
>
> Number of active points: %d
> Forward:
> x[%d] = %.2f
> y[%d] = %.2f
> g[%d] = %.2f
> RMS = %.2f%.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)
%.5for G_trim_decimal() ??
Seems reasonable enough.
What would be an appropriate precision for the reverse error (i.e.
distances in X-Y coordinates)?
--
Glynn Clements <glynn@gclements.plus.com>
From: Glynn Clements <glynn@gclements.plus.com>
Date: Mon, 26 Jun 2006 12:16:18 +0100
To: Michael Barton <michael.barton@asu.edu>
Cc: Hamish <hamish_nospam@yahoo.com>, grass5 <grass-dev@grass.itc.it>
Subject: Re: [GRASS-dev] i.points, i.vpoints now use G_parser()That's easy enough to generate. Do you need the disabled points as
well? Currently, the errors are only being computed for valid points.Presumably disabled points shouldn't be included in the RMS error,
even if the individual errors are being displayed.
The easiest to parse would be distance for each point. Calculating RMS is
pretty easy to do in TclTk if I have the projected disances.
Thinking about it, I all I really need is "g". I can put "g" in the proper
spot in the GCP management form and already have an algorithm to calculate
RMS for valid points only (sqrt(sumsq(g)/N)).
Probably the simplest would be for me to run g.transform each time the user
does a 'save' of points. This would recalculate g and total RMS.
How does that sound?
Sorry for being dense, but does it return a string that includes newlines
like the following..."Number of active points: 5\nForward:\nx = 999999.999\ny = 9999999.999\n..."
...or just the values like the following...
"5 999999.999 9999999.999..."
The format should be exactly as described above, except with the
%d/%.2f specifiers replaced with actual values.I can change the format to whatever is easiest to process.
After all that, it is sounding like the best way to go is simply to return a
string with the 'g' values separated by something easy to cut--newlines,
colons, etc.
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
For total RMS, do I simply combine forward and backward (i.e., like I have
twice as many points)? Or is it better to display separate forward and
backward RMS values? Same with displaying 'g' for individual points--just
display forward or display the average of forward and backward?
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@gclements.plus.com>
Date: Mon, 26 Jun 2006 12:19:03 +0100
To: Hamish <hamish_nospam@yahoo.com>
Cc: <michael.barton@asu.edu>, <grass-dev@grass.itc.it>
Subject: Re: [GRASS-dev] i.points, i.vpoints now use G_parser()Hamish wrote:
What information does it return and in what format?
Number of active points: %d
Forward:
x[%d] = %.2f
y[%d] = %.2f
g[%d] = %.2f
RMS = %.2f%.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)
%.5for G_trim_decimal() ??
Seems reasonable enough.
What would be an appropriate precision for the reverse error (i.e.
distances in X-Y coordinates)?--
Glynn Clements <glynn@gclements.plus.com>
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
Michael Barton wrote:
For total RMS, do I simply combine forward and backward (i.e., like I have
twice as many points)? Or is it better to display separate forward and
backward RMS values? Same with displaying 'g' for individual points--just
display forward or display the average of forward and backward?
Forward and backward errors will be in different coordinate systems,
so it isn't meaningful to compute an average (arithmetic mean).
For a projection which consists solely of translation, rotation and
uniform scaling, the forward and backward errors will be directly
proportional.
For projections with significant levels of distortion, the forward and
backward errors will differ depending upon the scale factor in the
direction of the displacement.
E.g. if you had an image of the whole earth, misplacing a GCP near the
horizon (where the surface is tangential to the view) would result in
a large forward error but a small backward error, while misplacing a
GCP in the centre (where the surface is perpendicular to the view)
would result in the forward and backward errors being roughly
proportional.
Also, bear in mind that rasters are projected using the reverse
transformation, while vectors use the forward transformation.
--
Glynn Clements <glynn@gclements.plus.com>
So I should display a forward RMS and a backward RMS.
For each point, should I just display a single error distance or try to
display reverse for raster and forward for vector?
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@gclements.plus.com>
Date: Tue, 27 Jun 2006 16:25:43 +0100
To: Michael Barton <michael.barton@asu.edu>
Cc: Hamish <hamish_nospam@yahoo.com>, <grass-dev@grass.itc.it>
Subject: Re: [GRASS-dev] i.points, i.vpoints now use G_parser()Michael Barton wrote:
For total RMS, do I simply combine forward and backward (i.e., like I have
twice as many points)? Or is it better to display separate forward and
backward RMS values? Same with displaying 'g' for individual points--just
display forward or display the average of forward and backward?Forward and backward errors will be in different coordinate systems,
so it isn't meaningful to compute an average (arithmetic mean).For a projection which consists solely of translation, rotation and
uniform scaling, the forward and backward errors will be directly
proportional.For projections with significant levels of distortion, the forward and
backward errors will differ depending upon the scale factor in the
direction of the displacement.E.g. if you had an image of the whole earth, misplacing a GCP near the
horizon (where the surface is tangential to the view) would result in
a large forward error but a small backward error, while misplacing a
GCP in the centre (where the surface is perpendicular to the view)
would result in the forward and backward errors being roughly
proportional.Also, bear in mind that rasters are projected using the reverse
transformation, while vectors use the forward transformation.--
Glynn Clements <glynn@gclements.plus.com>
Michael Barton wrote:
So I should display a forward RMS and a backward RMS.
For each point, should I just display a single error distance or try to
display reverse for raster and forward for vector?
I suspect that you should probably display both.
AFAICT, either of the two points in a GCP pair can be misplaced just
as easily. Also, when you are entering the control points, do you
actually know whether they are going to be used for transforming a
raster or a vector (or both)?
Maybe you could determine the size of the source and destination
regions, and convert the absolute errors to a proportion of the
region's size. That would allow you to sensibly compare forward and
backward errors.
--
Glynn Clements <glynn@gclements.plus.com>
From: Glynn Clements <glynn@gclements.plus.com>
Date: Wed, 28 Jun 2006 16:31:57 +0100
To: Michael Barton <michael.barton@asu.edu>
Cc: Hamish <hamish_nospam@yahoo.com>, <grass-dev@grass.itc.it>
Subject: Re: [GRASS-dev] i.points, i.vpoints now use G_parser()Michael Barton wrote:
So I should display a forward RMS and a backward RMS.
For each point, should I just display a single error distance or try to
display reverse for raster and forward for vector?I suspect that you should probably display both.
AFAICT, either of the two points in a GCP pair can be misplaced just
as easily. Also, when you are entering the control points, do you
actually know whether they are going to be used for transforming a
raster or a vector (or both)?Maybe you could determine the size of the source and destination
regions, and convert the absolute errors to a proportion of the
region's size. That would allow you to sensibly compare forward and
backward errors.
If I normalized them to percents (I'd better use a percent sign so as not to
confuse anyone), would this make sense to people? Or will people prefer to
see the distance in actual map units?
Michael
--
Glynn Clements <glynn@gclements.plus.com>
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics and Complexity
Arizona State University
phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton
Michael Barton wrote:
> Maybe you could determine the size of the source and destination
> regions, and convert the absolute errors to a proportion of the
> region's size. That would allow you to sensibly compare forward and
> backward errors.If I normalized them to percents (I'd better use a percent sign so as
not to confuse anyone), would this make sense to people? Or will
people prefer to see the distance in actual map units?
If the target units are known (meters) it is very useful to know what
the ground error is. more important than percentage I think.
Hamish