Utility network mapping

Utility network mapping is the work that turns a network — power, water, telecom, gas — into structured, traceable, query-able GIS data. The foundation that asset management, planning, fault response, and operational reporting sit on top of.

We deliver utility network mapping for owners and operators across UK and US markets. Geospatial work is delivered through our partner Geodars.

Why network mapping is its own discipline

Most utilities have network records. Most utility network records aren’t fit for purpose:

• Topology gaps — circuits or service lines that can’t be traced because connectivity isn’t modelled
• Attribute drift — fields populated inconsistently, codes changed over time, no controlled vocabulary
• Geometry quality — features located approximately, sometimes off by tens of metres
• Stale snapshots — records that don’t reflect what was actually built years of work-orders ago

Network mapping is the work of turning these into something operations can actually use.

What’s in a network mapping deliverable

A complete delivery covers:

Topology

• Connectivity modelled (assets that should be connected actually are)
• Traceability (you can follow a circuit, a feeder, or a service line end-to-end)
• Hierarchy (parent/child relationships where the network has them — substations to feeders to services)

Attribution

• Schema aligned with industry standards (Esri Utility Network model, IEC CIM for power, OGC standards generally)
• Controlled vocabularies for asset types, statuses, condition codes
• Required fields actually populated; optional fields flagged
• Provenance — where each attribute came from

Geometry

• Located against accurate base mapping
• Snap discipline — assets that should connect snap exactly
• Quality flagging where source data was approximate

Data quality reporting

• Pre-mapping baseline state
• Post-mapping state with explicit changes
• Remaining issues flagged with severity

Industries we work in

• Power utilities — transmission, distribution, substations, switchgear
• Telecom networks — fibre, copper, splice points, cabinets, equipment
• Water utilities — pipes, valves, meters, pumps, treatment
• Gas networks — pipes, regulators, valves, meters
• Multi-utility — where multiple networks share the same spatial substrate

For each, the data model conventions and standards differ, but the underlying engineering — getting topology right, getting attribution clean, getting geometry honest — is similar.

Inputs we typically work from

A network mapping engagement runs on:

• Existing records — whatever shape they’re in, paper drawings, scattered spreadsheets, legacy GIS, asset management systems
• Authoritative as-builts where they exist (often partial)
• Field surveys to fill gaps where existing records are inadequate
• Industry standards — the data model the output should conform to
• Integration targets — what systems will consume the mapped network

Where existing records are particularly poor, the mapping work includes a re-survey component — at meaningful additional cost, but unavoidable when records can’t be relied on.

Output formats and platforms

We deliver to whichever platform the operator runs:

• PostGIS — for organisations on the open-source GIS stack
• Esri Utility Network — for ESRI-stack utilities
• Esri Geodatabase (legacy) — where migration is to ArcGIS but not to Utility Network model
• Hybrid — where authoritative data lives in one system but feeds others

Common pitfalls in outsourced network mapping

Topology not actually validated. Mapped data that visually looks right but fails connectivity tracing isn’t useful. We validate topology by running the queries operations will need to run — circuit traces, service tracebacks, connectivity checks.

Attribute backfill from assumptions. Filling in missing attributes by assuming values to satisfy a “complete” data quality metric produces records that look complete but aren’t. We flag missing data rather than fabricating it.

Geometry snapped naively. Snapping that doesn’t preserve real-world relationships (e.g. parallel power and comms cables that run together) produces data that looks tidy and doesn’t reflect reality. We snap deliberately.

No path to currency. Mapping projects that produce a one-off snapshot without operational handover decay quickly. We build the field-data-flow-back path so the mapped network stays current.

Compliance and standards for utility network mapping

Utility network mapping isn’t purely a data engineering exercise — every deliverable sits inside a compliance envelope defined by regulator, operator, and industry standards. Get the compliance frame wrong and the mapped network passes internal QA but fails audit, funder review, or the operational system it’s meant to feed.

Regulatory and jurisdictional compliance:

• US electric utilities — FERC Order 693 (reliability standards), NERC CIP for critical infrastructure protection where the network holds bulk-electric-system data
• US water and wastewater utilities — EPA reporting requirements, state PUC data standards varying by jurisdiction
• US telecoms — FCC Form 477 broadband reporting alignment, BEAD serviceable-location data structure where federal funding applies
• UK — NUAR (National Underground Asset Register) submission format for underground utilities, DFT/OS data standards where highway crossings apply
• EU — INSPIRE Directive data specifications for spatial datasets held by public bodies

Industry data model standards:

• Esri Utility Network — the current canonical model for utility mapping in the Esri stack (electric, gas, water, telecom domain templates)
• CIM (Common Information Model) — IEC 61968 / 61970 for electric utility data exchange
• OGC standards — WMS, WFS, GeoPackage, SFS for interoperability requirements
• NENA i3 — for utility network data feeding 911/next-generation-911 systems

Operator-specific compliance layers:

Each utility owner layers its own compliance requirements on top: naming conventions, attribute controlled vocabularies, drawing standards for extract outputs, audit trail requirements for edits. A network mapping deliverable that meets NERC CIP but violates the utility’s internal drawing standard gets returned.

How we handle compliance:

Every mapping engagement starts with a compliance scan — identify every applicable regulator, industry standard, and operator-specific layer up front. We build the schema and workflow to satisfy all layers rather than discovering one late. Audit trail requirements are designed in from the start rather than retrofitted.

Typical timelines

• Single-area mapping (e.g. one substation feeder, one fibre exchange catchment) — 4-12 weeks depending on scale
• Mid-sized network (utility cooperative or regional segment) — 12-32 weeks, typically phased
• Large utility programme — multi-year, programme-managed

Re-survey for inadequate baseline records adds substantial time at the front.

How we deliver

Geospatial work runs through our partner Geodars. The team has direct experience with utility network mapping, telecom asset records, and migration to modern GIS platforms.

Related reading

For the wider picture — how network mapping fits the operational GIS lifecycle across telecom, electric, gas, water, and municipal right-of-way — see our field guide, GIS as the Operational Layer for Utility and Telecom Networks. It covers system-of-record thinking, the data lifecycle, and how mapping feeds design, 811, and O&M.

Talk to us about a network mapping project

Tell us the network domain, the geographic scope, the existing record state, and the target platform. We’ll scope and discuss approach. Network mapping work nearly always warrants a scoping call given the variability of input data.