<div dir="ltr">Thanks for your help, Pierre.  Some follow up questions or answers:<br><div><br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div class="im">

</div>Pixel selection is possible via three options:<br>
1) one raster ST_MapAlgebra<br>
2) ST_Reclass<br>
3) ST_DumpAsPolygons (with a where clause)<br></blockquote><div><br></div><div>OK, we will test the different approaches to see what works best/fastest.  When a query refers to multiple raster layers (e.g., select pixels with slope = x, elevation = y, landcover = z), I suppose you would use multiple calls to one-raster ST_MapAlgebra or a combination of one- and two-raster?  <br>
</div><div class="im"><br>
</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">It is possible to build a distance raster in the database. It is a slow operation. But if your data is kind of static you can do it outside. What do you want exactly? The nearest pixels to a rail?<br>
</blockquote><div><br>We
 are after a raster layer that has a distance via highway to the nearest railroad 
for each raster cell.  That way a user can query cells based on their 
own distance threshold of interest.  Looks like the best way is to precompute distance and
 conduct queries on this value.<br><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Try the new optimized callback map algebra:<br>
<a href="http://postgis.net/docs/manual-dev/RT_ST_MapAlgebra.html" target="_blank">http://postgis.net/docs/manual-dev/RT_ST_MapAlgebra.html</a><br>
You might have to upgrade as it was optimized very recently.<br></blockquote><div><br></div><div>Does this mean switch to PostGIS 2.1, or use the latest 2.0.3?<br><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Test needed. If the pixel selected do not involve all the tiles of a tiled raster you might gain a lot by tiling.<br></blockquote><div><br></div><div>Pixels of interest will likely be found across the spatial extent of the database.  And they will come in many small clusters.  So it sounds like having few tiles and sticking with rasters over vectors is the best way to go.  Currently we have no tiles.  Is this sensible?<br>
<br></div><div>All in all, it sounds like 'best practices' often depends on the idiosyncracies of the database.  Thanks for the outlining the possibilities.  We will start testing different approaches and will update the post with context and results as we go.  <br>
</div><div></div></div><br></div></div></div>