[postgis-devel] Another idea to speedup raster value editing

[Bryce L Nordgren]

On Wed, Feb 1, 2012 at 10:20 AM, Sandro Santilli <strk at keybit.net> wrote:

> On Wed, Feb 01, 2012 at 12:01:11PM -0500, Pierre Racine wrote:
> > For sure being able to 'print' (or 'burn') a set of point of multipoint
> in a raster is interesting.
>
> Yeah, but the step forward here is that the _value_ to burn-in would be
> embedded in the point-or-multipoint itself. Rather than burning a constant
> into the raster where the vector hits, you'd burn a value that the vector
> holds. For points it'd be straightforward, for lines might still do
> something
> smart like linearly interpolating, for polygons I can't imagine anything
> smart.
>


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.)

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.

say you had a

typedef struct geomval_s {
  LWGEOM *geometry ;
  VALUE      *val ;
} geomval_t ;

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.

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.

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.

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.

Bryce
PS:
This suggests a user visible API addition of

ST_DumpRasterAsGeomval(rast raster, cell_pt geometry OUT,  values array OUT)

and

ST_LoadRasterFromGeomval(rast raster, t_name text, pt_col text default
"cell_pt", values array)

t_name = table name
pt_col   = name of column containing points
values = array of column names containing values to load into raster.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20120206/ec723a57/attachment.html>