[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