<br><br><div class="gmail_quote">On Wed, Feb 1, 2012 at 10:20 AM, Sandro Santilli <span dir="ltr"><<a href="mailto:strk@keybit.net">strk@keybit.net</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">On Wed, Feb 01, 2012 at 12:01:11PM -0500, Pierre Racine wrote:<br>
> For sure being able to 'print' (or 'burn') a set of point of multipoint in a raster is interesting.<br>
<br>
</div>Yeah, but the step forward here is that the _value_ to burn-in would be<br>
embedded in the point-or-multipoint itself. Rather than burning a constant<br>
into the raster where the vector hits, you'd burn a value that the vector<br>
holds. For points it'd be straightforward, for lines might still do something<br>
smart like linearly interpolating, for polygons I can't imagine anything smart.<br><div class="HOEnZb"><div class="h5"></div></div></blockquote><div><br><br>More or less, you appear to be conceptualizing points with an "M" or "Z" component as a geometry-value-pair. The geometry consists of the x and y component; the value consists of the M or Z component. Note that the approach outlined above is fundamentally limited to a single band. (Maybe OK, depending on what you're doing.)<br>
<br>If I may neutrally observe (without drawing fire), ISO 19123 has covered this territory and has already come up with something smart for many different types of geometries, including points, lines, and surfaces/surface patches like polygons and tins. Even solids. On the downside, implementing their idea would require an additional data type, but on the upside, it's quite general. Postgis raster has a variant of the data type already implemented, and this may be applicable.<br>
<br>say you had a <br><br>typedef struct geomval_s { <br>  LWGEOM *geometry ; <br>  VALUE      *val ;<br>} geomval_t ; <br><br>where "VALUE" could represent the value in more than one band. You now have a data type which can express the value in each band, at each point in your "multipoint" geometry. You could either lump all of the points with the same value into a single multipoint geometry, or you could associate each point with its own value separately. Then you make an array of these geomval_t items to express the spatial distribution of observed values.<br>
<br>A little extra complication for a set of single-valued points, but now handling lines and polygons is simply a matter of putting the correct geometry type into the above geometry field. The same rules always apply: the value(s) is(are) associated with the geometry.<br>
<br>ISO19123 also separates representation (geomval_t) from interpretation (this set of geomval_t items should be interpolated thusly). So, while the simplest way to handle a line segment with a value would be to interpret the value(s) as being constant over the entire line segment, one could also interpolate linearly from one line segment's value to the next. But if you chose to interpolate, that would be a layer of interpretation on top of the raw data. Likewise, the simplest way to handle a polygon would be to hold the value(s) constant over the entire polygon.<br>
<br>Now the last observation: every Postgis table with a geometry and at least one numeric non-geometry column is a source of geomval_t information. Any such table could be used to rapidly load single or multiband information into a raster.<br>
<br>Bryce<br>PS:<br>This suggests a user visible API addition of <br><br>ST_DumpRasterAsGeomval(rast raster, cell_pt geometry OUT,  values array OUT)<br><br>and <br><br>ST_LoadRasterFromGeomval(rast raster, t_name text, pt_col text default "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></div></div>