Geoprocessing Tools for UN Error Analysis

[MarkCederholm]

The PointErrors and LineErrors feature classes provided a simple way to analyze and address UN errors via SQL and Python.  Each record provided a single error code and identified both features involved in the issue.  The UN4 approach is a serious barrier to effective automated error analysis.  I think the least that can be done to rectify this situation is to provide geoprocessing tools to generate the old error classes.  Given some reflection and imagination, think of the even better tools that could be created.

[RemiMyers]

Thanks for your Idea submission.  As you mentioned there have been significant changes with the release of the UN4; these changes were a result of performance optimizations and the new nonspatial objects.   

The new dirty area layer is configured to store and maintain the error codes, to provide the network source, and GUID of the error features.  This approach was intended to reduce the number of error features and enables network management to be more performant on networks that have a larger number of errors.  Since nonspatial objects don’t have geometries, the team decided to include the error management for those objects in a single dirty area layer.   

As always, we are working to improve the user experience for QA and error management and look forward to seeing your solutions and customers moving into production environment. 

[MarkCederholm]

Code breaking changes are never fun.  After more work, I finally found another way to accomplish my goals, and I'm considering posting a blog entry about this for the benefit of others.

[DavidCrawford]

Hi Mark,

I'm not making any promises here, but we are willing to consider this idea. We have a mechanism by which we can generate the 'old' style error features, and hydrate a couple physical classes to allow you to work with in the v3 style. This mechanism is, as yet, untested and unimplemented, but it is something we could consider in the future.