nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

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.

Find more posts tagged with

Accepted answers

All comments

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,

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,

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.

SusanONeill1

Robert,

This sounded promising, but I ran the Analyze Network Data and it only found 2 Duplicate Vertex results. The "Dirty Areas" in the UN indicate there are 174 lines with duplicate vertices. I don't know why they aren't consistent, but it does limit the usefulness of the tool. (And no - it's not 2 lines with 174 duplicate vertices between them). There were also 17 with the error "Vertex within tolerance" but even that doesn't account for the 174 duplicate vertex errors in the UN Dirty Areas. Any ideas?

RobertKrisher

@SusanONeill1 Can you post a screenshot of the complete results of all the errors discovered by the Analyze Network Data tool? The Errors by Type chart gives a good breakdown. I want to see all the errors it discovered, as well as the number of occurences of each error.

SusanONeill1

Robert,

My bad. I was looking at the Error Summary Table, which had 2 records, rather than the Error Location table, which shows a number of errors more consistent with the Dirty Areas. Thanks for your help. I did have to upgrade to 3.5 yesterday since the tool is only available at that version, so I guess I missed the details on the types of info returned by the tool. Thanks again.

RobertKrisher

@SusanONeill1 When looking at the error summary table make sure you look at the occurrences field for each error summary. You should find that when you add the number of occurrences for both of those rows together you will get the correct number (which will match the number of error location features you find).

egcon27

I’m wondering if someone can help me understand what’s happening.

I’m using the Analyze Network tool and then applying the suggested resolutions. When I turn the network topology back on, it shows zero errors. But when I run Analyze again to double check, it keeps finding more Vertex Within Tolerance errors. I apply another round of resolutions, re-run the tool, and it finds even more. Not sure why these aren’t getting picked up the first time.

I’ve tried changing how I apply the actions (anchoring the point and snapping the line, and vice versa), but I still keep getting new Vertex Within Tolerance errors. My guess is that applying the fixes might be shifting other features and creating more issues?

Not sure what’s going on, maybe I should just manually fix the initial errors instead of relying on the tool?
Thoughts? @RobertKrisher

Screenshot 2026-04-02 144519.png

RobertKrisher

Vertex within tolerance will not generate topology errors, but they are data quality issues that can result in problems with tracing and editing.

In terms of applying resolutions not fixing all the errors, that shouldn't be the case, but I can imagine there are some edge cases that the tool may not be able to handle. If there are a relatively small number of them than you may be better off manually resolving them. By doing that you will probably understand why the automated tool is not able to correct them. If you plan on running subsequent migrations, you should also look at correcting the problems in your source database.

Join the Conversation

Signed in members can post, follow updates, and more. New here? Register a free account.

Quick Links

Community Help
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.