[postgis-devel] Controlling GEOS PrecisionModel

[Carl Anderson]

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:
>
>	PrecisionModel(0.00001);
>
>This would teoretically *grid* every GEOS geometry
>(input and output)
>
>--strk;
>  
>

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
'
BEGIN
  return (translate(
           intersection(
                  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.

C.