An asset map tells you where pipes and valves are recorded. A connected network must also describe how they relate and which conditions affect movement through the model. If the question is “what connects to this pipe?”, nearby points and lines are not enough on their own.
ArcGIS Utility Network provides a framework for representing utility assets and their network relationships. This guide concerns data readiness for that model. It does not replace hydraulic analysis, field verification or an operator's procedures.
Separate the questions before choosing the data work
A valve inventory supports tasks such as finding a recorded valve or linking an inspection to its identifier. A network question asks which pipes are connected through that valve and what the model should do under a defined condition.
Both are useful. A team whose immediate need is a reliable inspection register may sensibly start with identity and location. A team proposing network traces must establish more than a clean-looking map.
A small example exposes the missing relationship
Consider this synthetic review case. Pipe P1 runs from a source to junction J1. P2 connects J1 to a facility. P3 connects J1 to another branch. Valve V1 is drawn beside P2, but its relationship to the pipe has not been confirmed.
| Record | What the map shows | What remains to be established |
|---|---|---|
| P1 | Line between source and J1 | That both ends represent the intended connections |
| P2 | Line between J1 and facility | That the facility relationship is correctly recorded |
| P3 | Another line meeting J1 visually | Whether the apparent meeting represents an actual connection |
| V1 | Valve point beside P2 | Whether it belongs to P2 and how it is represented in the model |
| V1 status | Blank value | Whether the state is unknown, unrecorded or awaiting confirmation |
A tempting shortcut is to assign V1 to the nearest pipe and fill the blank with a default. That turns two unknowns into apparently confident data. The more useful output is an exception record: V1's relationship and state need confirmation by the utility's responsible data owner.
Suppose a drawing review confirms V1 belongs to P2, but its current status remains unknown. The team can resolve one issue without pretending to resolve both. Keep the status question open and record the source and date of the relationship correction.
Connectivity and trace configuration are different checks
A connected relationship does not, by itself, specify every rule a trace should apply. Esri's trace documentation distinguishes trace types and configuration, and explains the importance of validated network topology. An edit can leave an area needing validation; a plausible map is not proof that the model is ready for analysis.
For a proposed trace, write down the starting location, the question, relevant conditions and the expected treatment of unknown values. Have the responsible specialist confirm the appropriate model and configuration. Do not present a synthetic example as a tested isolation result or an instruction to operate a real valve.
Build an acceptance register around exceptions
Use the following entries to scope a small preparation exercise, rather than trying to repair the entire network at once.
| Acceptance item | Example evidence | Action if unresolved |
|---|---|---|
| Stable identity | P1, P2, P3, J1 and V1 each map to an approved record | Resolve duplicates before joining other records |
| Relationships | Approved source confirms the modeled connections | Keep ambiguous connections in an exception list |
| Relevant state | Value, source and review date recorded for the intended question | Preserve unknown status and refer it to the owner |
| Model consistency | Specialist reviews validation results and relevant errors | Correct and revalidate before relying on the proposed analysis |
| Result interpretation | Reviewer explains inputs, assumptions and limits | Revise the question or configuration before acceptance |
This register is an editorial planning example, not an Esri certification checklist. Its benefit is to show exactly what must be resolved and who can resolve it.
Connect the network model to maintenance without confusing them
An inspection can provide evidence about an asset. A work order records an action. Neither automatically establishes every network relationship. Maintain consistent identifiers so these records can inform each other while keeping their meanings clear. Our valve inspection and maintenance guide addresses that separate operational record, while the service request, inspection and work order comparison explains the handoffs.
For an initial discussion, bring a small representative area, the question your team needs to answer, sample asset records and known exceptions. Discuss water-network GIS with InfoGraph, explore GIS services, or review training options for the people who will maintain and review the model.
