[postgis-devel] [PostGIS] #1806: Extremely slow and CPU-intensive ST_MakeValid (ST_BuildArea) case

[PostGIS]

#1806: Extremely slow and CPU-intensive ST_MakeValid (ST_BuildArea) case
----------------------+-----------------------------------------------------
  Reporter:  strk     |       Owner:  strk         
      Type:  defect   |      Status:  closed       
  Priority:  high     |   Milestone:  PostGIS 2.0.1
 Component:  postgis  |     Version:  2.0.x        
Resolution:  fixed    |    Keywords:               
----------------------+-----------------------------------------------------

Comment(by aperi2007):

 Replying to [comment:15 hugoledoux]:
 > We have designed and implemented a different algorithm to automatically
 repair polygons, it avoids the 4000+ overlay operations mentioned for this
 polygon (behaviour is not quadratic like ST_MakeValid). The code is not in
 PostGIS though, but can be obtained there: http://tudelft-
 gist.github.com/prepair/
 > For this polygon, it takes ~3s on my laptop.

 Hi,
 I see the sample in your link:
 http://tudelft-gist.github.com/prepair/

 I don't understand why the starting polygon is invalid.
 However starting from a hypotetical invalid polygon.
 I guess it's solution should don't break it's typology if possible.

 So if the starting geometry is a polygon with a hole, the result after the
 makevalid should still be (if possible) a polygon with a hole it should
 try to don't be another kind of geometry (a multipolygon) neither it
 should be an increase on the record number so it should not return two
 polygons (2 records) to substitute one polygon (one record).

 Otherwise the MakeValid could not be usable really because it need to see
 one by one all the change to do to every geometry before apply it to the
 starting table.

-- 
Ticket URL: <http://trac.osgeo.org/postgis/ticket/1806#comment:17>
PostGIS <http://trac.osgeo.org/postgis/>
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.