ArcGIS–QGIS Faceoff

Is QGIS a viable alternative to ArcGIS?

(Please note: This post is about clipping in ArcGIS version 10.0. The functionality has been improved, and problems mentioned have been fixed in later versions of ArcGIS)
I’ve never enjoyed working with contours. They seem to bog down my system more than any other layer type I work with. However, most of my clients are so used to looking at USGS Topo maps they expect to see them on at least one of the maps I produce for them. I recently worked on a project covering a five-town area in the Catskill Mountain region. The large area covered, and the ruggedness of the topography was proving exceptionally troublesome in processing their contours. So much so that I decided to look at other options to get the work done. I’ve used a variety of GIS tools over the years, but do most of my paying work exclusively in ArcGIS. It’s what I’m most familiar with, it does (nearly) everything I need it to do, and therefore provides my clients with the most efficient use of my time. However, in this situation that was not the case.
The one geoprocessing operation that frustrates me most often (in ArcGIS) is the Clip operation. It seems to take more time than most other geoprocessing tools, and often results in bad geometries. This happens so often, I usually resort to doing a union, and then deleting the unwanted areas of the Union results. For some reason this works much faster, and with more reliable results than doing a Clip.
Since what I wanted to do here was a clip on a contour layer, I was in for double trouble. Yes, I could have clipped the original DEM I wanted to produce the contours from first, then generated contours from the clipped DEM. But that wouldn’t have led to anything to write about. So, here’s a short comparison of how ArcGIS handled the process versus QGIS:

The hardware and software used:

ArcGIS 10, SP2

  • Windows 7, 64 bit
  • Dell Precision m2400 laptop
  • Intel Core 2 Duo CPU, 3.06GHz
  • 8 GB RAM

QGIS 1.4.0

  • Ubuntu 11.4
  • Dell Inspiron 600m laptop
  • Intel Pentium M CPU, 1.60 Ghz
  • 1GB RAM

A fair fight?

I started out with ArcGIS, and loaded up my 20’ contour lines and a 1 mile buffer of the study area to which I wanted to clip them. I began the clip operation 3 times. The first two times I had to cancel it because it was taking too long, and I needed to get some real work done. Curious to see how long it would really take, I let the process run overnight. The progress bar kept chugging away “Clip…Clip…Clip…Clip…”, and the Geoprocessing results window kept updating me with its progress, so I assumed it would complete eventually. In the morning, I looked in the Geoprocessing results window and found it had run for over 12 hours before throwing an error, never completing the clip operation. The error message said something about a bad geometry in the  output. Really, no surprise there.
ArcGIS - ClipContour1
(Yes, those are lines in the picture above, not polygons. They’re very densely packed)

QGIS gets to play

The next day I decided to give QGIS a shot at it. I copied the two shapefiles over to my 6 year old lappy. (The contour.shp file was 1.3GB) fired up QGIS, and ran the Clip operation on the two files.
QGIS - Contours Screenshot-Clip
This time it took all of 17 minutes and 21 seconds to get a new contour layer.
Clip Results - QGIS
So, who’s the winner here? Was it a far contest?
My take-away is, ESRI really needs to do some work on its Clip geoprocessing tool. As I said earlier, it is slow, and results in bad geometries more often than any of their other geoprocessing tools I use.
Addendum June 11, 2011: See the follow-up post here:

Reader Comments

  1. I’m going to forward this to all government departments…
    Wait, then I won’t ever get a job.
    Thanks for sharing your experience, Don!

  2. As much as I love QGIS, I think there is something else going on here. Will it be possible to share these two layers to check independently?

    1. Maxim –
      I agree, given the fact that Arc couldn’t even produce output, it looks like something else is going on. However, this is not the first time I’ve had problems with Arc’s clip routine. It’s been behaving like this for me since 8.x came out.
      I did restarts between my 3 attempts using Arc, and killed as many background processes as I could before the last attempt. I still want to give it a couple more tries before I hand out the layers. But, I will do that if I continue to come up with the same results.

    2. Good stuff Bill! CartoSet and the awesome yet smilpe things Vizzuality is doing with it, seriously makes me reconsider my life in management. I wanna be programmer really really bad so I can play with those toys!

  3. I wonder how by much QGIS’ 17:21 to complete the clip would be reduced if it were run on hardware comparable to your ArcGIS machine.

  4. Hi to All,
    I’ve found something “in the middle” of those two softs… Just a few hours ago I did quite similar process with GlobalMapper LLC – v. 12.02. A huge set of DEMs were opened. An SHP border overlayed. With a simple command – “Generate Contours – lines of 5m elevation interval” for the area just covered by the SHP file… and crop …
    It took just a minute to complete…, however that was not the same set of files as used by Don. One should try GlobalMapper too :-))

  5. I’d be interested in seeing how PostGIS compares… load the two datasets into spatially indexed tables and run the (very complicated) query:
    select ST_intersection(a.geom, b.geom)

  6. Answer my own question…
    With a 110Mb shapefile of elevation contours & a rectangle to clip them (about 60,000 linestrings in the output) QGIS=40 sec, PostGIS=30sec, both gave the same result as far as I can simplistically tell. Run on a 2 core AMD64 3.4Ghz with 8Gb memory under Ubuntu. QGIS 1.6, PostGIS 9.0/1.52.
    I guess Postgis has no graphical overhead, there are a couple of seconds to render the output for QGIS. Postgis sql =
    “create table test as select b.gid, b.elevation, intersection(a.geom, b.the_geom) as geom from wgtn_box a, contour b;”
    SELECT 59828
    But both worked quickly & apparently flawlessly.

    1. I think QGIS and PostGIS should be the same cause they both use GEOS for geoprocessing. However, I am not sure.

  7. Nice!
    I will more explore QGIS in my next projects.
    Thanks for share..

  8. The days of OS X are numbered. All hail iOS. ESRI didn’t miss the boat for OS X, they are ahead of the curve.

  9. So I tried some tests. Starting with a rectangle for the clip area (4 vertices) and a 121MB contour shapefile (all are files used are shp).
    Esri arc 10 took 2:09 (minutes:seconds)
    Qgis took 23.4 seconds
    GlobalMapper 32bit took 7.2 seconds
    GlobalMapper 64bit took 5.1 seconds
    The resulting file sizes were all very close, 53.9MB plus or minus a few kb.

  10. I noticed the same problem when using the dissolve tool in ArcGIS 9.1, It would work quickly up to 10000 polygons and after that would slow down. 10000 would take 20 minutes, 20000 polygons would take all day. When we mentioned it to ESRI they suggested it was the small amount of ram available on the computer 2gb.

  11. Thanks, you found a bug in our clip operation that was exposed by a number of the contour lines having 500k vertices which span nearly the entire extent of the data. The clip algorithm was sub-optimal for data matching these criteria. We’ve worked out a fix in our upcoming 10.1 release that has brought the time down to approximately the same amount of time as what you reported for QGIS.
    When you run into these kinds of issues with ArcGIS Geoprocessing, please contact ESRI technical support, and we’ll be sure to review the issue and do anything we can to resolve the reported issue.

  12. So the raster clip tool is not going to work until the next version of Arc comes out huh? That’s awesome.

  13. A quick update on our work with this case. We’ve now have the GP Clip tool performing this clip operation in 34 seconds. This improvement will be available in ArcGIS 10.1.
    Once again, thanks for bringing this to our attention.

Comments are closed.