[postgis-devel] corrected patch add precision reduction
strk at refractions.net
strk at refractions.net
Tue Jan 4 11:44:33 PST 2005
On Tue, Jan 04, 2005 at 11:15:48AM -0500, Carl Anderson wrote:
> strk at refractions.net wrote:
> >>tually 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 ?
> while a geometry collection may be cleaner -- especially because using
> it dodges the need to enforce the assertions of a MultiPolygon.
> Geometry Collections are pretty much a dead end unless things like
> overlaps and contains get full support for GeometyCollections. The
> only value I see for GeometryCollections is as you are using it to pass
> a set of stuff around
I agree. I do see the need to remove the dead-end constraint though,
and an explode(<geometry>, <table>, [<schema>]) would do it, as
in that way you will be able to further inspect the contents
and reorganize it at your will (the table could have tree fields:
id, dept, geometry).
> Rethinking clean(). a function that enforces the assertions of each
> geometry type
> Point - no assertions, no action, return input
> MultiPoint -no assertions, no actions, return input
> LineString -- no assertions
> LinearRing - issimple and startpoint == endpoint
> Polygon - rings are linearrings that do not cross
> each polygon has one exteriorring
> Multipolygon - polygons may not overlap
> polygons may only intersect at a discrete number of points
> GeometryCollection - assertions for each member are enforced
> ( I may be mangling the assertions but this is a discussion of a concept )
Basically your clean() function tries to enforce validity of the
geometries. This is a non-simple task. I think the Java Conflation Suite
from VividSolution does it. Maybe we could port JCS either in GEOS itself
or in a separate package. What do Paul and Martin think about this ?
> polygon_garray() should return a group of polygons. because we are
> effectively asking
> "turn this stuff into polygons".
> I need a way to
> build a multipolygon from a group of polygons.
> already provided are ways to
> build a polygon from linestrings
> build a line from a set of points
> build a set of linestrings from a polygon
> why not complete the set and put a consistent wrapper around the lot
> cast ( g, 'LINESTRING')
We have force_collection() and multi() which up-cast geometries.
A cast() function could do both upcasts and downcasts with appropriate
checks, which would exclude validity checks...
Still I think that 'exploding' a geometry and then select contents for
other collections would give more control. We actually lack a way
to build multi() from simple geoms sets (collect() did this, but changed
with LWGEOM). I see these options:
1) multipolygon(geometry) - aggregate
multiline(geometry) - aggregate
multipoint(geometry) - aggregate
2) cast(geometry, class) - function
3) multi(geometry) - aggregate returning multi* or collection
I vote for the first, which togheter with collect() would complete
the multi-geoms construction means.
> >>>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.
> I'm altering XMLTester in GEOS to add WKBReader to help diagnose this.
> in my example difference(a,b) fails but difference(astexct(a),astext(b))
> usually succeeds
By 'fails' you mean throws an exception, don't you ?
> >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/
> >This message has been scanned for viruses and
> >dangerous content for Fulton County by DefendMail, and is
> >believed to be clean.
> 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.
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/
More information about the postgis-devel