[postgis-devel] New polygon constructors (was: OGC polygon constructors)

[strk at refractions.net]

Ok, I wrapped polygonize_garray using algorithm suggested
by Carl Anderson to ensure valid output. We now have
tree more functions:

	- BuildArea(geometry)

	  Takes any geometry, extract linework and returns
	  either a Polygon or MultiPolygon depending on input.

	- BdPolyFromText(text, integer)
	- BdMPolyFromText(text, integer)

	  OGC standard functions, require MULTILINESTRING WKT
	  in input (will raise an exception otherwise).
	  The single-geom version will raise an exception
	  if a MultiPolygon is returned (they both calll
	  BuildArea internally)

So, what you'll be using is BuildArea(), but the OGC versions
are there to be standard compliant.

Regress test has been added for the tree functions.

--strk;

	

On Fri, Dec 09, 2005 at 10:46:19AM -0700, Charlie Savage wrote:
> I'd vote for wrapping polygonize_garray so that their is only one 
> implementation of the code.
> 
> Charlie
> 
> strk at refractions.net wrote:
> >On Fri, Dec 09, 2005 at 04:23:59PM +0100, strk at refractions.net wrote:
> >...
> >  
> >>Nonetheless, many items in the TODO list are completely missed:
> >>    
> >...
> >  
> >>- OGC polygon constructors
> >>    
> >
> >I'm approaching this. SFSQL 1.1 contains the following information
> >about these:
> >
> >  
> >> As an optional feature, an implementation may also support `building' of
> >> Polygon or MultiPolygon values given an arbitrary collection of possibly
> >> intersecting rings or closed LineString values.  Implementations that
> >> support this feature should include the following functions:
> >>
> >> BdPolyFromText(multiLineStringTaggedText String, SRID Integer): Polygon
> >>
> >>   Construct a Polygon given an arbitrary
> >>   collection of closed linestrings as a
> >>   MultiLineString text representation.
> >>
> >> BdMPolyFromText(multiLineStringTaggedText String, SRID Integer): 
> >> MultiPolygon
> >>
> >>   Construct a MultiPolygon given an
> >>   arbitrary collection of closed linestrings as a
> >>   MultiLineString text representation.
> >>    
> >
> >Given these specs I think we can avoid use of GEOS for the construction,
> >as the only required thing is to find out what is an hole and
> >what is a shell. C code for this is already present in the loader.
> >
> >The alternative would be using just a comple of wrappers
> >to the polygonize_garray() function.
> >
> >Thoughts ?
> >
> >--strk;
> >
> > /"\    ASCII Ribbon Campaign
> > \ /    Respect for low technology.
> >  X     Keep e-mail messages readable by any computer system.
> > / \    Keep it ASCII. 
> >
> >_______________________________________________
> >postgis-devel mailing list
> >postgis-devel at postgis.refractions.net
> >http://postgis.refractions.net/mailman/listinfo/postgis-devel
> >
> >
> >  



> _______________________________________________
> postgis-devel mailing list
> postgis-devel at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-devel


-- 

 /"\    ASCII Ribbon Campaign
 \ /    Respect for low technology.
  X     Keep e-mail messages readable by any computer system.
 / \    Keep it ASCII.