shrug-l: Repair Geometry and Dealing w/ ModelBuilder Iteration/Geodatabase Bloat to reconcile polygon boundaries programmatically.

Griffin, Jason jgriffin at co.pinellas.fl.us
Wed Dec 14 16:18:08 EST 2011


Hey guys,

I have been working with ModelBuilder recently and have found a few oddball issues.  First, when unioning two datasets together it is natural to create some pretty gnarly data.  With all of the slivers come geometry issues that need to be cleaned up before further geoprocessing can be done.  Now what you may not be prepared for is when running the Repair Geometry tool doesn't iron out the kinks.

Typically, when you try to run any sort of spatial analysis/selection/etc and the tool fails bad geometry is to blame.  Repair Geometry has always done the job for me in the past however my tools kept failing.  I created all sorts of insane steps and reordering of processes to cut down on the error, but on a whim decided to do something a bit odd.  I ran repair geometry two times in a row within my model, and that allowed me to process larger chunks of my dataset, but not everything.  So I tacked on an extra repair geometry, because at this point, why not, and it worked.

So Repair... Repair... and Repair some more if needed.

The fallout from my frustration and attempts to circumvent the need for multiple repairs I created a "simplified" model that runs record by record and appends the processed row into the new dataset (I only have 7,500 rows to run).  I run it, and it gets through a few hundred records, with excellent looking results, and then ArcMap crashes.  I pray I haven't corrupted my database and open up ArcMap while wincing, but it is okay this time.  I decide to be smart and create a backup of the dataset in ArcCatalog by doing the right-click + "Copy," and my computer freezes.  I restart my computer and check the folder, my geodatabase is over 4 gigabytes for two datasets.  Now something is not quite right with this.  I run compact, and the database shrinks to a respectable 60mb.

Moral of the story, keep an eye on your database size.  If you are iterating multi-step analysis and are dissolving/appending data like your license is about to expire throw a compact at the end of the analysis for good measure.  For a file geodatabase it only takes a second or so to run (After your first compact).  No clue as to what exactly the bloat is coming from but compact fixes it.

I hope everyone is doing well,

Getting aggregated Zoning data to coincide parcels where it should, and maintain the shape of Zoning where it matters...

There is a specific case where errors will be produced but it will reduce the number of manual edits necessary significantly.  ...and those errors are consistent which I will take on any day.
[cid:image003.jpg at 01CCBA7B.F76B2640]

After I run this model I also need to run the Eliminate Polygon Part tool to clean-up any tiny sliver/holes within polygons (Under 25 square feet).

Jason A. Griffin, Ext. 33613 | BTS Senior Technology Specialist, GIS Dev. | Pinellas County Government, Business Technology Services [BTS] | 400 S Ft. Harrison Ave | Clearwater, FL  33756 | Tel: 727-453-3613 | Cell: 727-600-6634 | JGriffin at co.pinellas.fl.us<mailto:JGriffin at co.pinellas.fl.us>|

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.dep.state.fl.us/pipermail/shrug-l/attachments/20111214/a2da63b5/attachment.htm
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.jpg
Type: image/jpeg
Size: 46741 bytes
Desc: image003.jpg
Url : http://lists.dep.state.fl.us/pipermail/shrug-l/attachments/20111214/a2da63b5/image003.jpg


More information about the SHRUG-L mailing list