[postgis-devel] [PostGIS] #1174: [raster] C-level index-to-geocoordinate functions

[PostGIS]

#1174: [raster] C-level index-to-geocoordinate functions
-----------------------------+----------------------------------------------
  Reporter:  bnordgren       |       Owner:  pracine      
      Type:  enhancement     |      Status:  reopened     
  Priority:  medium          |   Milestone:  PostGIS 2.0.0
 Component:  postgis raster  |     Version:  1.5.X        
Resolution:                  |    Keywords:               
-----------------------------+----------------------------------------------

Comment(by bnordgren):

 Replying to [comment:4 dustymugs]:
 > Replying to [comment:3 bnordgren]:
 > > With respect, r7884 does two potentially important things differently:
 > Only the commented-out validation code generates the matrix inverse.  At
 minimum, the active code only calculates the denominator of the rearranged
 equation for division by zero.  That denominator could be cached...

 Ummmm. Take another look at
 http://mathworld.wolfram.com/MatrixInverse.html

 Calculating a disposable matrix inverse is exactly what you're doing.
 You're just not caching any of the coefficients...and you're mixing in the
 matrix-vector multiplication at the same time...If you prefer not to
 believe that you're calculating an inverse matrix, I can go with that too.

 My claim here is that if you did cache (or start computing) all six matrix
 coefficients for the inverse matrix, the forward equations are absolutely
 no different than the reverse equations. If you'll humor me by letting me
 count up the number of operations in your forward and reverse transforms:

 Forward transform totals:

  * 4 multiplies
  * 4 additions

 Reverse transform totals:

  * 6 multiplies
  * 2 divides
  * 7 subtractions

 Room for improvement (if you can reduce your reverse transformation to the
 same number of operations as the forward one) :
  * (8 mult+div - 4 mult) / 8 mult+div = 50%
  * (7 sub - 4 add) / 7 sub = 42%

 Now divides and multiplies take much longer than adds and subtracts, and
 you can cut those in half. Big bonus. On top of that, you'll remove nearly
 half of the adds/subtracts. Still good.

 If it was only going to happen once, not such a big deal. But again, it's
 per pixel. If an operation takes ten minutes with the current code, it'll
 take five (or less) after the code is reworked to compute/cache the
 inverse matrix.


 >
 > Neither geopoint_to_cell or cell_to_geopoint use GDAL.  "d" is just the
 denominator and processed prior to everything else just to test for
 divisiion by zero.

 Whoops. Missed the commented out bits.

-- 
Ticket URL: <http://trac.osgeo.org/postgis/ticket/1174#comment:5>
PostGIS <http://trac.osgeo.org/postgis/>
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.