[postgis-devel] SnapToGrid higher dimensions (was: measures test fail)

[Nicklas Avén]

well, problem and problem.

I think most people expect when they do what you did in r6083
http://trac.osgeo.org/postgis/changeset/6083 that also z will be
snapped. Of course we can not always meet peoples expectations, but when
it is possible it makes the software very much more easy to use. All
remembering of special rules for special functions makes things more
difficult. From that perspective, when everything in the code is
prepared for z and m snapping except the part in LWGEOM_snaptogrid where
z and m grid values are set to 0, I thought it would have been nice to
get all dimensions snapped when writing ST_SnapToGrid(the_geom, 0.01)

I think your suggestion is quite appealing, eventually with just a
special case for the example ST_SnapToGrid(the_geom, 0.01), since I
think that is the most common usage and that wouldn't conflict with
anything in overloading the function.

/Nicklas







On Mon, 2010-10-25 at 08:54 +0200, strk wrote:
> On Sun, Oct 24, 2010 at 04:53:33PM +0200, Nicklas Avén wrote:
> > It seems like m and z snapping is implemented  at the "version 4" (in
> > doc) of the function, when a point is used to define the origin of the
> > grid cell. Bu tin the more common ST_Snaptogrid(geometry, size_of_grid)
> > there is no snapping to m and z.
> 
> Uhm.. since it's possible with "version 4" I really don't see the problem.
> Eventually, if we want to clean up the interface further we might have:
> 
> ST_SnapToGrid(<input>, <size> [, <offset>])
> 
> Where both <size> and <offset> are points.
> 
> --strk;
> 
>   ()   Free GIS & Flash consultant/developer
>   /\   http://strk.keybit.net/services.html
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>