[postgis-devel] Controlling GEOS PrecisionModel
carl.anderson at vadose.org
Wed Nov 9 17:37:25 PST 2005
strk at refractions.net wrote:
>[ included postgis-devel ]
>On Wed, Nov 09, 2005 at 11:35:59AM +0000, David Orme wrote:
>>Of course, I hadn't considered that I need to SnapToGrid the
>>geometries from the sequential unions rather than just the original
>>inputs so I'll try that.
>This won't be easy, maybe we should add a function to control
>precision of GEOS operations as a whole. Check out
>lwgeom_geos_wrapper.cpp and try to change the PrecisionModel
>constructor in initGEOS from the default to something like:
>This would teoretically *grid* every GEOS geometry
>(input and output)
If the objective of precision control is to keep precision "entropy"
from building up, you could write a stub function that consumes
precision on the left of the decimal point thereby limiting available
precision to the right of the decimal point. To really work the stub
would need to examine the incoming geometries to predict a sensible
value to shift so that real info was not lost. This is not an exact
precision limit but would not require
a global setting for the GEOS wrapper.
such a thing might look like, in a simple form ....
create function intersection ( geometry, geometry ) return geometry as
translate($1, 1024*1000, 1024*1000, 1024*1000),
translate($2, 1024*1000, 1024*1000, 1024*1000)
-1024*1000, -1024*1000, -1024*1000)
END;' language 'plpgsql';
better translating, a rescaling of the geometries would work better.
just my 2 cents.
More information about the postgis-devel