Repairing Invalid Geometries

When loading data from other geographic sources into ArcGIS you can quickly learn about expectations different systems have about feature geometry definitions, especially when dealing with geometries that are to become part of ArcGIS geometric networks. Geometries that are valid in other systems or for other purposes are not always so for geometric network features. Luckily for us, our friends at Esri have as of version 10.2 provided a new Geoprocessing tool, “Verify and Repair Geometric Network Connectivity” to help detect and resolve many of these cases.

Self-Intersecting Line Example

We’ll use what is a pretty typical example of a case that can result in an invalid network feature geometry. As illustrated to the right the case is where a line geometry doubles back on itself and becomes “self-intersecting.” In our simple example we’ll look at a case where a three-vertex line begins at vertex 1, proceeds to vertex 2 and ends at vertex 3, which falls on the segment defined from vertex 1 to vertex 2. In addition, as is also often the case, we have a junction feature snapped to vertex 3.

Repairing_Geometries_1Repairing_Geometries_2

This might be an electric transformer, a gas or water tap feature or a fiber optic cable splice point. The same condition would apply across the board. When we create a geometric network from these features a fourth vertex is introduced – between vertex 0 and (what was) vertex 1 and coincident with (what was) vertex 2.

Repairing_Geometries_3

This in and of itself would not necessarily be an issue, however when we try to edit our edge feature in ArcFM/ArcMap we find that there is an issue. Namely, we can’t modify the edge feature geometry. The line thinks its connected to the same junction at two distinct vertices, which isn’t valid. If we explore further there would potentially other problems such as certain trace operations not returning expected results.

Repairing_Geometries_4

So, now what? Well, we could repair the individual feature within our ArcFM/ArcMap session by any of the following steps:

  1. Delete and re-add the feature (yikes!)
  2. Disconnect the feature using the (ArcFM) Disconnect tool, repair the geometry and re-connect it with the (ArcFM) Connect tool
  3. Use the “Geometric Network Editing” toolbar “Rebuild Connectivity” tool

Repairing_Geometries_5

All of these methods would work, but the onus would be on a map editor. If there are a small number of these cases in your database this may be a reasonable approach, but in data migration there may be many such cases. It would seem there should be a better way.

And that brings us to the “Verify and Repair Geometric Network Connectivity” Geoprocessing tool found in ArcToolbox under “Data Management Tools | Geometric Network”. The tool presents a dialog that asks you to select a geometric network, provide an log file output location and asks if you simply want to diagnose and report network errors or, in addition, to fix them.

Repairing_Geometries_6

If you choose the “Repair Network” option updates are made directly to the geometric network features as needed – no further action required (though it’s probably a good idea to make a backup of your database before running, just in case).

So what would this tool do to resolve our case in question? Here’s a portion of the resulting log file that documents detection of our error and what was done to resolve it. Basically, the line was re-created to avoid connecting our line to our junction in two places.

[8/16/2014 12:15:59 PM] Processing LineFC
[8/16/2014 12:15:59 PM] Error(LineFC): Feature OID=9 has an error in its sub elements chain
[8/16/2014 12:15:59 PM] Recreating Edges (1)
[8/16/2014 12:15:59 PM] Warning(LineFC): Junction connected at coincident vertices avoided on Edge ClassID=302, OID=9
[8/16/2014 12:15:59 PM] Deleting invalid EIDs (2)

What does this look like back in our map? The first thing we see is that we can edit the line with normal editing tools and no error message – a relief. The second thing we notice is that the repair process didn’t change the geometry of the line at all. All four vertices that were present at the time the geometric network was created are still present in our current line, including the coincident vertexes (vertex 1 and vertex 3 from above.) All the repair process did – as we would want it to – is to connect the junction to just one of the coincident vertices, not to both, and as a result permit normal use of the data for map editing or analysis purposes.

Repairing_Geometries_7Repairing_Geometries_8

At this point we may say our work is done here. This may be as much as we would want any automated process to perform. If, on the other hand we could say with high confidence that the segment to the west of our junction was completely extraneous, likely the result of a digitizing error in our source system or some similar condition, then we may want to detect and eliminate coincident segments within a given line geometry. But that would be a topic for another Tips and Tricks discussion.

 

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>