[postgis-devel] corrected patch add precision reduction

Carl Anderson carl.anderson at co.fulton.ga.us
Mon Jan 3 10:17:30 PST 2005

strk at refractions.net wrote:

>Carl, I feel that the 'filter' function should be done
>entirely inside postgis, with no GEOS involved.
>New postgis api contains an LWGEOM_EXPLODED structure
>with deserializer (exploder) and serializer which would
>make geometrytype-based filtering straightforward, w/out
>the need and cost of GEOS<->POSTGIS conversions.
I will try again in POSTGIS only.

>For the clean(geometry) it looks it basically calls
>polygonize() for a multipolygon geometry and does
>nothing for the others. Why not advertising the 'cleanup'
>feature of the polygonize() function and just call that
>one instead of adding a new one ?
actually I think that polygonize() should be the clean function.  but 
I'll need a way
to get to a MultiPolygon from a collection of polygons.  ?? 
cast(the_geom, 'MULTIPOLYGON')

>Finally the reduceprecision() call, and all the
>third-args-extensions. I don't think we should add
>a scale parameter to any function, or any geometry
>editor would apply for that [ eg. difference(g1, g2, computeBbox) ].
>The precisionreduction itself could again be implemented
>completely inside postgis, as it seems a pretty easy task, not
>requiring any noding or indexing.
My big test case seems to be a precision related issue. I was trying to 
build tools that would eliminate
excessive precision in the input geometries as a source of the problem.

Carl Anderson
GIS Manager Fulton County, Georgia
carl.anderson at co.fulton.ga.us

This message has been scanned for viruses and
dangerous content for Fulton County by DefendMail, and is
believed to be clean.

More information about the postgis-devel mailing list