Water Utility Traces Stop at the First Valve After Migration
A water district has migrated 18,400 valves, 2,100 miles of main, and six pump stations from a geometric network into a utility network in an enterprise geodatabase. The data sits in one feature dataset and branch versioning is enabled. Asset groups and asset types exist, but almost every valve is assigned the asset type 'Gate Valve - Unknown' with terminal configuration 'None.' No connectivity rules were created for valve-to-main or main-to-main connections. Network topology was built without errors, and editors can snap a new main to a valve. When a GIS analyst runs a downstream trace from Pump Station P-3, the trace returns the pump and the first main segment, then stops at the first valve. A second trace from a hydrant 2,000 feet downstream returns only the hydrant. The utility wants to avoid re-importing all features.
1. Both traces stop after the first device or feature. Identify the two configuration gaps most likely responsible and explain how each one interrupts trace propagation. Which gap would you verify first, and what evidence would confirm it?
Read the worked answer
The two gaps are missing terminal configuration and missing connectivity rules. A valve with terminal configuration 'None' has no terminals, so the utility network cannot create an internal path through the device. The trace can reach the valve but cannot leave it, which matches the first trace stopping at the first valve. Even if terminals existed, absent connectivity rules mean the topology build has no allowed valve-to-main or main-to-main association. The trace therefore has no downstream edge to follow, so a hydrant beyond that point is returned as an isolated feature. I would verify terminal configuration first because rules are defined at terminal level; without terminals, the rules cannot be authored correctly. Evidence would be the valve asset type properties showing 'None,' validation errors or dirty areas around the first valve, and a trace that reaches the valve but produces no downstream features. A quick test is to inspect the network topology around the valve for connectivity associations; if none exist, the trace behavior is explained.
2. Propose a remediation sequence that preserves the 18,400 existing valves and minimizes downtime. Include the order of operations and at least two validation checks.
Read the worked answer
Preserve the features and change the model around them. First inventory valve attributes and split the single 'Gate Valve - Unknown' type into meaningful asset types, such as gate, butterfly, and pressure-reducing valves, using existing size and type fields. Second assign a two-terminal configuration to in-line valve asset types so existing features inherit terminals. Third create connectivity rules between valve terminals and main asset types, including the normally closed bypasses where appropriate. Fourth rebuild or validate network topology in a pilot district, not the whole system. Fifth update affected subnetworks and run representative traces. Validation checks: (1) validation error count is zero and no unexplained dirty areas remain in the pilot district; (2) a downstream trace from Pump Station P-3 reaches the hydrant 2,000 feet away and matches the known geometric-network result. Minimize downtime by doing the work in a named version, testing on one district, and using attribute rules to assign asset types rather than manually editing thousands of valves.
3. The topology build reported no errors. Why is that not proof that the network is traceable?
Read the worked answer
A topology build without errors only means that the build process completed and did not flag validation errors for the rules that exist. It does not prove that every intended connection is represented. If connectivity rules are missing, the build may simply create no edge between a valve and a main; that absence can be silent because there is no rule to violate. A device with no terminals can also be present without generating a build error, yet it cannot carry a trace. Traces depend on connectivity associations, terminals, and network attributes, not on the absence of error features alone. The correct proof is a known-answer trace compared with field records or the old geometric network, plus inspection of connectivity around key devices. 'No errors' is a necessary check, not sufficient evidence of traceability.