Duplicate Vertices in UN but not in Check Geometry

[SusanONeill1]

I am working on converting a  Water geometric network to the Utility Network.  When I enable the UN, I get over 180 errors that indicate a water line has duplicate vertices.  But if I run the "Check Geometry" tool, it doesn't find any errors.  Is there some difference in the tolerance between the Check Geometry tool and the UN?  I can't find any place to change or define a tolerance in either tool. 
(I realize I can display the vertex coordinates for each of the lines and determine if there is a duplicate, but that seems pretty labor-intensive if there aren't really any errors.)

Please let me know if you can help.  Thanks.  

[RobertKrisher]

There is a slight difference. However, because you can get your data you should use the errors captured there to identify the features you need to clean up. You can use the Summarize Utility Network Errors tool in the Utility Data Management Support toolbox (included in the Utility Network Foundation) to create a report database that describes all the errors that you can overlay on your source data.

[Isaac_King]

I was going to recommend the same thing Robert did. The Summarize Utility Network Errors is a very useful toolkit that really helps to speed up bulk error remediation.

[SusanONeill1]

I was able to identify the lines by using the error code, but I guess the Summarize could come in handy at some point. I was just hoping ESRI had an explanation for why the tolerance is different - or how to identify the actual vertex in error rather than having the visually go through each vertex when editing (I don't currently have access to a license for "Feature Vertices to Points" or other tools that might help.)  I did find that I can put the line in edit, then display the vertex coordinates, export them to Excel and find duplicate rows in Excel.  So that will have to do for now.

[RobertKrisher]

The utility network uses a slightly larger tolerance than just the x/y resolution and x/y tolerance when establishing connectivity, so this is reflected in our analysis of vertices.

[EdwardBlair]

Hi @SusanONeill1 -

I'm finding the same problem.   No invalid line geometries in my source data (of over 240,000 lines) and about 240 features with "Duplicate Vertex" errors when enabling topology in the UN.   Kind of frustrating to find that the UN seems to be creating errors where they did not exist in the source data.

Any chance you found a better explanation for why this is happening or how to avoid it?

Thx,

Ed

[RobertKrisher]

The duplicate vertices check in check geometry is only checking whether the xy resolution ensures that any two vertices are distinct, the utility network also takes into consideration whether the two junctions would collapse into a single junction when establishing connectivity. The Analyze Network Data tool also includes an even more precise check that looks at your data for "Vertex within tolerance" issues, these are situations where they coordinates are distinct, and outside of the tolerance for establishing connectivity, but are still so close together that they may cause connectivity to not consistently be established when validating topology.

[SusanONeill1]

Ed,

   I didn't find any other info.  We will just have to fix the vertices when we've converted the data to the Utility Network.  Glad to hear someone else finds it odd in spite of ESRI's explanation.  

[EdwardBlair]

Susan -

Right.    I'm thinking I can discover vertices that are "close" (but not problems) in the source GN data and weed out those that will (likely) present problems in the UN.

It *is* reassuring that others have found this problem.

Thanks,

Ed

[RobertKrisher]

If you run the data through the migration toolset (or into any UN) then run analyze network data, it will flag every vertex on every feature that is likely to be a problem. If it's a small amount, you can manually fix it. If it's a larger amount than you could consider either relying on apply error resolutions to correct this problem every time or creating your own tool to fix these in the source data.