<br><br><div class="gmail_quote">On Mon, Feb 6, 2012 at 5:06 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">
<div class="im"><br>
> This suggests a user visible API addition of<br>
><br>
> ST_DumpRasterAsGeomval(rast raster, cell_pt geometry OUT,  values array<br>
> OUT)<br>
<br>
</div>How is this different from ST_DumpAsPolygons()? I agree that ST_DumpAsPolygonValues() would have been clearer...<br>
<div class="im"><br></div></blockquote><div><br>Well, the geometry column would contain points (cell centers), for one. Values is also an array instead of a scalar, making this a true raster operation instead of a single band operation.<br>
<br>With this call, you're working with pixels instead of the perimeter of aggregated clumps of pixels. That's vital when you start thinking multiband. Individual pixels can always have a unique combination of band values. Aggregations of pixels...well, in certain special cases where the bands are well correlated, I suppose it may work OK. But on real data, you'd end up with one polygon containing all the pixels having the value [12, 15] and another polygon for pixels having value [12, 22]...assuming you put in a lot of effort to implement a multiband DumpAsPolygons.<br>
 </div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="im">
> ST_LoadRasterFromGeomval(rast raster, t_name text, pt_col text default<br>
> "cell_pt", values array)<br>
><br>
> t_name = table name<br>
> pt_col   = name of column containing points<br>
> values = array of column names containing values to load into raster.<br>
<br>
</div>How is this different from the planned ST_UnionToRaster()? What do you do when two or more points fall into the same pixel?<br></blockquote><div><br>First question: it appears that ST_UnionToRaster: a] is not planned to operate on an existing raster; b] will apply the same value to every geometry; c] does not specify if it will even take "points", or what the outcome might be if you provided points.<br>
<br>Second question: do whatever is appropriate. If you're considering the pixels to be an area, then average the values within the pixel, or take the max, or the min, depending on what you're interested in. Or consider the array of geomvals to represent layers in "z order" (topmost layer wins). If two or more polygons fall within the same pixel, then weight the average by the area of each polygon. If you're considering the pixels to represent point samples, interpolate (krige, IDW, etc.). (And by "you", I don't mean the authors of the tool, I mean users.) In any case, these are all meant to outline the array of use cases which are likely to be common, support whatever subset is convenient.<br>
<br>But realize that by asking that second question, you have placed yourself squarely in "Coverage (ISO19123)" territory. Deciding what value to return at a point based on a set of geomvals is exactly what a coverage does. It may be worth your while to investigate their solution to this problem before rolling your own.<br>
</div></div>