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

--strk;

> 
> C.
> 
> >--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/
> >
> >-----------------------------------------------------
> >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
> 404.730.8026
> 
> 
> -----------------------------------------------------
> 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 mailing list