The "Result Grid Iteration Engine".<br><br><a href="https://collab.firelab.org/software/projects/modisfire/wiki/Seamless_spatial_operations_architecture#Result-Grid-Iteration-Engine">https://collab.firelab.org/software/projects/modisfire/wiki/Seamless_spatial_operations_architecture#Result-Grid-Iteration-Engine</a><br>
<br>Finally, the top down design on my architecture wiki page meets the bottom up design in the code on ticket 1058 (<a href="http://trac.osgeo.org/postgis/ticket/1058">http://trac.osgeo.org/postgis/ticket/1058</a>). Note that the code is slightly outdated because I had better ideas of how to organize it (due in part to the exercise of writing the code in the first place). <br>
<br>Features:<br><ul><li>The raster iteration code is in one place.</li><li>Small pieces (extension points) come together in a large thing (iteration engine).</li><li>MapAlgebra can leverage this design simply by implementing a value computation extension point.<br>
</li><li>Speed performance advantage over SQL implementation (input and output rasters are only serialized/deserialized once, instead of once per pixel).</li></ul>The drawback, of course, is that it loads both input rasters and the output raster completely into memory at the same time (assuming they are all in-database rasters).<br>
<br>Bryce<br>PS: Mark, I have the postgis->lwgeom refactoring done on my laptop, but work won't let me connect it to the network. I'll upload when I get home.<br>