lr at pcorp.us
Fri Apr 16 09:43:49 PDT 2021
> >> How about just overloading the name ST_Force3DZ, ST_Force3DM cause
> >> that's essentially what you are doing here isn't it?
> No, no more overloading, that just makes things less clear.
[Regina Obe] Yah I figured you wouldn't go for that but thought I'd throw it
out there :)
> > How about ST_PopulateZ and ST_PopulateM ?
> I had originally thought something like that. I'm fine w/ those. I think I
> ST_CopyZ / ST_CopyM in my notes.
NOOO hate those. Populate reminds me too much of our management functions
populate_geometry and is many characters to type.
ST_Copy just feels wrong as it feels like both the source and target should
be the same family of thing.
> > Or even ST_SetZ and ST_SetM.
> Not feeling these ones.
> > For the latter we also have an open ticket requesting to extend the
> > functionality of ST_SetZ/ST_SetM to allow getting the Z/M values from
> > some other computation. In this case the computation would be
> > extracting the value from a Raster, if I Understand correctly.
I like ST_SetZ and ST_SetM the best. I think it more follows the other
function naming for setters like ST_SetPoint and friends
> > Or .. don't we have functions that "draw" a raster into a
> > "vector/geometry canvas" ? In that case we could have them accept a
> > non-empty canvas, to "draw into a pre-existing geometry", with some
> > draw operation (multiply/add/replace/subtract..).
> > I've some resemblance of implementing that kind of "drawing"
> > in the CHIP type times...
> > --strk;
[Regina Obe] We have a function that burns geometries into a raster - it's
called ST_SetValues -
Then there is ST_DumpAsPolygons which converts a raster to a set of geomvals
(geom, value). -
Paul's new function will largely replace the use of this function. Common
use case of this function was
And then use the val of the geomvals returned to reconstitute a new geometry
with Z/M (borrowed from the values)
More information about the postgis-devel