[postgis-devel] SnapToGrid and higher dimensions

[Alex Mayrhofer]

strk at refractions.net wrote:
> 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).

from the design point of view that would of course be the perfect solution - 
however, i personally know that dump/reload is always a hassle that i 
personally try to avoid.

I think you should note this, and introduce the SnapToGrid(geom, BOX4D) 
function when a dump/reload is needed for other stuff anyway.

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

In an abstract way, SnapToGrid has 3 parameters: a geometry to be snapped, a 
vector which defines offset, and another vector which defines a cell 
"diameter" (The BOX4D would of course be the perfect grid cell prototype). 
(actually, it could be reduced to one vector - which i tried using the 
LINESTRING stuff in my previous mail).

However, one could interpret a POINT as a vector spanning from the origin to 
the POINT, so another solution could be

SnapToGrid(geom, offsetvector_point, cellvector_point) - the example above 
would then look like:

SnapToGrid(geom, 'POINT(0 0)', 'POINT(2 2)');

(error conditions when dimensions do not match have to be defined, of course).

otoh, that would be confusing when changing to BOX4D, because "offset 1, 
size 2" would look like

SnapToGrid(geom, 'POINT(1 1)', 'POINT(2 2)');

while the BOX4D approach would look like

SnapToGrid(geom, '(1 1, 3 3)::BOX4D'); (note the difference in the second point)

because a BOX is described by it's corners while the vectors start from the 
origin. So, probably the best solution is to start with something like

SnapToGrid(geom, boxleftlowercorner, boxrightuppercorner);
SnapToGrid(geom, 'POINT(1 1)', POINT(3 3)'); (example from above)

and then (additionally) go to the BOX4D approach one a dump/reload is 
neccessary anyways. That would make the two versions look "similar", and not 
confuse because of origin-based offsets..

What do you think?

Alex