[postgis-users] ST_MakeValid

Tue Apr 17 07:30:50 PDT 2012

:)  It's never so easy, is it.

I had reason to kill the ST_MakeValid at about 10:1, so I have no idea what
the completion time is except > 10,000 seconds.  I'm rerunning now.

I can play with finding a subset of the data that replicates the behavior.

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
 <http://www.clemetparks.com/> clevelandmetroparks.com

From: postgis-users-bounces at postgis.refractions.net
[mailto:postgis-users-bounces at postgis.refractions.net] On Behalf Of Martin
Davis
Sent: Tuesday, April 17, 2012 12:11 AM
To: postgis-users at postgis.refractions.net
Subject: Re: [postgis-users] ST_MakeValid

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
 <http://www.clemetparks.com/> clevelandmetroparks.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
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/20120417/c11ab151/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 3772 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/postgis-users/attachments/20120417/c11ab151/attachment.png>