[postgis-devel] corrected patch add precision reduction

[strk at refractions.net]

On Mon, Jan 03, 2005 at 01:17:30PM -0500, Carl Anderson wrote:
> 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')

I think a *valid* GEOMETRYCOLLECTION is cleaner then an *invalid*
MULTIPOLYGON. If you need a set of *clean* polygons you might
want a function taking a MULTIGEOMETRY (or Collection) and inserting
its elements into a table. Returning a set could also be done but
would not work for older postgresql. Also in this case we need to
define semantic of nested collection/multigeom: should the function
consume the whole geometry discarding the tree structure or just
'explode' the first level ?

> >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.

Some functions (since JTS-1.4) already do precision reduction internally.
Buffer() is such an example. I need to check whether all of them do.
If they do this is a GEOS port bug, if they don't I wonder why (this is
part of the Robustness issue introduced with JTS-1.4 ).
Maybe Martin (Davis) can give us a better overview of this.

--strk;

For standing up against patentability of software,

  Thank You, Poland!

Read the intervention:    http://kwiki.ffii.org/ConsPolon041221En
Send your thanks:         thankyoupoland.info
Read/do more:		  http://www.noepatents.org/