Thinking about raster alignment today, I thought it might be nice to have a "Raster View" object or "Raster Wrapper" object which could allow you to index a raster using a different raster's indices. Say you have two rasters which are offset by exactly three pixels in the x direction. Normally, to reference the pixel in which covers the same spot on the ground, in rasters A and B, you'd need to write<br>
<br>A[i+3, j] and B[i, j]<br><br>In this case, i & j are indices into B, and we're calculating the index of the corresponding pixel in A. This is exactly how mapalgebra currently handles the task.<br><br>What if we could "wrap" A in such a way that the wrapper itself remembered the translation?<br>
<br>C = RasterView(A, dest=B)<br>C[i, j] = A[i+3, j]<br><br>Potentially, the "offset calculator" in mapalgebra could be replaced with this wrapper code. It could also be used wherever rasters need to be aligned. The advantage of using this "index arithmetic" is that the rasters do not need to be resampled and stored somewhere. You would simply use the coordinates in the "result" raster to lookup data in all of the inputs. Ideally, the raster wrapper would behave exactly like a "regular" raster, except the indices are transformed before use.<br>
<br>Now here's the best part: scrounging through GDAL documentation, I found <br><br><a href="http://www.gdal.org/gdal__alg_8h.html#7671696d085085a0bfba3c3df9ffcc0a">http://www.gdal.org/gdal__alg_8h.html#7671696d085085a0bfba3c3df9ffcc0a</a><br>
<br><blockquote style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;" class="gmail_quote">void* GDALCreateGenImgProjTransformer()<br><p>
Create image to image transformer. 
</p><p>
This function creates a transformation object that maps from pixel/line 
coordinates on one image to pixel/line coordinates on another image. The
 images may potentially be georeferenced in different coordinate 
systems, and may used GCPs to map between their pixel/line coordinates 
and georeferenced coordinates (as opposed to the default assumption that
 their geotransform should be used).</p></blockquote><div>There are three different versions. The treatment seems quite general, and will handle different orientations and even different projections.<br><br>Could someone with more knowledge of PostGIS comment on the difficulty of creating a raster wrapper using the above described GDAL functions? Would we need another type in the database, or could we have two C implementations of the raster PostGIS type? <br>
<br>Bryce<br></div>