Round 2 in which ArcGIS throws in the towel.
(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)
This is a follow-up to my previous post where I matched up ArcGIS and QGIS in a clipping contest. One of the commenters on that post expressed some concern that there might be “…something else going on…” with my test, and I agreed. It was unfathomable to me that an ESRI product could be out-done by such a wide margin. Knowing that ArcGIS often has problems processing geometries that are not squeaky clean, I began my investigation there. I ran the original contour layer through ArcToolbox’s Check Geometry routine, and sure enough, came up with 5 “null” geometries. I deleted those bad boys, and ran it through ArcToolbox’s “Repair Geometry” routine, and then ET GeoWizard’s “Fix Geometry” routine for good measure (These may or may not be identical tools, I do not know). No new problems were found with either tool.
I wanted to give ArcGIS a fighting chance in this next round, but also wanted to level the playing field a bit. I did a restart of my Dell m2400 (see the specs in the previous post), exited out of all my desktop widgets, and turned off every background process I could find. I also turned of Background Processing in the Geoprocessing Options box. The only thing running on this machine was ArcGIS 10, and the only layers loaded were the contour lines and the feature I wanted to clip them to. I ran the “Arc Toolbox > Analysis Tools > Extract > Clip” tool and watched as it took 1 hour 35 minutes and 42 seconds for ArcGIS to go through the clipping process before ending with the message:
ERROR 999999: Error executing function
Invalid Topology [Topoengine error.]
Failed to execute (Clip)
Now granted, this is much better than the 12 hours it took the first time I ran it, but still, no cigar in the end.
Giving QGIS a chance to show it’s stuff, I used Windows version 1.5.0 to run a clip on the same files, on the same machine. QGIS took all of 6 minutes and 27 seconds to produce a new, clean contour layer.
I ran this through the same geometry checks as the original contour layer, and came up with no problems.
My goal here is not to jump all over ESRI and do a dance in the end zone. I would really like to figure out what’s going on. As I’ve said before, I’ve had problems in the past with ArcGIS producing bad geometries with its Clipping process (and other tools, too). But the fact that another product can handle the same set of circumstances with such ease baffles me.
I’ve put about as much time as I can into this test, and taken it as far as I can. If you would like to give it a go, feel free to download the files I used through his link:
www.donmeltz.com/_files/ContourClipTest.zip
(Note: This is a 878MB file, and is not completely uploaded as of this posting. Check back later if the link does not work for you right now)
If any of you have better results than I did, or find any faults with my files or process, please let me know and I WILL make a note of them here. Thank you.
It’s always great to see people taking some of their time to make up practical comparisons between ESRI products and FOSS4g. I would love to see some of my academic colleagues reading blogs like these… they really need it.
By the way..loved the entry title!
It is just good to see someone confirming what our little gis lab has noticed for years, ArcGIS can be very slow and buggy with geo-processing tasks when compared to using QGIS/FOSS4g tools.
We still love ArcGIS desktop for Map Layout and design, Topology Rules, and Map Export. Although ESRI had better shift gears and stop coasting on their legacy.
What about OGR2OGR?
QGIS might use the library already for clipping?
ogr2ogr -clipsrc clipping_polygon.shp output.shp input.shp
Good comments about Esri getting their house in order – but “legacy” might be the wrong word:
I don’t use QGIS – but often for those geoprocessing tasks I drop back to ArcView 3.3 to knock it out – which of course is stupid – but it works really well. Probably the mostly the same speed as QGIS.
rw,
If you already submitted tech support issues for these, please send me the incident numbers so I can follow up. If not, contact me directly with the cases so I can make sure that they are investigated.
Starting at 10.0 we were able to address a few cases from people who were doing the same thing as you (going back to AV). Once we were made aware of the issues they were seeing we addressed them and they are now successful with ArcGIS.
Thanks,
Ken
Users of AV 3.3 are rare and getting rarer: it’s nice to see some still around. Of course it has its limitations, but subject to them, it is a great adjunct to ArcGIS (and not just for clipping). In many cases, an operation that bogs down ArcGIS will simply fly in AV 3.3. To get one-off analyses done, it can be far faster to save an ArcGIS dataset as a shapefile or grid, do the work in AV 3.3, and import its results back to an ArcGIS project. Compared to ArcGIS/ArcCatalog, AV 3.3 has a light footprint: it costs about 40 MB RAM to keep it open in Windows and consumes almost no other system resources. And it only takes one second to launch, anyway… .
As far as installation goes (for those who may no longer have it on their systems): if you still have a full disk backup from an old Windows version of AV 3, simply restore the AV folder (usually C:/ESRI/AVGIS30) to a new machine. (Later you might want to copy over some of the old ESRI fonts, too.) You’re off and running.
Correct. ArcGIS 8x, 9x, 10x are nowhere near the speed of old ArcView 3x when it comes to clipping. But most of us no longer have 3x installed.
One work around: select and save the subset of the intersect your clip boundary; clip that. I don’t think Arc does this in memory, and it may greatly pare down the task. Then realize that ETGeoWizards can often finish a task faster than the ArcToybox dialogs can open. Or jump to QGIS.
Don- Just tested your clip files in Global Mapper v11.02 on Windows XP w/ 3.5GB RAM and tons of other processes running. It took a whopping 49 seconds to perform the clip!
QGIS – 4 min
ArcGIS 9.3 – 1h9m to:
ERROR 999999: Error executing function.
Invalid Topology [4gb file limit.]
Failed to execute (Clip).
Ran on 6 core overclocked system w 8gb ram, on solid state drive. built the system specifically for cpu-intensive geoprocessing, only to find out esri doesn’t utilize 80% of my resources (no 64bit support). But even QGIS didn’t use much either.
wonder how some of these others compare, now. Thanks for the post!
I couldn’t get ArcMap or ArcCatalog to finish. I tried putting it in a fgdb and doing the work there, but I still got a 999999 error of sorts.
Though I think if you have to use esri – a workflow like this might work…
Select contours by location – using the buffer area. Switch selection and delete the stuff you don’t need. Smaller file size might help.
If that doesn’t work…
Convert the buffer area to a line and split the remaining contours. Split seems to be easier than a clip. Then repeat the first step above.
Or use something else.
The times that it took for me
GlobalMapper – 30 mins
QGIS – 4-5 mins.
Using Manifold 8 (64bit) in Windows XP64, 16 gb. ram, and 2.33 ghz with 8 cpu’s (only one used) – Manifold completed in 31 minutes.
Lots of background stuff running, even my anti-virus.
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.
Many Arc(users) would love it if ESRI could fix it’s geo-processing issues across the board…
Try doing a simple merge of 100 shapefiles… It will easily take seconds using GDAL and several minutes in ArcGIS…
What is up?
Mars,
Have you reported this to our tech support yet? If so, please send me the incident number so I can follow up.
Thanks,
Ken
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.
Ken
Here the benchmark for GRASS GIS 7 (thanks to Markus Metz, GRASS7 comes now with a much improved and faster topology engine):
The v.overlay command takes 5min and 4s seconds on a Dell PowerEdge 2950 from 2008 (Intel Xeon 2.66GHz, 8GB RAM, so not really new hardware) to topologically intersect the layers.
Full script if you want to try yourself:
#!/bin/sh
#
# create the GRASS GIS location from dataset:
# grass70 -c StudyArea1MileBuffer.shp /grassdata/contourClipTest/
#
# start the session:
# grass70 /grassdata/contourClipTest/PERMANENT/
export GRASS_OVERWRITE=1
# import the maps
v.in.ogr Contours20Ft.shp out=Contours20Ft
v.in.ogr StudyArea1MileBuffer.shp out=StudyArea1MileBuffer
# overlay operation (with time measurement):
time v.overlay ain=Contours20Ft bin=StudyArea1MileBuffer op=and
atype=line btype=area out=ContourClip --v
I published a benchmark summary here:
http://gfoss.blogspot.it/2012/11/arcgis-vs-qgis-etc-clipping-contest.html. Thanks for this great post!
CPU: Intel(R) Core(TM) i3 CPU 540 @ 3.07GHz
RAM: 4GB
gvSIG 1.12; Xmx=1024MB; Xms=256MB;
Clip build-in process: 2 minutes and 20 seconds
Sextante Clip: 1 minute and 36 seconds
GDAL 1.9.2, released 2012/10/08
ogr2ogr -clipsrc StudyArea1MileBuffer.shp ../salida_ogr.shp Contours20Ft.shp
3 minutes and 50 seconds
As the designer of JTS (and GEOS, which is being used in at least some of the C-based FOSS participants) it’s neat to see these numbers.
It would be interesting to see a comparison of a polygon coverage overlay process. That’s substantially more challenging in terms of functionality, robustness and performance. How about running another shootout?
With OpenJUMP (based on using JTS 1.13 – EnhancedPrecisionOp.intersection) with -Xmx8192M option, Windows Vista, a core I7 and every data loaded into memory :
clipping = 62 s
(loading the shapefiles is 20 to 66 s, exporting the result is 4 s and processing is not possible on a 32b machine due to limitation on the adressable RAM)
Michaël
I tested it with ArcGIS 10.1
It seems something was fixed. ArcGIS did complete the clip operation and it took only 1 minute and 3 seconds.
the only “hack” I did on the dataset was creating a File GeoDatabase and importing the two shapefiles inside it.
The test run on a virtual machine with 2 Intel XEON X5570 2.93 GHz and 4 Gbyte Ram.
Cheers
Stefano
Stefano –
Yes, it has been fixed in version 10.1, as noted in a previous comment.
Here is a comparison of ArcGIS 10.1, Spatialite, Manifold, and QGIS all on the same computer:
http://www.georeference.org/forum/t117952.13
Spatial join: QGIS 1.8 vs and ArcGIS 10.1
on MacBook Air with Intel(R) Core(TM) i5-2557M CPU @ 1.70 GHz, and 4.00 GB RAM, which is not really for intensive computation.
I have been working on a series of huge shapefiles in ArcMap, and was able to spatially join over 3 million points to over 3 million polygons (falls into/within) in about 30 hours on my MacBook Air. However, I couldn’t even open these shapefiles in QGIS on the same machine — every time after trying to add the layer for about 30 minutes, QGIS crashed.
Using ArcGIS Pro Beta 2, the clip operation took 18.17 seconds on a Windows 7 Dell Precision T3600 with Intel Xeon E5-1650 @ 3.20 GHz and 8GB RAM
Tom
Ran the test – QGIS 2.4.0 (64bit) vs ArcGIS 10.2 (32bit?)
System Specs – Haswell i5-4570t – 2.9ghz, 8mb ram
ArcGIS 10.2 geoprocessing to default geodatabase.
Executing: Clip Contours20Ft StudyArea1MileBuffer
Start Time: Thu Jul 10 10:53:23 2014
Analyzing input features…
Dissolving clip features…
Clipping input features…
Succeeded at Thu Jul 10 10:53:46 2014 (Elapsed Time: 22.93 seconds)
I did not have an output message on QGIS so timed it with a watch. Geoprocessing the clip in QGIS took 1 min 50 secs.
I think the performance benefit in ArcGIS is due to outputing to the default geodatabase. Or possibly how arcpy differs from the geoprocessor used in QGIS? You would expect ArcGIS to outperform QGIS and it did. I tried different methods, running the tool in ArcCatalog and clipping to a shapefile and the average time for the tries is about 30 secs. However I don’t have a license outside of work to do this so I can afford to wait the extra minute for the processing to complete vs the cost of the license from ESRI.