[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
404.730.8026
-----------------------------------------------------
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