mtnclimb at gmail.com
Fri Apr 16 10:48:09 PDT 2021
I'm liking ST_SetZ and ST_SetM.
- nice and concise
- indicates that the geometry is being mutated
- removes one function parameter (I can't see a need to
programmatically choose between setting Z and M, but if that need arises
can always add a function)
- as Regina said, there is a ticket to create ST_SetZ/M already (
https://trac.osgeo.org/postgis/ticket/3959), and this harmonizes nicely
with that (hard to believe we don't already have these!)
On Fri, Apr 16, 2021 at 2:02 AM Sandro Santilli <strk at kbt.io> wrote:
> On Fri, Apr 16, 2021 at 01:08:44AM -0400, Regina Obe wrote:
> > > Sent: Friday, April 16, 2021 1:03 AM
> > > To: 'PostGIS Development Discussion' <postgis-devel at lists.osgeo.org>
> > > Subject: RE: [postgis-devel] ST_GetValues()
> > >
> > > > And building on that, ST_GetValues() which reads values from a raster
> > > > into the Z or M coordinates of a reference geometry.
> > How about just overloading the name ST_Force3DZ, ST_Force3DM cause that's
> > essentially what you are doing here isn't it?
> How about ST_PopulateZ and ST_PopulateM ?
> Or even ST_SetZ and ST_SetM.
> 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.
> 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...
> postgis-devel mailing list
> postgis-devel at lists.osgeo.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the postgis-devel