Timeline for Getting topology or out of memory errors with large dataset intersects and spatial joins in ArcMap
Current License: CC BY-SA 3.0
6 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| May 10, 2012 at 13:19 | comment | added | Brent Edwards | Generally speaking, I develop all of my geoprocessing scripts to write a new, local FGDB to perform all processing and then push the results to the desired format (SDE, PGDB, SHP, etc.). This is almost always the fastest and most reliable method. I only experiment with other formats as a last resort, when I have tried the options mentioned. | |
| May 10, 2012 at 13:11 | comment | added | Brent Edwards | In my personal experience, I've had certain overlay (intersection, union etc.) geoprocessing operations that produce geometry/topology errors when working with the FGDB format and function properly , without errors in SHP format. | |
| May 9, 2012 at 21:15 | comment | added | D.E.Wright | SaultDon, our experience in our production services has data being much more responsive in a fGDB than in a SHP. I can't give you exact benchmarks but we will see a 15%-25% improvement depending on the data being used. As we work with datasets for the entire State of Washington, this can add up. | |
| May 9, 2012 at 20:38 | comment | added | SaultDon | I also noticed features stored in a geodatabase draw/render quicker on screen compared to shapefiles. Storage location can also affect performance (networked vs local). | |
| May 9, 2012 at 20:34 | comment | added | SaultDon | Do you know of any benchmarks to show that the shapefile results in faster computation vs the geodatabase? I've noticed the reverse where clipping, union, intersect can complete far quicker with data in a geodatabase compared to shapefiles. | |
| May 9, 2012 at 20:24 | history | answered | Brent Edwards | CC BY-SA 3.0 |