7

Im currently trying to convert my scripts from ArcGIS to QGIS but one aspect that is extremely slow (imo) is trying to intersect a polygon with a line feature. I feel as though there must be a better way to accomplish trying to clip the voronoi polylines with the original polygon itself i.e. :

Voronoi_Lines

by

Original Polygon

These are some of the bench tests that i've done with these two layers.

ArcGIS 10.1 Intersect 2min 24sec

Grass 7 v.Overlay quit after ~1hour (~70% Selecting lines...) - Currently not supported in processing (Sextante)

Grass 7 v.split + v.Overlay ~2min + 45min

QGIS 1.9 quit after ~3hours

ogr2ogr -clipsrc quit after > 1hour

SAGA GIS Intersect Line-Polygon ~15min -- acceptable but still 7x slower than ArcGIS and produces wrong results? The images below show SAGA GIS Intersect(with dangles removed) and same area with ArcGIS Intersect - Clearly SAGA did not intersect the line and polygon correctly as there should be no connection of the lines. These errors are scattered throughout the new output!!! In addition Line-Polygon does not retain the polygon intersect attributes to the line unlike the other methods mentioned above...

SAGA GIS Intersect

I have placed the original dataset in a GitHub repository here so hopefully others can make their own benchmarks and thereby provide suggestions?

I notice that ArcGIS splits (cracking) the featureclass so I do not know if that is another possibility to improve intersection speed within one of the opensource alternatives mentioned above?

***Note that the reason I mention QGIS here is that I have made some scripts within the processing toolbox (formally known as Sextante) and i'd like to remain in that environment if at all possible.

System - Intel Core i7-2760QM CPU @2.40GHz and 8GB ram

Any help on increasing performance would be most appreciated!

Cheers

closed as unclear what you're asking by PolyGeo Oct 29 '15 at 10:25

Please clarify your specific problem or add additional details to highlight exactly what you need. As it's currently written, it’s hard to tell exactly what you're asking. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • you should try a benchmark using OGR directly: darrencope.com/2011/03/31/clipping-large-shapefiles-using-ogr - you can use that in the Processing toolbox as well. – Darren Cope Sep 16 '13 at 19:07
  • 1
    How about the SAGA function from the toolbox? They seem to be very fast and reliable. The default intersect and other default tools in QGIS are a real pain in the a.. – Bernd V. Sep 16 '13 at 19:32
  • 3
    @BJEBN: Can you put the data set online so that we can benchmark ourselves? – markusN Sep 16 '13 at 20:16
  • @Darren/@Bernd/@markusN see updated post – BJEBN Sep 18 '13 at 8:33
  • 1
    @BJEBN; unfortunately I don't have time right now to try a benchmark, but another thought may be to try the 64bit version of QGIS available as an experimental build from trac.osgeo.org/osgeo4w (assuming you're on a 64bit machine) and see if the processing time is any faster. Otherwise, you could add the GRASS v.split and v.overlay to the Processing toolbox - not that hard to do following the instructions here: fossies.org/linux/misc/qgis-2.0.1.tar.gz:a/qgis-2.0.1/python/… – Darren Cope Sep 18 '13 at 12:05
1

Yes same problem here. What I did to speed up this process was to load SHP files in PostgreSQL and do clipping there. Not a perfect solution but faster for me since I quite powerful server behind it. And yes, this operations are slow. I hope this improves in the future.

Not the answer you're looking for? Browse other questions tagged or ask your own question.