Topology Validation versus Fixing the Actual Error(s)

[JoeBorgione]

In a couple of recent posts (Export Topology Errors and Versioning  & Cannot iterate Export Topology Errors GP tool ) exporting topology errors is a common theme.

Topology in an versioned enterprise geodatabase is something of a mystery to me, as I've long held the belief that feature datasets within the egdb environment is looking for trouble.  I still hold that belief, but have to deal with it none the less...

All that said, I am scripting a process that examines a topology and in doing so, exports the errors found. 

In the production egdb, the actual errors themselves have been corrected in the life feature class, but the topology itself has not been (re)validated.  When I run my script against the production egdb, I get no errors returned.

We also have a test egdb that mimics the production egdb.  However, the line feature class has not had any edits made correcting the topological errors.  When I point my script at the test environment, I get all the errors exported as expected.

Bottom line:  when do topology errors disappear?  I always figured you had to validate the topology to clear them out, but what I'm finding doesn't support that.

[BillFox]

Are they still there after a few reconcile & posts to Default?

[JoeBorgione]

The topology is built on a version once removed from default.  Yes; the edit version has been reconciled and posted with default in our production environment. 

Bill Fox‌

[George_Thompson]

Are the tolerances the same between both the PROD and TEST EGDB and is all the data the exact same?

Are the EGDB's at the same version and RDBMS patch level?

[George_Thompson]

I have seen where data copied from one GDB to another fixes some of the geometry issues that topology may flag.

[JoeBorgione]

The test egdb is a copy of the production egdb, so it's more or less a mirror.

Back ground:  every Monday at quitting time we open an edit session in ArcMap with the production feature class & topology: with the validate topology tool in the topology toolbar, we validate the topology.  It takes anywhere from 12 to 17 hours to run, as it's validating topology on 4.5 million line features.  When it's done on Tuesday morning, we use the error inspector to get a list of lines and their respective errors.  That list is then emailed to the editors and they make the corrections; those corrections are reconciled and posted to default Tuesday afternoon.  Given validate topology is such a pig, we run it only once a week.

If you recall one of my earlier posts on topology permissions, I'd like to have the editors validate once they finish an area of edits.  My team inherited this process when another employee moved on to green pastures, and we are trying to get the whole mess automated.

[George_Thompson]

Ok, thanks for that background.

How may errors are there when the topology is run and completed?

Are there polygons in the topology runs also or only the lines?

I would say that as long as the editors validate before reconcile and posting to their parent version then I would say that they should be good. 

Are the editors making a dent in the # of topology error present or are there a bunch of "new" errors popping up each time?

[JoeBorgione]

The topology rules are are simple and apply only to lines, so I get line errors ('Must Not OverLap') and point errors ("Must Not Have Dangles", "Must Not Self-Inersect")

We are seeing only about 50 errors tops with each validation, which when you do the math with 4.5 million records, the errors are a minuscule percentage.  We have to check for them though since these 4.5 million lines become 450K parcel polygons. (Can't wait for Parcel Fabric implementation...)

The editors fix all the errors we discover in the validation. But this is a living breathing feature class that's constantly being added to. So they fix errors and we find new ones the next time we validate....

[JoeBorgione]

Here's an update on some testing:  my script to export line and point topology errors seems to working for me. It emails me two spreadsheets, one for point errors, one for line errors that have the objectid of the line associated with the error as well as the error description.  

I then make some edits to the lines and re-run my script.  If the edit I make is snapping a line to the end of another line, I see that error again.  However, if my edit is deleting some weird line that is clearly a cogo error, that error is not listed on the spread sheet.

Big fun...