#163: g.transform no longer calculating error for 2nd order transformation
------------------------------------+---------------------------------------
Reporter: cmbarton | Owner: grass-dev@lists.osgeo.org
Type: defect | Status: new
Priority: major | Milestone: 6.3.1
Component: default | Version: svn-develbranch6
Keywords: g.transform georectify |
------------------------------------+---------------------------------------
Sometime recently, g.transform stopped calculating forward and backward
error for 2nd order transformations. It simply returns 0's. 1st order
transformations still work fine AFAICT.
#163: g.transform no longer calculating error for 2nd order transformation
-----------------------+----------------------------------------------------
Reporter: cmbarton | Owner: grass-dev@lists.osgeo.org
Type: defect | Status: new
Priority: major | Milestone: 6.3.1
Component: default | Version: svn-develbranch6
Resolution: | Keywords: g.transform georectify
-----------------------+----------------------------------------------------
Comment (by martinl):
Replying to [ticket:163 cmbarton]:
> Sometime recently, g.transform stopped calculating forward and backward
error for 2nd order transformations. It simply returns 0's. 1st order
transformations still work fine AFAICT.
The 2nd order transformations requires at least 6 GCPs. Your input POINTS
file contains 6 points. Then forward/reverse error is 0.0's.
Yes. This has 6 points like it is supposed to. But the transformation
doesn't work. Doesn't work with more than 6 either.
Michael
On 6/17/08 3:44 AM, "GRASS GIS" <trac@osgeo.org> wrote:
#163: g.transform no longer calculating error for 2nd order transformation
-----------------------+----------------------------------------------------
Reporter: cmbarton | Owner: grass-dev@lists.osgeo.org
Type: defect | Status: new
Priority: major | Milestone: 6.3.1
Component: default | Version: svn-develbranch6
Resolution: | Keywords: g.transform georectify
-----------------------+----------------------------------------------------
Comment (by martinl):
Replying to [ticket:163 cmbarton]:
Sometime recently, g.transform stopped calculating forward and backward
error for 2nd order transformations. It simply returns 0's. 1st order
transformations still work fine AFAICT.
The 2nd order transformations requires at least 6 GCPs. Your input POINTS
file contains 6 points. Then forward/reverse error is 0.0's.
Martin
__________________________________________
Michael Barton, Professor of Anthropology
Director of Graduate Studies
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University
2008/6/17 Michael Barton <michael.barton@asu.edu>:
Michael
On 6/17/08 3:44 AM, "GRASS GIS" <trac@osgeo.org> wrote:
#163: g.transform no longer calculating error for 2nd order transformation
-----------------------+----------------------------------------------------
Reporter: cmbarton | Owner: grass-dev@lists.osgeo.org
Type: defect | Status: new
Priority: major | Milestone: 6.3.1
Component: default | Version: svn-develbranch6
Resolution: | Keywords: g.transform georectify
-----------------------+----------------------------------------------------
Comment (by martinl):
Replying to [ticket:163 cmbarton]:
Sometime recently, g.transform stopped calculating forward and backward
error for 2nd order transformations. It simply returns 0's. 1st order
transformations still work fine AFAICT.
The 2nd order transformations requires at least 6 GCPs. Your input POINTS
file contains 6 points. Then forward/reverse error is 0.0's.
Martin
__________________________________________
Michael Barton, Professor of Anthropology
Director of Graduate Studies
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University
I get what I would expect with min number of GPSs for the given order,
when I add some other GPSs to the points file I get non-zero fwd/rev
errors
I haven't tried this in a couple of weeks, but when I ran this with a
current build a free weeks ago, I only got 0's here. You are getting values,
but I got nothing.
I don't know if this is a function of something that is now fixed, or a
problem with the Mac.
Michael
Regards, Martin
2008/6/17 Michael Barton <michael.barton@asu.edu>:
Michael
On 6/17/08 3:44 AM, "GRASS GIS" <trac@osgeo.org> wrote:
#163: g.transform no longer calculating error for 2nd order transformation
-----------------------+----------------------------------------------------
Reporter: cmbarton | Owner: grass-dev@lists.osgeo.org
Type: defect | Status: new
Priority: major | Milestone: 6.3.1
Component: default | Version: svn-develbranch6
Resolution: | Keywords: g.transform georectify
-----------------------+----------------------------------------------------
Comment (by martinl):
Replying to [ticket:163 cmbarton]:
Sometime recently, g.transform stopped calculating forward and backward
error for 2nd order transformations. It simply returns 0's. 1st order
transformations still work fine AFAICT.
The 2nd order transformations requires at least 6 GCPs. Your input POINTS
file contains 6 points. Then forward/reverse error is 0.0's.
Martin
__________________________________________
Michael Barton, Professor of Anthropology
Director of Graduate Studies
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University
__________________________________________
Michael Barton, Professor of Anthropology
Director of Graduate Studies
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University
It turns out that 2nd order transformation need MORE than 6 points, not 6
points or more--at least in g.transform. There needs to be a change to the
help file about this (for g.transform if different from i.rectify, or for
i.rectify if in both). I've changed the information in the interactive
georectify modules for TclTk and wxPython. I'm closing this because it is
not really a bug (or at least I don't think so), but some misinformation
in the docs.
> It turns out that 2nd order transformation need MORE than 6 points, not
6 points
> or more
Not according to the i.rectify man page,
"The number of control points required for a selected order of
transformation (represented by n) is ((n + 1) * (n + 2) / 2) or 3, 6, and
10 respectively."
And imagery/i.vpoints/analyze.c's compute_transformation() which leads to
imagery/i.vpoints/crs.c's calccoef() function agrees. n >= 6.
The same code is reused by g.transform, I assume they are identical after
re-indent.
no idea about what the needs of backtransforming are. I assume they are
symetric with a forward transform.
No idea if any of this matters to the status this bug. Reopening as the
reason for closing it is invalid and the interactive georectify modules
now need to be reverted.
#163: g.transform no longer calculating error for 2nd order transformation
-----------------------+----------------------------------------------------
Reporter: cmbarton | Owner: grass-dev@lists.osgeo.org
Type: defect | Status: reopened
Priority: major | Milestone: 6.4.0
Component: default | Version: svn-develbranch6
Resolution: | Keywords: g.transform georectify
Platform: All | Cpu: Unspecified
-----------------------+----------------------------------------------------
Comment (by cmbarton):
Well, when I use exactly 6 GCP's the RMS values returned by g.transform
are 0, and i.rectify fails. If I use 7 GCP's, I get real values from
g.transform and i.rectify works.
So at present, in terms of how this functions, the i.rectify man page is
incorrect. I don't know if there is an error in the code or an error in
the description.
#163: g.transform no longer calculating error for 2nd order transformation
-----------------------+----------------------------------------------------
Reporter: cmbarton | Owner: grass-dev@lists.osgeo.org
Type: defect | Status: reopened
Priority: major | Milestone: 6.4.0
Component: default | Version: svn-develbranch6
Resolution: | Keywords: g.transform georectify
Platform: All | Cpu: Unspecified
-----------------------+----------------------------------------------------
Comment (by hamish):
Replying to [comment:4 cmbarton]:
> Well, when I use exactly 6 GCP's the RMS values returned by g.transform
are 0,
IIUC that is RMS *error* value is 0, not results. By specifying the
minumum number of points have you just fit a perfect surface to the
points, and so no error?
or is the actual fit bad?
you can interactively play with this with i.vpoints's analyse tool if you
like.
ISTR in photogrametry the standard fiducial marks needed are like:
{{{
+ +
+ +
+ +
}}}
which compensates for rotation, scale, skew, and lens fisheye.
(if that translates to this task geometrically..?)
> and i.rectify fails.
what is the error i.rectify gives?
> If I use 7 GCP's, I get real values from g.transform and i.rectify
works.
... but what if 0 rms error is real?
> So at present, in terms of how this functions, the i.rectify man page is
> incorrect. I don't know if there is an error in the code or an error in
the
> description.
Or consider the case that the error is not with i.rectify at all.
(sorry, I haven't tried the test data yet)
#163: g.transform no longer calculating error for 2nd order transformation
-----------------------+----------------------------------------------------
Reporter: cmbarton | Owner: grass-dev@lists.osgeo.org
Type: defect | Status: reopened
Priority: major | Milestone: 6.4.0
Component: default | Version: svn-develbranch6
Resolution: | Keywords: g.transform georectify
Platform: All | Cpu: Unspecified
-----------------------+----------------------------------------------------
Comment (by msieczka):
Replying to [comment:5 hamish]:
> Replying to [comment:4 cmbarton]:
> > Well, when I use exactly 6 GCP's the RMS values returned by
g.transform are 0,
>
> IIUC that is RMS *error* value is 0, not results. By specifying the
minumum number of points have you just fit a perfect surface to the
points, and so no error? or is the actual fit bad?
On GDAL API reference pages [1] it reads that "Note that 2nd order
requires at least 6 GCPs, and 3rd order requires at least 10 gcps". GDAL
uses the same algorithm as GRASS and this info is coherent with GRASS
manual.
AFAIK, for any transformation supported by i.rectify, adding an extra
point above the minimum lets the algorithm calculate residuals. If only
the very required number of points is provided, the transformation result
is still valid, but you don't know the RMS. Given that, g.transform should
return 0 with 6 values, but i.rectify should work. If it doesn't it's
strange.
#163: g.transform no longer calculating error for 2nd order transformation
-----------------------+----------------------------------------------------
Reporter: cmbarton | Owner: grass-dev@lists.osgeo.org
Type: defect | Status: reopened
Priority: major | Milestone: 6.4.0
Component: default | Version: svn-develbranch6
Resolution: | Keywords: g.transform georectify
Platform: All | Cpu: Unspecified
-----------------------+----------------------------------------------------
Comment (by martinl):
Replying to [comment:8 hamish]:
> > "''I've changed the information in the interactive georectify modules
for TclTk? and wxPython.''"
>
> has that been changed back to 3,6,10?
I don't remember reopening it, but don't think it was ever "fixed". There was some discussion about whether this is a "bug" or not. As I remember it, here is what happens. If you select 6 points for a 2nd order transform, you get 00's or bogus numbers for the RMA calculations. I think someone pointed out that because 6 is a minimum number, you should get 0's. This seems weird and not too useful. Also, at least a couple of people in my lab ended up with blank maps with exactly 6 points. If you use 7 or more points, all problems go away.
I took this to mean that what the docs *really* mean is that you must have *more* than 6 points for a 2nd order transformation. I changed the GUI accordingly and suggested that the docs be changed. Others have said that, no, you need *at least* 6 points, not more than 6 points.
I have not retested this, but AFAIK, there was no change to g.transform.
Michael
______________________________
C. Michael Barton, Professor of Anthropology
Director of Graduate Studies
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University
Tempe, AZ 85287-2402
USA
RMS error reports all 0 for 6 points in a 2nd order transformation. But the rectification happens OK. RMS values are reported for a 2nd order transformation with more than 6 points.
Michael
On Jan 16, 2009, at 6:39 PM, GRASS GIS wrote:
#163: g.transform no longer calculating error for 2nd order transformation
-----------------------+----------------------------------------------------
Reporter: cmbarton | Owner: grass-dev@lists.osgeo.org
Type: defect | Status: closed
Priority: major | Milestone: 6.4.0
Component: default | Version: svn-develbranch6
Resolution: fixed | Keywords: g.transform georectify
Platform: All | Cpu: Unspecified
-----------------------+----------------------------------------------------
Changes (by hamish):
RMS error reports all 0 for 6 points in a 2nd order
transformation. But the rectification happens OK. RMS values
are reported for a 2nd order transformation with more than 6
points.
right; when you have only the minimum number of points to describe the
transform you have no statistical power to determine how well that matches
the "ideal" transform described by a set containing many many well placed
control points.
once you start to add more points you can begin to see how noisy your GCP
placement is. Note that with a low "n" such as min+1 you can get a very
small RMS by chance, even if they're crap but happen to line up. As you
add enough extra points to get a meaningful RMS, the best obtainable RMS
you can achieve will asymptote to some smaller value but never reach 0.0
(due to limits GPS accuracy; width of line on map vs scale; etc)
With the RMS you are testing how well the points fit each other (as
described by a polynomial fn), not how well they fit reality. So RMS error
is an abstract thing which primarily just gives you confidence in your
digitization consistency, and AFAIU the back-transformed RMS gives you an
idea how much of a difference that error makes after the projection step.
** i.e. you should be georeferencing into a location/projection which is
the same as the original map scan, and not try e.g. to georeference a lat/
lon (plate carree) map directly into a projected location. **
Use [i.rectify] + r.proj as a two step process if the projection will
change.