Details Ticket 3166


Comment | Reply | Take | Resolve


Serial Number 3166
Subject bad target region calculations with i.rectify order=3
Area grass6
Queue grass
Requestors hamish_nospam@yahoo.com
Owner none
Status open
Last User Contact Thu Nov 3 19:02:52 2005 (3 yr ago)
Current Priority 75
Final Priority 70
Due No date assigned
Last Action Thu Nov 3 19:02:52 2005 (3 yr ago)
Created Wed Apr 20 07:00:11 2005 (3 yr ago)

Transaction History Ticket 3166


Wed, Apr 20 2005 07:00:11    Request created by hbowman  
Subject: bad target region calculations with i.rectify order=3

Hi,

i.rectify (both 6.0.0, 6.1cvs) is creating rasters with incorrect regions and
resolutions when doing a 3rd order transform. It works fine with 1st or second
order transforms. 'i.rectify -c' (or lower order) is needed to get a good
transform.

Starting with unreferenced simple XY map (PNG imported with r.in.gdal)
and re-regioned to positive values with r.region, keeping res=1 pixel.

Target location is lat/lon (both wgs84 and none/intl datums fail)

e.g. eastern boundary ends up being +2 degrees east of what it should be,
resolution is calculated from e-w/cols so that ends up very coarse...
southern boundary is wrong too.

CRS_georef() in imagery/i.rectify/crs.c ?

more info available upon request.


thanks,
Hamish
Wed, Apr 20 2005 15:25:14    Mail sent by neteler@itc.it  
Return-Path <neteler@itc.it>
Delivered-To grass-bugs@lists.intevation.de
Date Wed, 20 Apr 2005 15:25:10 +0200
From Markus Neteler <neteler@itc.it>
To Request Tracker <grass-bugs@intevation.de>
Cc grass5@grass.itc.it
Subject Re: [GRASS5] [bug #3166] (grass) bad target region calculations with i.rectify order=3
Message-ID <20050420132510.GC8579@thuille.itc.it>
Mail-Followup-To Request Tracker <grass-bugs@intevation.de>, grass5@grass.itc.it
References <20050420050011.A14781005DD@lists.intevation.de>
Mime-Version 1.0
Content-Type text/plain; charset=us-ascii
Content-Disposition inline
In-Reply-To <20050420050011.A14781005DD@lists.intevation.de>
User-Agent Mutt/1.4.1i
X-Spam-Status No, hits=-4.9 tagged_above=-999.0 required=3.0 tests=BAYES_00
X-Spam-Level
On Wed, Apr 20, 2005 at 07:00:11AM +0200, Request Tracker wrote:
> this bug's URL: http://intevation.de/rt/webrt?serial_num=3166
> -------------------------------------------------------------------------
> 
> Subject: bad target region calculations with i.rectify order=3
> 
> Hi,
> 
> i.rectify (both 6.0.0, 6.1cvs) is creating rasters with incorrect regions and
> resolutions when doing a 3rd order transform. It works fine with 1st or second
> order transforms. 'i.rectify -c' (or lower order) is needed to get a good
> transform.
> 
> Starting with unreferenced simple XY map (PNG imported with r.in.gdal)
> and re-regioned to positive values with r.region, keeping res=1 pixel.
> 
> Target location is lat/lon (both wgs84 and none/intl datums fail)
> 
> e.g. eastern boundary ends up being +2 degrees east of what it should be,
> resolution is calculated from e-w/cols so that ends up very coarse...
> southern boundary is wrong too.
> 
> CRS_georef() in imagery/i.rectify/crs.c ?
> 
> more info available upon request.

Hamish,

you may compare with GDAL:

 gdal/alg/gdal_crs.c

- is the algorithm identical?
- does gdalwarp produce the same (error)

If GDAL performs better for above operation, its improvements
might be worth backporting.

Markus


Thu, Apr 21 2005 07:08:25    Mail sent by hamish_nospam@yahoo.com  
Return-Path <hamish_nospam@yahoo.com>
Delivered-To grass-bugs@lists.intevation.de
Date Thu, 21 Apr 2005 17:07:59 +1200
From Hamish <hamish_nospam@yahoo.com>
To Markus Neteler <neteler@itc.it>
Cc grass-bugs@intevation.de, grass5@grass.itc.it, Frank Warmerdam <fwarmerdam@gmail.com>
Subject Re: [bug #3166] (grass) bad target region calculations with i.rectify order=3
Message-Id <20050421170759.5736bfd7.hamish_nospam@yahoo.com>
In-Reply-To <20050420132510.GC8579@thuille.itc.it>
References <20050420050011.A14781005DD@lists.intevation.de> <20050420132510.GC8579@thuille.itc.it>
X-Mailer Sylpheed version 1.0.4 (GTK+ 1.2.10; i386-pc-linux-gnu)
X-Face M<EoB)"*Z~u!,vFhXmw}R_KbdBta*P_=T|rbBL'e1/CQ9;/1g\BU3&!=y8ria$2Uk!HT&BB 8i?|X_+7~1jsy}F~g$2va%3fV`*=L(*cem[@3\yg,G,@rg6/QMJ
Mime-Version 1.0
Content-Type multipart/mixed; boundary="Multipart=_Thu__21_Apr_2005_17_07_59_+1200_I1tsNuLxYLct+J3o"
X-Spam-Status No, hits=-4.0 tagged_above=-999.0 required=3.0 tests=BAYES_00, FORGED_YAHOO_RCVD
X-Spam-Level
This is a multi-part message in MIME format.

--Multipart=_Thu__21_Apr_2005_17_07_59_+1200_I1tsNuLxYLct+J3o
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

> > this bug's URL: http://intevation.de/rt/webrt?serial_num=3166
> > -------------------------------------------------------------------
> > 
> > Subject: bad target region calculations with i.rectify order=3

[1st and 2nd order work fine]

> > 
> > i.rectify (both 6.0.0, 6.1cvs) is creating rasters with incorrect
> > regions and resolutions when doing a 3rd order transform. It works
> > fine with 1st or second order transforms. 'i.rectify -c' (or lower
> > order) is needed to get a good transform.
> > 
> > Starting with unreferenced simple XY map (PNG imported with
> > r.in.gdal) and re-regioned to positive values with r.region, keeping
> > res=1 pixel.
> > 
> > Target location is lat/lon (both wgs84 and none/intl datums fail)
> > 
> > e.g. eastern boundary ends up being +2 degrees east of what it
> > should be, resolution is calculated from e-w/cols so that ends up
> > very coarse... southern boundary is wrong too.
> > 
> > CRS_georef() in imagery/i.rectify/crs.c ?
> > 
> > more info available upon request.
> 
> Hamish,
> 
> you may compare with GDAL:
> 
>  gdal/alg/gdal_crs.c

ok.
 
> - is the algorithm identical?

I think so.

The CRS_georef() fns are essentially the same (GRASS 6/GDAL 1.2.5).

I have cut the top off of both files to CRS_compute_georef_equations(),
diff -wi attached.. No difference there that I can see.

Note that Frank has some comments in his:

 * $Log: gdal_crs.c,v $

[gdal 1.2.6]
+ * Revision 1.8  2004/12/26 16:12:21  fwarmerdam
+ * thin plate spline support now implemented
+ *
[nice..]

 * Revision 1.7  2004/08/11 19:01:56  warmerda
 * default to 2nd order if we have enough points for 3rd order but 0 requested
*
 * Revision 1.6  2004/08/09 14:38:27  warmerda
 * added serialize/deserialize support for warpoptions and transformers
 *
 * Revision 1.5  2004/03/19 15:22:02  warmerda
 * Fixed double free of padfRasterX. Submitted by Scott Reynolds.
 *
 * Revision 1.4  2002/12/07 17:09:50  warmerda
 * re-enable 3rd order even though unstable
 *
 * Revision 1.3  2002/12/06 17:58:00  warmerda
 * fix a few bugs
 *
 * Revision 1.2  2002/12/05 05:46:08  warmerda
 * fixed linkage problem
 *
 * Revision 1.1  2002/12/05 05:43:23  warmerda
 * New


which tells us 3rd order is not stable...?

If we can get the inputs out, maybe we can try doing the matrix math
in Matlab/Octave and see what answers it gives... (polyfit() fn.)


> - does gdalwarp produce the same (error)

I am starting with a flat PNG(Tiff) image with no georefencing.
I assume you can use something in GDAL to insert GCPs as defined
in the GRASS group/POINTS file, but not the four corners of the 
map - that's where it all goes wrong in i.rectify.

So I don't know how to try gdalwarp on it.
?

 
> If GDAL performs better for above operation, its improvements
> might be worth backporting.

I think GDAL will have the same.
?


Hamish

--Multipart=_Thu__21_Apr_2005_17_07_59_+1200_I1tsNuLxYLct+J3o
Content-Type: text/plain;
 name="crs.diff"
Content-Disposition: attachment;
 filename="crs.diff"
Content-Transfer-Encoding: 7bit

--- irec_crs_crop.c	2005-04-21 16:50:03.000000000 +1200
+++ gdal_crs_crop.c	2005-04-21 16:48:10.000000000 +1200
@@ -4,8 +4,11 @@
 */
 /***************************************************************************/
-int 
-CRS_compute_georef_equations (struct Control_Points *cp, double E12[], double
N12[], double E21[], double N21[], int order)
+static int 
+CRS_compute_georef_equations (struct Control_Points *cp, 
+                                      double E12[], double N12[], 
+                                      double E21[], double N21[], 
+                                      int order)
   {
   double *tempptr;
   int status;
@@ -77,22 +80,22 @@
 
   /* INITIALIZE MATRIX */
 
-  m.v = (DOUBLE *)G_calloc(m.n*m.n,sizeof(DOUBLE));
+    m.v = (double *)CPLCalloc(m.n*m.n,sizeof(double));
   if(m.v == NULL)
     {
     return(MMEMERR);
     }
-  a = (DOUBLE *)G_calloc(m.n,sizeof(DOUBLE));
+    a = (double *)CPLCalloc(m.n,sizeof(double));
   if(a == NULL)
     {
-    G_free((char *)m.v);
+        CPLFree((char *)m.v);
     return(MMEMERR);
     }
-  b = (DOUBLE *)G_calloc(m.n,sizeof(DOUBLE));
+    b = (double *)CPLCalloc(m.n,sizeof(double));
   if(b == NULL)
     {
-    G_free((char *)m.v);
-    G_free((char *)a);
+        CPLFree((char *)m.v);
+        CPLFree((char *)a);
     return(MMEMERR);
     }
 
@@ -101,9 +104,9 @@
   else
     status = calcls(cp,&m,a,b,E,N);
 
-  G_free((char *)m.v);
-  G_free((char *)a);
-  G_free((char *)b);
+    CPLFree((char *)m.v);
+    CPLFree((char *)a);
+    CPLFree((char *)b);
 
   return(status);
   }

--Multipart=_Thu__21_Apr_2005_17_07_59_+1200_I1tsNuLxYLct+J3o--


Thu, Nov 3 2005 19:02:52    Mail sent by bernhard  
Hamish: 
 
Did you ask Frank W. about his comment? 
You could also add debugging output to see the values 
so you can run another tool to compare. 
 
 
Comment | Reply | Take | Resolve

You are currently authenticated as guest.
[Show Configuration] [Login as another user]

Users Guide - Mail Commands - Homepage of RequestTracker 1.0.7 - list any request