Wherefore are thou Topology? (A Plague On Both Your Houses!)

Not a lot of ESRI posts here recently for a mostly happy reason: there's been little ESRI programming in my universe the past few months. I've been working on a fun little wrapper generator for managed code called GIWS (no, not about the Chosen Tribe, it's SWIG backwards. Get it?) Anyway, that's a post for another time.

Today I come not to praise ESRI Topologies but to bury them. One of our products has a feature where you download a little personal geodatabase from our web application to your desktop to do detailed editing in ArcMap, then you send it back to us and we unpack it. We're thinking of scrapping the whole approach as it turns out to make sense to programmers, but not to end users where it is deployed. But that's yet another post for another time.

Anyway, we take care to create the feature classes in this personal geodatabase in a topology, complete with rules about overlaps, to help users create clean datasets. Several of our feature classes are essentially coverages: the polygons need to be non-overlapping. We thought that by creating a topology automatically we'd be doing our users a favor. They're tedious to put together, and somewhat intricate.

Well, two years later we're getting rid of the topologies. I thought it might be worth sharing our reasoning, as I'm curious whether anyone else has found similar problems. (FWIW, we're using 9.0. Doing work for a big company means you have the awesome upside of knowing your work matters on a large scale. The downside is usually being 12 months behind the technology curve. That's okay.)

• Topology algorithms find uncorrectable problems. We had many instances of topology scans finding, for example, polygon overlaps, which turned out to be degenerate lines, points, or even invisible artifacts. These seemed to be associated with datasets where original work had been done in a projected coordinate system, then projected into the WGS1984 we use internally. I understand that projection might cause points to snap differently, creating errors. We all get it. But the problems detected would turn out to be invisible or uncorrectable. That aggravated people.
• Topology algorithms are different than geoprocessor algorithms. The feature classes users edit were inputs to a series of geoprocessing algorithms. Nothing exciting, mostly intersections followed by some algebra on the attributes. But quite often a topology check would claim no overlaps, while an intersect would show overlaps. (It forced us to do a sanity check before geoprocessing of doing a self-intersect on each layer and asserting that the number of input polygons equalled the number of output polygons.) We did not spend time to figure out who was right -- and given well-known robustness issues in spatial algorithms, it may well be that both are correct. But since our results are created by the geoprocessor, we decided to use it.
• Topological Editing is a very advanced skill—people don't like learning it. We had trouble convincing our users to learn the topological editing tools. Heck, normal editing in ArcMap is hard enough. I couldn't really blame them.
• Topologies add awesome bloat to geodatabases. We were seeing geodatabases with a dozen simple feature classes bloating to 700MB after editing. Compacting them would take them back to 2MB. Ouch. We know databases need to be compacted now and again, but this was a little much for us.
• Toplogies would cause obscure COM errors in our geoprocessor. This one may be sort of our fault. We are using the 9.0 geoprocessor in-process on the main STA thread of our desktop application. It doesn't seem to like that, and we're contemplating running it as an out-of-process python script on demand. Nonetheless, the stability of our tool has increased since we didn't include topologies. Given the above reasons not to use topologies, it wasn't worth debugging this one.

We really wanted topologies to work. They make sense, they reflect how people really think, they ought to be the bee's knees. But we were ultimately disappointed. Perhaps they're better in 9.2 or 9.3, but I doubt we'll try them again. We coded our own overlap detection and repair tool for people who can't use the ones already out there (e.g ET Geowizards).