<br><br><div class="gmail_quote">On Wed, Jun 29, 2011 at 9:01 PM, Pierre Racine <span dir="ltr"><<a href="mailto:Pierre.Racine@sbf.ulaval.ca">Pierre.Racine@sbf.ulaval.ca</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
> You've hit on the point I was trying to make. A single row (or a single raster) is<br><div class="im">
> guaranteed to be rectangular, has no gap, no overlap and it is always<br>
> guaranteed that interlopers will fail to break my nice image. The standard way<br>
> to provide efficient I/O and memory management for these perfect rasters is to<br>
> provide the tiling services that people from a raster background have come to<br>
> expect.<br>
<br>
</div>At the price of not being able to support other tile arrangement.<br>
<div class="im"><br></div></blockquote><div><br>They're complementary, not conflicting.  I'm advocating a more efficient way to access information in an individual raster after the correct row has been located with the existing infrastructure.<br>
 </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">We could go further and provide fast subtile retrieving for big tiles but I'm not sure it is necessary to go that far.<br>
</blockquote><div><br>Exactly what I'm proposing, and that's exactly how it's complementary.  This provides not just increased speed, but increased memory efficiency too.<br> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
I would put this as a future refactoring/optimization of the rt_api internals. But you will first have to justify why storing small tiles does not fulfill your application needs.<br></blockquote><div><br>Ahh, so you're open to the possibility and wouldn't fight me if I wanted to fund this. :)<br>
</div><div class="h5"><br>
</div><br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">Hum no... Both ST_SetValue(newrast, 1, x, y, newval) are O(1) operations... Since every raster has its own georeference and you can easily derive the memory location of the requested pixel value in O(1). Take also into account the fact that those two rasters are already loaded.<br>
</blockquote><div><br>The index calculations are clearly O(1). DETOASTing and RETOASTING the entire raster are each O(N^2) operations, I presume, and this happens with every call to ST_SetValue()/ST_Value(). Unless I'm not understanding this toast thing. See Paul's msg: <br>
<br><a href="http://postgis.refractions.net/pipermail/postgis-devel/2011-June/013882.html">http://postgis.refractions.net/pipermail/postgis-devel/2011-June/013882.html</a><br><br><br></div></div>