On a monthly basis I create a bunch of topologys to make sure that my polygon layers don't overlap or have gaps (ESN). I also run a topology on my street layer to find street segments that aren't snapped. This process consists mostly of models.
Since I always try to help my Public safety brethren, I figured I compile my process in a Python AddIn, that "should be easy to use". I started a day ago and have the skeleton of the AddIn finished and now I am looking for a Guinea Pig (I am looking at you Chris Donohue, GISP & Joe Borgione ) to use it!
- Created an official document: Topology Check Python AddIn (6/30/17)
- Added Error message when the wrong feature is chosen for certain Checks (i.e. polygon feature is chosen for dangle check)
- Now works with ArcGIS Desktop Standard
- Latest test version that includes a polygon break check. This check make sure that your line features are broken when they intersect with a polygon feature. Just select the line feature and polygon feature in the TOC and run the check.
Dropbox - TopoAddIn.esriaddin 10.3.1 + version
Here is what you need:
ArcGIS Desktop Standard 10.3.1 or later versions
Here is how it works:
1. You would download the add in HERE. (10.1 version HERE )
2. Double click it and install it.
3. Open an MXD and add a polygon layer and a street layer.
4.The toolbar should be there but if it is not click on Customize -> Toolbars -> TopoCheck
5. Follow the steps in the screenshot!
As I said it is still a work in progress, especially the street dangle check.
Let me know what you think!
I'm in. Let me download it and I'll give it a spin sometime today! Thanks Tim!
I took a quick test drive earlier today, and so far it's pretty darn cool. What I like most about it is the fact that I can find topololgy issues in my enterprise geodatabase without the overhead of creating a feature dataset and subsequent topology; imho, feature datasets within an enterprise geodatabse should be avoided at all costs.
The add-in creates actual feature classes out of the errors, so for example, I got a points feature class of street dangles. We all know what a 'should not have dangles' topology looks like; you can't tell the legitimate dangles of cul-de-sacs from actual problems. I selected all my freeways and then selected just those dangle points that intersected the selected freeways; in about 10 minutes I had a dozen or so dangles on my freeways and ramps fixed that I had no idea about. I also spatially joined the non-freeway errors to my Cities polygon feature class, so the individual city-editors can quickly review just those points within their respective borders. Slick.
I'll be correcting some dispatch response polygon errors next, and if it goes as easy as the first trial, it should be a piece of cake.
Tim- I'll send you a follow up email with some "it would be even cooler if it could do this" notes in the next few days. Thank you a million times over for developing it and giving me the opportunity to try it.
Chris- You gotta try this!
the latest version should dramatically cut down on the "false dangles".
I can't wait to see your wishlist
The AddIn came in easily and looks good, but unfortunately no luck on getting it to work. I tried some test data in a File Geodatabase which was purposefully altered to have gaps and overlaps, but didn't get any results from running the AddIn tool. There was not any errors or other feedback, just no results.
I suspect it may be the ArcGIS version differences of 10.3.1 vs 10.2.1, i.e. the Python version associated with each version of ArcGIS has some critical difference (I'm still in the stone ages (10.2.1)).
I guess for now add that as a potential limitation for users.
Chris Donohue, GISP
Sounds cool. I'll give it a look, but unfortunately I'm on 10.2.1, so it may blow up due to version differences (the City has been holding off upgrading due to many other systems that connect to GIS that are not compatible with the newer versions of GIS, like ArcFM).
Chris Donohue, GISP
I'll give that a try.
Chris Donohue, GISP
Got some results this time. When run, the tools chug away and the classic "Not Responding" shows up, but then it finishes out after several seconds.
Check for Overlaps - worked when run on parcels with an intentional overlap. Looks good.
Check for Gaps - no results for output feature class GapErrors_poly when run on parcels with gaps, but did get the parcels gaps correctly depicted as lines in GapErrors_line output (purple lines below).
Check Line Segments - DangleErrors output correctly found two dangles that were close to other lines, but missed dangles that were far from other lines. Could be a just be a tolerance setting, though.
Unfortunately, no results for OverlapErrors_line output despite the intentional addition of line overlaps to the street test data.
Note - I made some assumptions when running these, which may influence the results:
1. The tools ran without being in Editing Mode for the selected feature class, which I assume is OK. If instead it is assumed that the user is in Editing Mode for the feature class being checked, let us know.
2. I didn't worry about whether the layers selected to run a tool on were set as specifically Selectable.
3. Ran the tools on test feature classes in a File Geodatabase. Did not try them on Versioned data.
Also, the bane of all software development, a feature request Is there a way to change the default location the output feature classes get written to? At the moment the seem to be going to a new geodatabase added to the C: drive. Not a critical request, but it would be nice to be able to save it to a few levels further out in the C: drive.
Chris Donohue, GISP
glad it gave some results! For you (10.1 to 10.2) I removed the dialogue box that will tell the user that the tool is running via a progress bar. Apparently this feature became available starting 10.3.
It is funny I already started thinking of improvements for the tool and they would address your issues
1) Add another button to find overlaps of lines (which will make sure that street segments are broken at intersection. You would probably get "false" overlap errors in case of an overpass)
2) You and HeatherW had the same request, which is a great idea. I'll have to figure out how I can in cooperate the functionality of the user being able to choose where the geodatabase goes.
3) At the moment the dangle tolerance is set to 1 foot, maybe add a combo box to let the user choose the feet? The way it works at the moment is, it buffers (1 foot) around each dangle and if it the circle hits the street more than once, it is a valid dangle. By changing the radius it would have probably popped up the one in your picture. At the same time we don;t want to make the radius too big.
Again thanks for the feedback. This will be a work in progress!