[postgis-devel] SnapToGrid and higher dimensions
axelm-postgis at nona.net
Fri Dec 2 03:15:40 PST 2005
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?
More information about the postgis-devel