[geos-devel] ST_Snap

Sandro Santilli strk at keybit.net
Fri Mar 2 03:46:59 EST 2012

On Thu, Mar 01, 2012 at 05:08:26PM -0800, Martin Davis wrote:
> On 3/1/2012 9:48 AM, Sandro Santilli wrote:

> >But it's not easy to determine the grid size, which that paper
> >is based upon, right ? How close should a segment be to a node
> >in order to snap there ? In other words, how big is the hot pixel ?
> Data-dependent.  I think you need to let the user choose. 

I agree, it needs to be decided once and globally.

I've been thinking about the "expanding grid" idea and realized
you just _can't_ rely on it because if you have to compute a grid
based on ordinate values you can only do it _locally_ so you'd need
to recompute it for every intersection point (and scaling to the
origin to improve robustness would also change those "local" numbers
making it even harder to tell).

The alternative of computing "min_grid_size" based on each operation
is also broken because an operation performed on a long edge (insert
a long edge into the existing topology) will have to use a large grid
(the size of the biggest cell within the new edge extent) while a point
you may have added before would have used a smaller grid size so you'd
end up with different tolerances which would create hard or impossible
to manage situations (multiple candidate hotpixels to snap to).

> You should be able to get away with 10 digits of precision.

Yep, that's about the value my convoluted "find out min tolerance"
gives you. Could be 10 digits very much on the left of the decimal
digits too...

> >It'd surely be useful to let the user specify such grid (tolerance?)
> >when invoking GEOS functions.
> >
> >It's also interesting to note that the floating point number grid
> >is of variable size, with cells growing in size while moving away
> >from origin.
> Snap-rounding assumes a fixed-point coordinate system.  It's not
> going to be able to handle datasets with huge variation in scale.

If instructed by user about the cell size it wouldn't need to assume
anything, right ? That'd probably be the aim.


  |   __/  |    Delivering high quality PostGIS 2.0 !
  |  / 2.0 |    http://strk.keybit.net - http://vizzuality.com

More information about the geos-devel mailing list