Stephen,

Do you have a final timing from your ST_MakeValid test?  The numbers you show indicate about a 2.5:1 decrease in performance.  This could easily be explained by an extra overlay or validity test or two. 

This isn't to say that there wouldn't be a possibility to improve the performance of the ST_MakeValid code, but (speaking as someone who has spent way too much time tweaking spatial algorithms for performance) this may or may not be an easy/obvious fix.

Also, it would be helpful to know if this is a systematic difference in performance, or whether there are big differences for specific geometry cases.  This unfortunately will take a bit of effort to isolate - you'd probably have to run many tests on single geometries to capture the performance difference.

And sad to say, even if there is an obvious large difference only in specific cases, this doesn't necessarily mean that it's easy to improve the performance in just those cases.  One of the annoying things about spatial algorithms is that it's often very difficult to detect particular simple cases which can be computed quickly - at least, not any faster than the full, slower algorithm would run anyway!

On 4/16/2012 9:33 AM, Stephen V. Mather wrote:

Hi All,

                Has anyone done any performance tests on ST_MakeValid?  I had been using Tim Sutton’s cleanGeometry function from circa 2010 (http://linfiniti.com/2010/07/cleaning-geometries-inside-postgis/) to clean up geometries.  Works most of the time—every now and then I throw it something too big and harry and it runs for weeks and weeks and never (AFAI have the patience for) completes.  I’ve been looking forward to ST_MakeValid.

                Today, a new Postgis 2.0 instance in hand, I was playing with a dataset with 9106 invalid geometries—all self intersecting geometries from raster-->vector conversion in an un-named proprietary package.  On a whim, I decided to compare the speed of ST_MakeValid to Tim’s code, so first I needed the correct functions:

 

psql -U postgres -d test -f "C:\Program Files\PostgreSQL\9.1\share\contrib\postgis-2.0\legacy.sql"

 

Then a quick run through cleanGeometry:

 

CREATE TABLE tpi_clean AS

     SELECT gid, id, gridcode, "class name", cleanGeometry(geom)

           FROM tpi;

 

And I get back:

 

Query returned successfully: 1004952 rows affected, 955444 ms execution time.

 

If I run as ST_MakeValid,

 

CREATE TABLE tpi_valid AS

     SELECT gid, id, gridcode, "class name", ST_MakeValid(geom)

           FROM tpi;

 

At 2300000 milliseconds, it is still running… .

 

This is PostgreSQL 9.1, PostGIS 2.0 USE_GEOS=1 USE_PROJ=1 USE_STATS=1, on Windows XP 32-bit.  I have not yet tested on my Ubuntu box… .

 

Thanks,
Best,

Steve

 

 

http://www.clemetparks.com/images/esig/cmp-ms-90x122.pngStephen Mather
Geographic Information Systems (GIS) Manager
(216) 635-3243

s...@clevelandmetroparks.com
clevelandmetroparks.com

 

 

 

 



_______________________________________________
postgis-users mailing list
postgis-users@postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-users


No virus found in this message.
Checked by AVG - www.avg.com
Version: 2012.0.1913 / Virus Database: 2411/4940 - Release Date: 04/16/12


_______________________________________________
postgis-users mailing list
postgis-users@postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-users

Reply via email to