Manhole Asset Management GIS Data Model: Field Guide
Dana Whitfield manages the GIS for a wastewater utility with 9,000 manholes. When her director asked which covers were past their design life and sitting on arterial roads, she had the answer in about four seconds.
A neighbouring utility with a similar asset count needs four days for the same question, and the answer arrives with caveats attached. The difference isn’t the sensors. It isn’t the software either. It’s the manhole asset management GIS data model underneath both.
Most manhole layers started life as drawing cleanup, not as an asset register. They hold a point, a Facility ID, and little else that supports inspection, condition, or risk. That works fine until someone asks a question the layer can’t answer.
This guide is the field-level specification those layers are missing. You’ll get the feature class and its attributes, the subtypes and coded-value domains that make reporting possible, the rules that decide what belongs on the asset record versus a time-series table, how NASSCO MACP condition data maps into the schema, and the migration order that avoids mistakes which are expensive to undo.
Building or rebuilding a manhole layer? See the Black Ant smart manhole cover range that writes field data into these schemas.
What Is a Manhole Asset Management GIS Data Model?
A manhole asset management GIS data model is the structured definition of how manhole assets are stored in a geographic information system: the feature class, its attribute fields and data types, the coded-value domains that constrain those fields, the relationships to connected pipes and inspection records, and the rules that keep the data consistent over time.
That’s easy to write and easy to ignore. What matters is that a working model carries three layers. Most manhole layers carry only the first.
| Layer | What it holds | What breaks without it |
|---|---|---|
| Spatial | Point geometry, coordinates, spatial reference | Nothing maps, nothing traces |
| Descriptive | Identity, physical structure, elevations, ownership | No reporting, no condition analysis |
| Temporal | Installation, inspection history, live telemetry | No trends, no risk scoring, no early warning |
A map layer answers “where.” A sewer GIS data model answers “where, what, in what condition, and what is happening right now.” The distance between those two questions is the whole cost of a retrofit, and it’s wider than most teams expect.
The payoff is measurable. The EPA attributes 25% to 60% of sewer flow to infiltration and inflow, and up to 90% of that inflow enters at manholes. You can’t rank which manholes without structure-level elevation and condition data already in the register.
The Four Questions the Model Must Answer
Every design decision in this guide traces back to one of four questions. If your model answers all four, it will survive contact with procurement, engineering, and operations.
- Where is the asset, and how accurately was that location established?
- What is it, physically, and when was it built?
- What condition is it in, and how do we know?
- What is happening inside it right now?
Most legacy layers answer the first question well, the second partially, and the last two not at all.
The Manhole Feature Class: Fields That Belong in Every Model
What Attributes Does a Manhole Feature Class Need?
A manhole feature class needs 22 attributes. Most are domains or doubles; only three are strings.
| FIELD NAME | DATA TYPE | LENGTH | DESCRIPTION | REQUIRED |
|---|---|---|---|---|
| FACILITYID | String | 20 | Locally assigned unique asset ID; the join key for everything else | Yes |
| LEGACYID | String | 30 | Pre-migration drawing or paper reference | No |
| MHTYPE | Domain | n/a | Manhole type by size and shape | Yes |
| WALLMAT | Domain | n/a | Brick, block, concrete, or lined | Yes |
| CVTYPE | Domain | n/a | Cover and frame type | Yes |
| DEPTH | Double | n/a | Rim to invert, measured or derived | Yes |
| DIAMETER | Double | n/a | Internal barrel diameter | No |
| RIMELEV | Double | n/a | Rim elevation | Yes |
| INVERTELEV | Double | n/a | Invert elevation at each connection | Yes |
| HIGHELEV | Double | n/a | High pipe elevation, used for drops | No |
| FLOWDIR | Domain | n/a | Flow in, out, or unknown | Yes |
| WATERTYPE | Domain | n/a | Sanitary, storm, or combined | Yes |
| INSTALLDATE | Date | n/a | Date the asset was installed | Yes |
| CONDITION | Domain | n/a | Current condition grade | Yes |
| INSPDATE | Date | n/a | Date of the most recent inspection | No |
| GPSDATE | Date | n/a | Date the location was captured | No |
| SPATIALACC | Domain | n/a | How the coordinate was established | No |
| OWNEDBY | Domain | n/a | Owning organisation | Yes |
| MAINTBY | Domain | n/a | Maintaining organisation | Yes |
| ACTIVEFLAG | Domain | n/a | In service, abandoned, or removed | Yes |
| LASTEDITOR | String | 50 | User who performed the last update | No |
| LASTUPDATE | Date | n/a | Timestamp of the last update | No |
Twenty-two manhole asset inventory attribute fields is no accident. Each one answers a question someone will eventually ask. Backfilling a missing field later costs more than adding it now.
The field list above is a working specification. It draws on schemas published by municipal GIS departments, the Autodesk wastewater manhole feature class, and Esri’s utility network foundation.
Field names follow the conventions those systems already use. That matters more than it sounds. Rename a field after go-live and you’ll break every downstream report, dashboard, and integration that touched it.
Why FACILITYID Is the Only Truly Load-Bearing Field
FACILITYID is the anchor that inspections, work orders, telemetry, and CCTV records all point at. Change it and every one of those joins breaks silently. Duplicate it and records attach to the wrong asset. Nobody notices until a crew is sent to the wrong street.
Two rules protect it. Assign IDs by a documented convention before the first feature is created, and never reuse an ID after an asset is retired. Then treat FACILITYID as immutable once published. If your naming standard has to change, add a new field instead of rewriting an existing one.
The Elevation Decision That Shapes Your Connectivity Rules
Rim elevation and invert elevation make a manhole useful for anything hydraulic. RIMELEV is straightforward. INVERTELEV isn’t, because a manhole has one invert per connection, and schemas disagree on where those values belong.
One approach stores them on the manhole as numbered fields, such as INVERTELEV1 through INVERTELEV3. Another stores them on the pipes and derives the manhole value from its connections.
Both work. They just behave differently. A pipe-based model lets a trace calculate downstream depth without reading the structure. A manhole-based model is faster to populate from field survey sheets.
Pick one before migration. Switching later means re-surveying, and you’ll re-survey because the two models disagree about which asset owns the measurement.
Subtypes, Asset Groups and Domains: Where Models Fail
Free-text fields are the single most common defect in municipal manhole layers. A CONDITION column that accepts “good”, “OK”, “Gd”, and “grade 2” isn’t condition data. It’s a comment field wearing a costume. Coded-value domains and subtypes are how a schema prevents that outcome.
Subtypes and Asset Groups in the ArcGIS Pro Utility Network Model
In the Esri ArcGIS Pro utility network feature classification, manholes are junction features, and classification runs on two fields. ASSETGROUP is the major classification and must serve as the subtype field for the class. ASSETTYPE is the minor classification, refined by an attribute domain assigned at the subtype level.
A practical manhole taxonomy looks like this. The asset group splits gravity manholes, pressure manholes, and cleanouts. ASSETTYPE then separates variants beneath each group, such as cover class, wall construction, or depth band.
| ASSETGROUP | ASSETTYPE examples | Typical use |
|---|---|---|
| GravityManhole | Standard, Drop, Junction chamber | Sanitary and combined collection |
| PressureManhole | Valve chamber, Air release | Force mains and pump discharge |
| CleanOutManhole | Terminal, Midline | Lateral and small-diameter reaches |
This structure is what makes reporting possible. Group the network by ASSETTYPE and you can answer “how many drop structures are past 40 years old?” without a fuzzy text search.
Coded-Value Domains Worth Building on Day One
Domains constrain a field to a known list, which makes every downstream count reliable. The eight below cover the questions municipal reporting actually asks.
| Domain | Field | Values |
|---|---|---|
| Manhole type | MHTYPE | Structure shape and size classes |
| Wall material | WALLMAT | Brick, block, concrete, lined |
| Cover type | CVTYPE | Cover and frame classes |
| Cover grade | CVTYPE | Flush, below, above finished surface |
| Condition grade | CONDITION | Program-defined condition bands |
| Ownership | OWNEDBY, MAINTBY | Organisation list |
| Water type | WATERTYPE | Sanitary, storm, combined |
| Lifecycle status | ACTIVEFLAG | In service, abandoned, removed |
Building all eight at design time costs an afternoon. Retrofitting them onto 9,000 free-text records costs a field season.
What Are the Design Rules for Manhole Subtypes and Domains?
People find these rules too late, mid-migration, when undoing them means rebuilding.
- The asset type attribute domain must use a short-integer field type.
- Codes and subtype values can’t exceed 1,023.
- Subtype codes become immutable once network topology is enabled. Esri enforces this. It surfaces as error 002140 when you try to change or delete one.
- Domain split policies need a deliberate decision. Duplicate is the default for asset type, but set the split policy for every other domain on purpose.
- Never let CONDITION, WALLMAT, MHTYPE or CVTYPE accept free text. Each one carries a coded-value domain from day one.
- Assign ASSETTYPE domains at the subtype level, not at the feature-class level, so values don’t drift outside their ASSETGROUP.
- Publish a data dictionary naming the domain owner and the change-request path, so taxonomy additions don’t become ad-hoc edits mid-migration.
Rule three is the one that breaks projects. Lock the taxonomy before topology, not after.
Manhole Asset Management GIS Data Model vs. Utility Network Data Model
There’s a real decision here, and it isn’t about ambition. It’s about what your operators need to do with the network.
When a Feature Class With a Geometric Network Is Enough
If your requirements stop at inventory, mapping, and condition reporting, a plain feature class with domains will carry you. You get attribute integrity, straightforward editing, and no topology overhead. Mid-sized utilities maintain perfectly serviceable manhole layers this way for years.
When You Need the Esri Utility Network
Move up when operators need to trace connectivity and answer questions like “what is downstream of this blockage?” That capability lives in topology, and topology changes the data model in ways that reach back into your attribute design.
Manholes become structure junctions. Mains become lines. Containment and association replace the simple relationship classes you may have hand-built.
Esri ships an ArcGIS Utility Network Foundation asset package for wastewater that already encodes the industry model. Start from that package and extend it. Fork it and you own the maintenance forever.
Connectivity and Containment Rules for Manholes
The utility network brings rules that a plain geodatabase doesn’t enforce, and they behave better than you’d expect.
| Rule | What happens |
|---|---|
| Channel containment | A manhole channel is contained within its structure junction. Esri’s foundation ships a batch attribute rule that creates the channel when a manhole is added. |
| Snap to manhole | A main that snaps to a manhole channel is pulled back roughly two feet. A connection point is added and associated to the channel. |
| Open-end detection | A manhole on a main is not an endpoint, and the network treats a structure with only one connection as suspect. |
That last rule is quietly valuable. Orphaned connectivity stops being a cleanup task and becomes a data-quality flag your schema raises on its own.
Making the Static Model Dynamic: IoT Sensor Telemetry in the GIS Schema
This is where most municipal models stop and most smart city programmes start. That order is backwards, and it shows up a year later. The manhole asset management GIS data model has to decide, in advance, where live data lives.
Priya Raman, an asset manager for a city of 400,000, found out in 2025. A contractor swapped 60 failed manhole devices over one summer. Nobody updated the device registry.
Telemetry from those 60 manholes kept arriving, and it kept attaching to the old records. Her flood risk report flagged three locations as high risk when the alerts had come from a street two kilometres away.
The Design Question: Asset Record or Related Table
The rule is simple. If you’ll ever chart it, it doesn’t belong on the feature class. When an operator asks “what was the water level here last Tuesday?”, that question has to hit a related table. That’s the dividing line.
| Belongs on the asset record | Belongs in a related table |
|---|---|
| Device ID | Tilt angle history |
| Last communication time | Water level history |
| Battery state | Gas concentration history (CH₄, H₂S) |
| Threshold configuration | Alarm events and acknowledge state |
| Last known alarm state | Every individual reading |
The left column holds one value per asset, overwritten as it changes. The right column holds a time series that grows without bound. Putting a time series on a feature class is how a 9,000-row table becomes a 40-million-row table and stops opening.
The Device Registry: The Most-Skipped Table in City IoT
A sensor event is worthless without a FACILITYID to join on. The table that connects them is the one teams forget.
The pattern that survives hardware churn is a device registry keyed on device ID, with FACILITYID as a foreign key and a pair of date fields recording when the device was installed and removed. When a device is swapped, you close the old row and open a new one. History stays attached to the right asset, and you can answer which device produced which reading two years ago.
Priya’s problem was never the sensors. It was a missing row.
If you’d rather not invent that interface from scratch, the OGC SensorThings API defines a standard model for exposing sensor observations, and it maps onto the asset-registry pattern without much adaptation.
Time-Enabled Layers and Alarm Triage
Once telemetry lives in a related table, two capabilities follow. Time-enabled feature layers let you replay a storm event and watch levels rise across the network minute by minute, the same pattern sewer flood prevention monitoring uses to trigger pre-emptive action. Alarm triage fields let a crew see what fired, how severe it was, when it cleared, and who acknowledged it, without reading a log file.
What the Hardware Must Provide for the Model to Work
The schema sets the requirements. The hardware has to meet them. A smart manhole cover event has to carry a device ID, a UTC timestamp, a WGS84 position, tilt, water level, gas readings, battery state, and signal strength. Miss one and a step in the pipeline breaks.
Black Ant’s stack maps onto this cleanly. The IP68 smart manhole cover sensor set reports tilt, magnetic status, water level, gas, and temperature/humidity over NB-IoT or LoRaWAN. An IoT data collection terminal aggregates the payloads, and the Edge Data Acquisition Computer classifies alarms locally with 10 to 50 ms of latency before the payload is built. That local step matters, because it means the fields arriving in your GIS are already triaged.
Planning the telemetry layer alongside the schema? Read the GIS integration guide for the REST, MQTT, and batch paths that move the data.
Manhole Condition Data Model: Mapping NASSCO MACP Into Your Schema
Condition is where a manhole model earns its keep. It’s also where North American practice converges. The NASSCO Manhole Assessment Certification Program is the framework municipal tenders name, and it defines more than 230 observation codes.
Tomás Delgado, a GIS lead for a coastal utility, watched a contractor deliver 11,000 MACP inspections in a spreadsheet with 230 columns. Nobody could query it. The data was complete and completely unusable.
The MACP Header Fields and Where They Land
MACP Level 2 header measurements translate into standard GIS attributes without much interpretation.
| MACP header measurement | GIS attribute |
|---|---|
| Rim to invert (outgoing) | DEPTH, or RIMELEV minus INVERTELEV |
| Rim to grade (outgoing) | Surface offset |
| Grade to invert (outgoing) | Invert elevation relative to grade |
| Northing and easting | Geometry, with SPATIALACC recorded |
| GPS accuracy code | SPATIALACC domain value |
Record the GPS accuracy code as its own domain value. It isn’t optional detail. It tells a future reader whether the coordinate is good enough to dig from.
Defect Codes Belong in an Observation Table
Two hundred and thirty observation codes can’t become 230 columns. Model them as one row per defect, with the code, severity, location within the structure, inspection date, and a foreign key back to FACILITYID.
That structure is what makes condition trending possible. One row per defect means you can ask whether the corrosion found in 2021 worsened by 2025, on the same manhole, at the same location within the structure. A wide table can’t answer that question.
Closing the Asset Management Loop
ISO 55000 frames the purpose clearly: an asset management system exists to support decisions, not to archive measurements. In practice that means CONDITION feeds a risk score, the risk score drives a work order, and the work order writes an updated CONDITION when the crew closes it. If any link in that chain is manual, the model decays within two budget cycles.
That loop is also where the money sits. The maintenance cost case is the argument that funds the schema work in the first place.
Building and Migrating a Manhole Asset Management GIS Data Model
Design is the cheap part. It’s the migration that slips the schedule.
The Three-Pass Migration
Move geometry first, mandatory attributes second, and enrichment third. Don’t combine them.
Tomás ran his 11,000-manhole migration in exactly that order over 14 months. Pass one moved geometry and FACILITYID, which gave crews a usable map early. Pass two filled the required fields, which made reporting possible.
Pass three added condition, elevation, and connectivity detail as survey data arrived. Attempting all three at once would have stalled on the first missing survey sheet.
Treat Spatial Accuracy as an Attribute
Record how each feature was located and how accurate that location is. A surveyed coordinate, a differential GPS fix, and a point digitised from a 1974 as-built drawing aren’t interchangeable. The difference shows up when someone trenches in the wrong place. The ASCE 38-02 quality levels give you a vocabulary that engineers already recognise.
The Open-Source Equivalent
Esri isn’t the only target. The same schema runs in PostGIS with a manhole point table, lookup tables in place of geodatabase domains, and a connectivity table replacing network edges. Publishing it back out through GeoServer as WMS and WFS means three departments can consume the model without buying three licences.
For Chinese smart city projects, SuperMap iServer and CIM platforms expect the same field discipline, expressed in a different stack.
Five Failure Modes to Design Against
| Failure mode | Why it costs you |
|---|---|
| Taxonomy locked after topology was enabled | Subtype codes can no longer be changed |
| Condition and material left as free text | Reporting and trending stay unavailable |
| Sensor hardware shipped with no device registry | Telemetry attaches to the wrong asset |
| Survey and GIS coordinate systems mixed | Locations carry unknown accuracy |
| Records migrated with no invert data | Hydraulic modelling can’t be validated |
Every one is cheaper to prevent than to fix. Four of them are schema decisions you’ll make before a single record migrates.
Conclusion: Build the Model Before the Map
A manhole asset management GIS data model isn’t a technicality you settle during migration. It’s the thing that decides whether your utility answers an asset question in four seconds or four days.
The takeaways worth carrying into your next project:
- Lock the subtype taxonomy before enabling network topology, because codes become immutable afterwards
- Build coded-value domains on day one, since retrofitting them onto free-text records costs a field season
- Keep chartable telemetry in a related table and one current value on the asset record
- Model MACP defects as one row per observation, not 230 columns
- Migrate in three passes, geometry first, enrichment last
None of this needs new hardware. It needs deciding what your records mean before you populate them.
If you’re specifying the field layer that feeds your manhole asset management GIS data model, explore Black Ant’s smart manhole cover and IoT data acquisition range, or contact our engineering team for a project-specific schema and hardware recommendation.
Frequently Asked Questions
What is a manhole asset management GIS data model?
A manhole asset management GIS data model is the structured definition of how manhole assets are stored in GIS: the feature class, its attribute fields and data types, the coded-value domains that constrain them, and the relationship rules that keep records consistent as assets change. It’s the difference between a map layer and an asset register.
What manhole feature class attributes are required?
At minimum: a unique FACILITYID, physical fields such as MHTYPE, WALLMAT and CVTYPE, elevation fields including RIMELEV and INVERTELEV, lifecycle fields such as INSTALLDATE and ACTIVEFLAG, and condition fields. Most models land between 18 and 25 fields.
Should sensor history be stored on the manhole feature class?
No. Store one value per asset on the feature class, such as device ID and last communication time. Store readings in a related time-series table keyed to the device, with FACILITYID as the link. Chartable data on a feature class turns a manageable table into an unmanageable one.
Do I need the Esri utility network, or is a geometric network enough?
A plain feature class with domains covers inventory, mapping, and condition reporting. Move to the utility network when operators need to trace connectivity, such as finding everything downstream of a blockage. The trade is topology overhead in exchange for traces that stay correct as the network changes.
How does NASSCO MACP condition data fit into a GIS schema?
Map the MACP header measurements to standard attributes such as DEPTH, RIMELEV and SPATIALACC. Store the defect observations as one row per defect in a related table, not as columns. That structure is what allows condition to be trended across inspection cycles.
