[postgis-devel] corrected patch add precision reduction

[Carl Anderson]

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
404.730.8026


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