[postgis-users] ST_MakeValid

Martin Davis mtnclimb at telus.net
Mon Apr 16 21:10:32 PDT 2012


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
>
> svm at clevelandmetroparks.com
> clevelandmetroparks.com <http://www.clemetparks.com/>
>
>
>
> _______________________________________________
> postgis-users mailing list
> postgis-users at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-users
>
>
> No virus found in this message.
> Checked by AVG - www.avg.com <http://www.avg.com>
> Version: 2012.0.1913 / Virus Database: 2411/4940 - Release Date: 04/16/12
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-users/attachments/20120416/d6974da6/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 3772 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/postgis-users/attachments/20120416/d6974da6/attachment.png>


More information about the postgis-users mailing list