Your City Already Publishes Its Utility Maps. Here's How Field Crews Finally Use Them — and Make Them Better.

Over the past fifteen years, something quietly remarkable happened in local government: cities, counties, and utility districts put their infrastructure maps online. Not as scanned drawings — as live feature services: web endpoints (ArcGIS feature services, WFS, and open-data portals) that serve the actual mapped geometry of water mains, sanitary and storm sewers, hydrants, manholes, and valves, with whatever attributes the GIS department keeps on them. Anyone with the URL can query them.

The catch is that almost no one on a job site has the URL. The data was published for GIS analysts at desks, and that is largely where it stayed. The crew opening the ground — the people with the most immediate, physical need to know what is down there — mostly never see it.

What's actually out there

We went looking. Digital ROW Utilities (DRU) now carries a catalog of more than 5,700 verified public utility map services spanning all 50 states: about 1,350 curated sources bundled with the app, plus a community tier of roughly 4,400 more, hosted on our CDN and fetched on demand. It is a living catalog — an automated discovery pass adds newly published services monthly (July's sweep alone verified 73 new ones), a weekly health check flags endpoints that move or go dark, and users can submit sources we missed or report ones that broke.

What is in them tells you a lot about who publishes. Sewer, storm, and water dominate — that is municipal public works, and those departments own both the assets and the GIS. Hydrant layers show up in numbers (your fire department thanks the water utility), manholes and valves likewise. Electric, gas, and fiber are much thinner on the ground, and part of that is real: those networks are largely privately owned, and their owners understandably do not publish them. But part of it was us. An earlier version of our discovery pass searched only for water and sewer vocabulary, so municipal electric, street-light, conduit, and fiber services were being skipped rather than found to be absent; correcting that turned up several hundred we had never seen. It is a useful reminder that a catalog measures the search as much as the territory. The publishers themselves run from McAllen, Texas to Marysville, Washington to Ankeny, Iowa: not just big-city GIS shops, but small towns and rural utility districts that put their systems online because it was the right thing to do with public infrastructure data.

Good maps, one-way street

Spend time in these layers and two things become clear. First, they are genuinely useful — knowing a 12-inch main crosses the alignment thirty feet ahead changes how you dig, even if the line's position is approximate. Second, they have a shared ceiling. Most public utility layers can tell you a line exists and roughly where it runs. Far fewer can tell you how deep it is, what it is made of, when it was installed, how the position was measured, or how much to trust it — the attributes that standards like ASCE 75-22 (as-built documentation of underground utilities) and the SUE quality-level framework exist to pin down.

That ceiling is not a GIS department failure. It is a capture failure. The data in the public layer is only as good as what came back from the field when the asset went in the ground — and what comes back from the field is usually a redline on a paper plan, weeks later, drawn from memory. The public map inherits every gap in that chain. And because the layer is read-only to everyone outside the GIS department, the thousands of people who stand in open trenches looking directly at the real answer have no way to contribute it.

What DRU does with the catalog

The first half of the fix is distribution: put the public layer where the work is. Open DRU in the field and the catalog is ranked by true distance from where you are standing — the nearest city, county, and district services first, not an alphabetical list thousands of names long. Tap one and the mapped lines and structures draw over your position; walk the site and you can view them in augmented reality, overlaid on the ground in front of you at real-world scale. If your agency or client runs its own private endpoint, add it alongside the public ones — user-added sources are first-class and never silently dropped.

One design decision worth stating plainly: DRU only queries these services when you ask it to. There are no background sweeps, no location beacons to third-party servers — the endpoints belong to their publishing agencies, and the app touches them on explicit user action, full stop.

Sending better data back

The second half is the interesting one: closing the loop. DRU is, at its core, a field as-built capture tool. When a crew installs, exposes, or locates an asset, the capture carries what the public layer is missing — position with full GNSS fix provenance (how the fix was obtained, and to what claimed accuracy), measured depth, material, size, owner, install and collection dates, geotagged photos of the open trench, and a SUE quality level with its justification. A built-in validation gate checks every capture against the ASCE 75-22 attribute set before it goes anywhere, and blocks publishing on hard errors rather than exporting a pretty but incomplete record.

Where does that better record go? Into the owner's own GIS. DRU publishes directly into an organization's ArcGIS layers — add, update, and delete, with a field-mapping editor that matches DRU's attributes to the layer's schema and warns before any mandatory ASCE attribute would be dropped on the floor. For agencies that ingest records manually, a one-tap deliverable package bundles the GeoJSON, a PDF report, inspection records, and a checksummed manifest into a single submittal. Either way, the loop closes: the crew that consulted the public layer on Monday is improving it by Friday — and the next crew inherits a map with depths, materials, and honesty about accuracy.

The catalog itself improves the same way. Every submitted source, every broken-endpoint report, and every monthly discovery run grows and prunes the shared list — the community tier updates on our CDN without waiting for an app release.

The same right-of-way: where DTCD comes in

Almost none of this work happens in a vacuum. An open trench in the right-of-way means lane closures, flaggers, advance signs — traffic control, with its own documentation duty. That is the job of our other product, the Digital Traffic Control Diary, and the two are built to work as one platform because in the field they are one event.

From a DRU project you can search your organization's existing DTCD traffic-control records and link one to the capture session — or create the DTCD project from inside DRU, with the permit number, utility company, and utility type carried over so nobody types them twice. Status stays synced, and deep links jump between the apps. One field event, two records, each in its proper system: the as-built flows to the GIS and the project file; the traffic-control diary becomes the defensible work-zone record — and feeds the live WZDx data that 511 systems and navigation platforms consume. A DTCD team subscription also unlocks DRU's team tier — ArcGIS publishing, deliverable packages, and QA review — one account across the platform.

If that thesis sounds familiar, it is the same one behind everything we build: the data everyone downstream wants has to be captured where it is created. For work zones, that is the crew placing the cones. For the underground, it is the crew standing over the open trench. The public utility map layer America already built is a remarkable head start. The people who can finish it are already on site.

Catalog figures are read live from the community catalog where your browser supports it (otherwise shown as of July 2026) and change as discovery and maintenance runs execute. Public endpoints belong to their publishing agencies; coverage, licensing, attributes, and update cadence vary by publisher, and public layers are reference data — not a substitute for One-Call/811 notification or utility locating required by law. DRU queries public services only on explicit user action.