While we’d like to think everything going into our Geodatabase was done correctly – I mean no one purposely enters invalid data, right? In practice we need to perform QA on a regular basis. It’s really just a given.
As we know in our ArcGIS/ArcFM solution stack there are two ways to perform QA, ArcFM “Run QA/QC” and ArcMap “Validate Features.” Both operate on a selected set of features. The ArcFM QA gives us a progress dialog, a list of errors we can inspect or write to a file, and most importantly, returns *all* errors found for a feature and any related records. The ArcMap “Validate Features” runs silently and removes valid features from the selection set leaving only invalid features selected.
In general, we like to use the ArcFM QA to get benefit from its completeness – but the price is performance. Here’s an example comparison of QA times for a sample set of approximately 45,000 complex edge features that we’ve found to be pretty representative:
That’s 15 minutes difference.
Knowing the performance difference and the results returned one strategy to consider is this:
1. Execute ArcMap “Validate Features” on your large selection set
2. Execute ArcFM “Run QA/QC All” on the remaining features in the selection set known to have at least one error
The following table offers a breakdown of times for an example of 26,000 simple junction features:
In this case our strategy saved us about 10 minutes for a QA run. If this is a task you run repeatedly, it might represent an opportunity.
Of course, if all or a large majority of your feature have QA errors this strategy won’t save but cost you time. Nonetheless, in our experience cases where *all* features in a class have QA errors is relatively rare.
In the end, we hope this strategy might be able to save you some time in your QA processing going forward.