[postgis-devel] SnapToGrid and higher dimensions
strk at refractions.net
strk at refractions.net
Fri Dec 2 00:52:29 PST 2005
On Thu, Dec 01, 2005 at 08:35:46PM +0100, Alex Mayrhofer wrote:
> strk at refractions.net wrote:
> >Suggestions ?
>
> What about silently adding 3/4D support to the simple
>
> SnapToGrid(geom, size)
>
> function, and provide new functions like
>
> SnapToGrid3D(...)
> SnapToGrid4D(...)
>
> for the versions with different sizes? Not a perfect solution, but would
> continue the "area2d" etc. naming scheme...
SnapToGrid3DZ() and SnapToGrid3DM() ...
> Another solution would be to provide a
>
> SnapToGrid(geometry, geometry)
>
> function, where the first geometry would be the one to be snapped, and the
> second one a LINESTRING(xoffset yoffset zoffset moffset, xsize, ysize,
> zsize, msize) which gives grid offsets and size...
>
> Not a nice solution, too, but easily to be distinguished from the other
> versions...
I don't like to use geometries to encode offset+size.
A BOX4D type could do, representing grid cell prototype.
Unfortunately adding a new type would require users to dump/reload
to upgrade to postgis 1.1.0 (currenlty unneeded).
A compromise would be using a POINT for offset and keep subsequent
args for sizes:
SnapToGrid(geometry input, point offset, float8 size);
SnapToGrid(geometry input, point offset,
float8 xsize, float8 ysize, [float8 zsize], [float8 msize]);
Then, our SnapToGrid(geometry, 2) would be equivalent to:
SnapToGrid(geometry, 'POINT(0 0)', 2, 2)
Missing dimensions in the POINT offset would be considered to be 0.
What do you think ?
--strk;
More information about the postgis-devel
mailing list