Well, in the interest of full disclosure, as I interrogated the output from the pgsql approach, it appears to have failed (silently?) on some of the output-- so there are fewer input features vs. output, and in non-intuitive ways (loss of some large polygon features. In other words, it's faster at the cost of being incorrect. My apologies I didn't notice this before posting.
I'll re-run tonight with the native function and report back on functionality. One feature request I could see useful would be to have the ability to specify which topology problems to fix, and which to skip for performance reasons. Best, Steve Stephen Mather Geographic Information Systems (GIS) Manager (216) 635-3243 s...@clevelandmetroparks.com clevelandmetroparks.com -----Original Message----- From: Sandro Santilli [mailto:sandro.santi...@gmail.com] On Behalf Of 'Sandro Santilli' Sent: Tuesday, April 17, 2012 4:50 AM To: Stephen V. Mather Cc: 'PostGIS Users Discussion' Subject: Re: [postgis-users] ST_MakeValid On Mon, Apr 16, 2012 at 03:05:21PM -0400, Stephen V. Mather wrote: > > IIRC there's a difference with a multipolygon composed by two > > overlapping rectangles. > > Rereading, does ST_MakeValid also test for overlapping polygons? It handles those too, yes. Basically it nodes and polygonizes all boundaries of input polygons and then maximizes the vertices retained in output by toggling between interior and exterior at every boundary. When impossible, the line is retained as a linestring. --strk; ,------o-. | __/ | Delivering high quality PostGIS 2.0 ! | / 2.0 | http://strk.keybit.net - http://vizzuality.com `-o------' _______________________________________________ postgis-users mailing list postgis-users@postgis.refractions.net http://postgis.refractions.net/mailman/listinfo/postgis-users
