[postgis-devel] SnapToGrid and higher dimensions

[strk at refractions.net]

On Fri, Dec 02, 2005 at 12:29:54PM +0100, Markus Schaber wrote:
> (Sorry, this mail was sent unfinished accidentally.)
> 
> Hi, Strk,
> 
> 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).
> 
> I agree with you that a BOX4D is not worth the effort, although I think
> it is possible to add a completely new datatype without dump/reload. No
> old data has to be migrated (because their storage format will not
> change), we only have a bunch of new new and some changed definitions.
> 
> > SnapToGrid(geometry input, point offset,
> >	float8 xsize, float8 ysize, [float8 zsize], [float8 msize]);
> 
> I think that this is a good solution. Sematically, it is a good decision
> to represent the offset by a Point.

I've implemented this, but dropped the optionality of higher dimension
cell sizes. If we want to provide defaults for sizes we'll end up
with conflics as in:

	SnapToGrid('POINT(9 11)', 10,           10);
	SnapToGrid('POINT(9 11)', 'POINT(0 0)', 10);

See if you can live with it. 
remember to run postgis_proc_upgrade.pl to enable this.
Also, rember to feed postgis_proc_upgrade.pl the name of schema in which
postgis is installed (or you might end up with duplicated functions)

--strk;

 /"\    ASCII Ribbon Campaign
 \ /    Respect for open standards
  X     No HTML/RTF in email
 / \    No M$ Word docs in email