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.

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.

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.

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

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.

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.

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.

The post Repairing Invalid Geometries appeared first on Blair Services.

“Trace returned no results”

I’ll start out with a favorite, a trace that returns the message “Trace returned no results.” Actually, there are many reasons why this occurs. For now I’ll focus on one particularly vexing condition, the full set of symptoms are as follows:

• Perform a downstream trace on a feeder just upstream of a transformer. The expected result are returned, including primaries, transformer(s), secondaries and service locations.

• Perform a downstream trace initiated at the transformer itself (one included in the previous trace results). The result is the message “Trace returned no results.”

How could this be? The first trace, which completed successfully, was a “superset” of the second trace, which returned no results. Shouldn’t a trace performed within the bounds of a previously performed successful trace also be successful? Clearly not necessarily.

Here’s the difference. The first trace process started on a primary line with a valid geometry, got the geometric network EID from the line feature and dove into the logical network (LN) obtaining “forward star” cursors within the network until it completed. When trace limits were found in the logical network the set of traversed EID’s were returned and used to select and/or highlight corresponding features.

The second trace started at the transformer junction feature and examined each connected conductor (primary and secondary) to determine where to proceed. If we look closely at the secondary line we can start to see the issue. Vertices 0 and 2 occupy the same X,Y location, which ArcGIS considers to be a “loop” and which makes the geometry invalid for a geometric network edge.

When the trace process tried to inspect this edge feature it encountered the invalid geometry and failed at that point. It never got into the logical network to begin its “forward star” querying process. Thus the trace returns a “returned no results” message.

In contrast, the first trace got from the feature into the logical network without problem and traced to and through the transformer and secondary while in the LN and returned results as expected.

“Case of the Step-down Transformer”

This case was initially puzzling because the trace started on a primary conductor and stopped at a step-down transformer which on the low side had other primary voltage conductors. The transformer and primaries are all connected, but under no condition would the trace proceed beyond the step-down transformer. It’s as if the step-down transformer were acting like an open switch.

Puzzling all the more because when we perform a trace in a similar condition when the primary on both sides of a standard distribution transformer are the same voltage we get the expected results. The transformer is traced, as is the downstream secondary and the downstream primary. So, what gives?

After a little rumination it’s clear that, though the 12 kV line downstream of the step-down transformer is a primary voltage, it’s a different voltage than the primary on the source side. And in this case different matters. When the first trace hits the transformer and examines the transformer’s connected phases – in this case it’s connected to ‘B’. Then it looks for connected conductors. Those with a different voltage than the upstream conductor are considered to be on the other side of the transformer and must share a common phase code for power to pass through it. Since the transformer is on phase ‘B’ and the low side primary is at 12.0 kV rather than 20.78 kV and since the low side primary is on phase ‘C’ the trace stops.

Now, this is also probably a data issue and the transformer (and possibly to low side conductor) phasing may not be correct.

“Secondary snapped to a primary without a transformer”

This one seems pretty straightforward – when you finally find it. But tracking it down can be a chore. The issue, as illustrated below, is where a secondary ends up getting snapped to a primary where it shouldn’t. The case below is a relatively dramatic one in that the secondary ends up connecting two separate feeders otherwise separated by a normal open, but the case where the secondary snaps directly to a primary that part of the same feeder also creates a loop – and creates a problem.

Of course, all elements in the above scenario would be considered to be in a “multi-feed” condition. Use of the ArcFM “Bit Twiddler” layers can be of some help in this case. Also helpful can be use of ArcGIS connectivity rules. In this case the connection of a secondary to a primary at a “generic junction” would violate the connectivity rule and return a QA error.

The post Why Did My Trace Do That? appeared first on Blair Services.