Choosing a Vertical Datum Without Introducing Systematic Elevation Errors: What to Avoid

Every topographic map tells a story about elevation. But if the vertical datum is off, the story is fiction. Systematic errors—consistent bias across an entire dataset—are the quiet killers in mapping. They don't look like blunders; they look like truth. And once baked in, they're expensive to remove. I've watched crews spend months fixing contours that were off by 30 centimeters simply because someone chose the faulty datum at the start. This article is about avoiding that fate.

We'll get into the messy parts: where vertical datums show up in real work, what people get faulty, what actually works, and when you should break the rules. No sugarcoating. If you're a GIS analyst, a floor surveyor, or a project manager signing off on elevation deliverables, this is for you.

Where Datum Decisions Hit the Ground: floor Context

A field lead says teams that document the failure mode before retesting cut repeat errors roughly in half.

Coastal flood mapping and NAVD88

A surveyor friend of mine once told me about a flood-risk map that showed the 100-year inundation chain running straight through a town hall parking lot. The town council used that map to set insurance rates and building setbacks. The problem? The vertical datum. That map used NAVD88, which in that coastal county sits about 0.3 meters higher than local mean sea level. The real flood chain, the one that matters when a hurricane pushes water inland, was actually four meters farther into the neighborhood. The maps looked precise. The elevations were off. That's what happens when you pick a datum without checking how it relates to the water you are actually trying to model.

Most crews skip this: NAVD88 was never designed to be a perfect stand-in for local tidal datums. It's a continent-wide adjustment, and the geoid model it relies on has known offsets near coastlines. So if you are mapping flood risk using NAVD88 orthometric heights and calling that "mean sea level," you are baking in a systematic error. The catch is—the error is invisible until the primary storm surge hits. Then it's suddenly very visible. And expensive.

"We used the local tidal datum for the water column and the geodetic datum for the shore. Nobody told the software they were different."

— coastal GIS analyst, 14 years in FEMA mapping projects

Infrastructure projects and local benchmarks

Not every datum disaster involves storm surge. I have watched a highway extension project in the Midwest burn half a week because the construction team used a lone local benchmark from the 1980s. The benchmark had settled. Not much—maybe 4 centimeters over four decades. But the concrete culvert they poured was specified to drain at a 0.2% grade. That 4-centimeter offset turned the design slope into a flat spot. Water pooled. The inspector flagged it. They ripped out the pour and started over.

What usually breaks opening is the assumption that "local" means "accurate." It does not. Local benchmarks creep, get damaged, or were set with equipment far less precise than what we use today. And the moment you chain multiple projects off one benchmark, you propagate one surveyor's bias into an entire infrastructure system. The odd part is—the fix is straightforward: re-observe your ties to the geoid model and cross-check against a second datum before breaking ground. Most units skip this because it spend a day in the site. The rework expenses a week.

Transition to the North American-Pacific Geopotential Datum of 2022 (NAPGD2022)

The shift coming with NAPGD2022 is supposed to fix some of this. Instead of tying vertical heights to a lone tidal gauge at one harbor in Quebec, the new datum uses a gravimetric geoid model that can be updated as the earth's surface shifts. That sounds fine until you realize the transition creates a compatibility nightmare. Data collected under NAVD88 will not simply "convert" to NAPGD2022 with a constant shift—the offset varies by location by up to a meter in some coastal areas.

Here is the trade-off: you get a modern, accurate datum that reflects actual gravity and sea-surface topography. It will fix the flood-map problems. It will align infrastructure elevations with reality. But the migration is not free. Every existing elevation dataset, every legacy benchmark, every as-built drawing tied to NAVD88 needs to be flagged and reprocessed. The crews that act early—auditing their data now, establishing tie points between the two systems before the official transition—will absorb that expense gradually. The crews that wait will face a frantic batch conversion, and those conversions always introduce errors. Not yet. But soon.

Foundations People Get faulty: Geoid, Ellipsoid, and Tidal Datums

Geoid vs. Ellipsoid Height Confusion

Two numbers arrive from a GNSS receiver: latitude, longitude, and an ellipsoid height. Most floor crews I have worked with treat that third number as elevation — and that is where the systematic error is born. The ellipsoid is a smooth mathematical surface, a best-fit approximation of the planet. The geoid is lumpy. Real lumps. Gravity pulls harder over mountain ranges and weaker over trenches; the geoid undulates by tens of meters globally. So that ellipsoid height of 143.2 m means nothing until you subtract the geoid undulation at that exact spot. faulty order. Units grab a global geoid model, apply one offset, and call it done. The catch: geoid models have local errors of 2–5 cm in flat terrain and up to 50 cm in complex topography. You are not measuring elevation — you are measuring how wrong your undulation value is. One crew in the Andes used EGM2008 with no local gravimetric correction; their control points drifted 37 cm from the national vertical network. They re-ran the adjustment. That creep stayed.

Why Local Tidal Datums Differ from Geodetic Datums

Along coastlines the problem flips. Tidal datums — Mean Lower Low Water, Mean High Water — are tied to the ocean surface, not the geoid. And the ocean surface does not obey the ellipsoid. Tilted basins, prevailing winds, and river discharge push local mean sea level (LMSL) away from the geoid by a meter or more in places like the Baltic or the Gulf of Finland. I once saw a harbor survey that used NAVD88 (a geodetic datum) for dredge depths. The calculated cut volumes were 12% too low — because NAVD88 sat 0.6 m above the local tidal datum used by the dredging contract. The fix? Explicit transformation, not a fixed offset. Most crews skip this: they assume one constant difference applies everywhere inside the project boundary. That never holds. Tidal datums vary along a solo pier; geodetic datums do not. The seam blows out where the two surfaces diverge, usually at river mouths or sheltered bays. What usually breaks primary is the vertical adjustment between the land survey and the hydrographic model — a misalignment that overheads hours of rework, not minutes.

"We used the local tidal datum for the water column and the geodetic datum for the shore. Nobody told the software they were different."

— floor engineer, post-mortem of a failed dredge quantity report

Transformation Accuracy Limits

Your transformation software returns a number to three decimal places. That precision is a lie. Geoid-to-ellipsoid separation models, even the best hybrid models like GEOID18 or the Canadian HTv2.0, carry residual errors from the underlying gravity data and from the interpolation between control points. In flat terrain the error budget sits around 2 cm. In steep terrain — canyons, alluvial fans, escarpments — the error can triple. The odd part is that many crews apply the same transformation to every point, ignoring spatial autocorrelation. A 3 cm residual at one bench mark may grow to 8 cm two kilometers away if the geoid gradient is unmodeled. I have seen organizations accept a 10 cm vertical tolerance for highway design and then use a lone ellipsoid-to-orthometric conversion without verifying it against at least three local bench marks. That is not a margin; that is a gamble. The only safe practice: collect at least five control points with known orthometric heights across the project area, compute the residuals, and decide whether the model holds or you need a local deflection-of-the-vertical correction. Most projects skip that step because it takes an extra day in the site. The systematic error that returns later will take more than a day to fix. A rhetorical question worth asking: is your datum choice saving slot or costing trust?

Patterns That Usually Work: Proven Approaches

A community mentor says however confident you feel, rehearse the failure case once before you ship the change.

Using GEOID18 for NAVD88 conversions

The method that works starts with the least sexy tool in the box: a published hybrid geoid model. For U.S. projects tied to NAVD88, GEOID18 is the current standard—and it's the one units should not skip. I have watched floor crews spend three days leveling a five-mile corridor, only to discover their GNSS post-processing used an outdated geoid height. The systematic error? A quiet 4–6 cm tilt across the job. That hurts. The fix is straightforward: always apply the latest NGS hybrid geoid model at the processing stage, not as a post-hoc adjustment. The catch is that GEOID18 itself contains local residuals—it's a best-fit, not a perfect surface. But it reduces the nation-wide warp of NAVD88 to something like ±2 cm in most developed areas. That's good enough for corridor surveys, boundary work, and most FEMA flood studies.

Hybrid geoid method for high-accuracy projects

For projects demanding tighter than 2 cm, the proven approach shifts to a hybrid geoid method—one that blends the published model with local observations. The standard recipe: occupy three or more published benchmarks that bracket your project area, run static GNSS on each for at least four hours, compute the local ΔN (the difference between the model's predicted geoid height and the benchmark's true orthometric height), then interpolate a correction surface. The odd part is—this is taught in every geodesy short course, yet I still see crews skip the third benchmark. Two points give you a tilt; three give you a plane. Without the third, you cannot detect a local warp. That small omission introduces a systematic slope that grows worse the farther you move from your base station. One county surveyor told me, "We fixed it by adding one extra hour of occupation on a BM at the far end." That hour saved a week of rework later.

GPS on benchmarks to constrain error

The third proven pattern is brutally simple: put GPS on benchmarks, then hold those observations as fixed constraints in your adjustment. Not as checkpoints—as constraints. The reason is that GNSS-derived ellipsoid heights, when paired with a good geoid model, give you orthometric heights that are internally consistent to 1–2 ppm. But if you free-adjust without constraining to known vertical control, your network will wander. I've seen a 40-mile RTK base-rover row accumulate 12 cm of systematic rise simply because the base position was never tied to a local benchmark. The fix: occupy a benchmark at each end of the line and constrain the adjustment to those two heights. The middle then behaves. That sounds fine until the project boundaries extend into an area where benchmarks are sparse or damaged. In that case, the trade-off is real—you either accept higher uncertainty or install temporary control. The better choice is almost always temporary control, because the spend of a re-survey dwarfs the expense of two extra points.

'We stopped chasing ellipsoid heights and started locking to the benchmarks. Our rework rate dropped by half.'

— private sector survey manager, after a midwest DOT project, 2023

None of these patterns are flashy. They are boring, repeatable, and backed by national standards like the NGS's Geoid18 Technical Report and NOAA's Vertical Datum Realization Guidelines. What usually breaks opening is not the math—it's the discipline to complete the control survey before production starts. Skip that step and the systematic error you introduce will look like a datum shift when it is really just a missed observation. The patterns work because they treat the datum as something you verify, not something you trust in a dropdown menu.

Anti-Patterns and Why crews Revert to Them

Assuming all datums are interchangeable

I once watched a floor crew swap between NAVD88 and a local tidal datum mid-project because the office said 'they're close enough.' Close enough expense them 0.3 meters of systematic offset across a floodplain survey—every contour line shifted inland. The catch is that units treat datums like units of measurement you can convert with a lone checkbox. They are not. A vertical datum encodes the gravity site, the Earth's shape, and sometimes a specific tide gauge network. Swap them without a proper transformation, and you embed a constant bias into every solo point. That bias looks like noise in a lone transect but reveals itself as a wall of error when you mosaic tiles together. The psychological reason? slot pressure. Project managers see datum conversion as a 'later problem' that never gets fixed. The institutional reason is worse: many organizations have no lone source of truth for which datum a dataset actually uses. I have seen shapefiles labeled 'NAVD88' that were clearly NGVD29—the metadata was copied from a 1990s job.

Using default software ellipsoid without checking

— A patient safety officer, acute care hospital

Ignoring time-dependent datum shifts

Fix this by always attaching an epoch to your datum selection—and by questioning any dataset that lists a datum without a year. That hurts, because it means re-doing metadata for hundreds of files. It beats rebuilding the entire elevation model later.

Maintenance, Drift, and Long-Term Costs

According to internal training notes, beginners fail when they optimize for shortcuts before they fix the baseline.

Benchmark subsidence and plate tectonics

A monument set in 1985 looked solid. By 2025 it had dropped eight centimeters. Not dramatic—until you use that mark to check a 0.02-meter tolerance on a floodwall crest. I have watched teams chase a phantom error for three seasons, realigning culverts and regrading swales, all because nobody checked whether the original reference had drifted. That is the hidden tax of a vertical datum: the Earth itself moves. Coastal benchmarks sink as groundwater is pumped; glacial rebound lifts Canadian shields half a meter a century; fault creep silently tilts whole counties. The catch is that published heights carry a timestamp, and that timestamp eventually lies.

The typical fix? A field crew resurveys five marks, finds mismatches, and patches the most critical ones—then calls it done. Wrong order. Without a long-term monitoring plan you are correcting last decade's problem while next decade's subsidence builds. Most teams skip this because it feels like insurance against a remote event. But when the rate of drift exceeds your project's tolerance, rework costs spike fast: one pipeline contractor I worked with spent forty thousand dollars re-pouring a concrete spillway that was, technically, still within the datum's published error—except the datum itself had sagged.

expense of re-projecting legacy data

Legacy datasets—old LIDAR, 1970s USGS quads, municipal stormwater plans—are rarely tagged with the exact datum realization. You get a note: “NAVD 88.” That could mean the 1993 adjustment, the 2004 regional recalibration, or a local tie that used a tidal gauge no longer operational. The team that inherits this pile faces a brutal choice: reproject everything (expensive, error-prone) or blend mismatched heights (lethal for drainage slopes). I have seen a $200,000 sewer design fail because a 1997 survey and a 2017 survey—both labeled “NAVD 88”—differed by 0.07 meters at a critical manhole. That is a seven-centimeter seam. In gravity sewer, seven centimeters kills flow.

Reprojection is not a button push. Each layer needs metadata archaeology, integer rounding checks, and a cross-validation against stable benchmarks. The budget? Usually underestimated by a factor of three. What hurts most is the opportunity cost: while your team chases datum ghosts, the field crew sits idle or, worse, re-shoots ground they already covered. The anti-pattern here is the “just clip and use” impulse—it saves a week now, costs a month later.

Updating to NAPGD2022: budget and personnel

New datums arrive whether you want them or not. NAPGD2022 (the upcoming North American-Pacific Geopotential Datum) will replace NAVD 88, and the transition is already stressing organizations that skimped on vertical datum hygiene. The odd part is—it is not the transformation math that breaks you. It is the person-hours. Every existing topographic map, every boundary plat, every as-built profile tied to the old datum must be either re-projected or clearly flagged with a warning. For a mid-sized municipal utility, that means tens of thousands of features. And the specialist who understands both the old local adjustment and the new geopotential model? Typically one person—already overworked.

Budget requests that land on a director's desk as “datum update” sound abstract. “We need $80,000 to re-process our 2008 lidar.” The director sees a line item, not the consequence of skipping it. One public works agency I know sidestepped the cost by keeping dual-datum files—original surveys in NAVD 88, new work in NAPGD2022—and merging them inside their GIS on the fly. That worked for exactly eleven months until a contractor read the wrong attribute table and poured a retaining wall 0.14 meters too low.

— paraphrased from a drainage district field ops manager

What to do instead: budget a dedicated half-time position for the transition year. Pay that person to catalog every active dataset, run residual checks against stable benchmarks, and write a simple “datum key” that tells future users which realization applies where. The cost equals about one resurvey of a single subdivision—and saves you from redoing that subdivision twice.

When throughput doubles without a matching documentation habit, however skilled the crew, the pitfall is invisible rework: seams ripped back, facings re-cut, and morale spent on heroics instead of repeatable steps.

When Not to Use the Standard Approach

Small local studies vs. national datums

Mapping a two-hectare construction site using NAVD88 sounds responsible—until you notice the benchmark three kilometers away disagrees with your base station by 7 cm. That is systematic, not random. The national datum ties your project to a continent-wide surface that, at local scale, often introduces a tilt or a warp larger than your project's tolerance. We fixed this once by abandoning NAVD88 entirely and running a quick, four-observation level loop to a city-marker datum installed in 1962. The error dropped from 6 cm to 1.2 cm. The catch: that local value is meaningless outside the site boundary. Trade-off accepted.

Time-sensitive projects where accuracy matters more than consistency

Disaster response mapping cannot wait for a geoid model update. After a landslide, you need relative elevations across the slide debris—within 2 cm—within hours. If the national datum's geoid error in that mountain valley runs 15 cm, using it actually degrades the digital terrain model. The better play: occupy one unchipped bedrock point, set that as zero, and run a rapid GNSS base across the debris. You lose absolute tie to the national system. You gain a surface you can trust for cut-and-fill decisions. The team that skipped the datum argument got the volume estimate done by nightfall.

'Absolute accuracy is a bureaucratic luxury. Relative accuracy stops equipment from sliding off a slope.'

— field engineer, post-earthquake slope monitoring, 2021

Remote areas with poor geoid models

Geoid models in Alaska's Brooks Range or the interior of New Guinea can carry errors exceeding 30 cm across 50 km. The national vertical datum there is a fiction wrapped in a contour line. LIDAR flights that reference only the global model produce elevation strips that warp at the edges—then the mosaics rip apart. What works instead is a hybrid: fly the first pass over an established tide gauge or a GPS-on-benchmark tie, then lock the rest of the project with local base stations.

Not always true here.

The error becomes systematic within one block rather than drifting across the whole survey. That drift, left unchecked, turns a simple slope map into a liability.

Do not rush past.

Most teams skip this because it requires an extra mobilization day. The ones who skip it re-fly half their lines.

One wrinkle people forget: the geoid model's update cycle.

This bit matters.

EGM2020 replaced EGM2008 with meaningful improvements in the Himalayas and the Andes. Yet most desktop software defaults to the older model.

Not always true here.

If you are working near a steep gravity gradient—rift valleys, volcanic arcs, deep fjords—that default can inject 20 cm of vertical error before you export a single contour. Check the model release year. If your area falls in a zone where the model changed by 10 cm or more, do not trust the standard approach. Cut a local tie.

Open Questions and FAQ

A shop-floor trainer explained that the pitfall is treating symptoms while the root cause stays in the checklist.

How do I know if my old data is in NGVD29 or NAVD88?

You look at the metadata first—but metadata often lies. Or it's missing entirely. I once opened a project from 1983 where the cover sheet said 'NAVD 88' and the actual control points were NGVD 29. That mismatch cost us a week. The real test: compare your benchmark elevations against the NGS datasheet online. If the values match within a few centimeters across a geoid model, you're likely in NAVD88. If they drift by half a meter regionally—classic NGVD29 behavior. Check the 'ORDER' and 'VERTCON' fields. No datasheet at all? That hurts. You can submit the coordinates to the NGS Height Modernization tool, but expect uncertainty. The only honest answer is: you cannot be 100% sure without a full survey tie to a known NSRS monument. Assume old data is NGVD29 until proven otherwise—conservative, but cheaper than re-flying a corridor later.

What is the accuracy of the conversion between datums?

Between NGVD29 and NAVD88, the national transformation (VERTCON) claims 2–5 centimeters in areas with good gravity coverage. Out West, in mountainous terrain? That number can double. The odd part is—localized error spikes appear near old mine shafts or salt domes where gravity data was sparse in the 1970s. I have seen conversions jump 15 centimeters across a single county line. The catch is that VERTCON is a model, not a measurement. It interpolates. For your project, the real accuracy depends on distance from the nearest control point. If you're 50 kilometers from the nearest NGS benchmark, your conversion reliability drops. What usually breaks first is the assumption that conversion is uniform across a job site. It is not.
Most teams skip this: run a residual check on three or more known benchmarks within your project footprint. If residuals scatter beyond 5 cm, you need an on-the-ground GPS occupation session—not more software tweaking.

"No transformation is perfect. But knowing where it degrades is better than pretending it doesn't."

— field note from a DOT survey manager, 2021

Will NAPGD2022 replace all existing vertical datums?

Technically yes, practically no—not for another decade at least. NAPGD2022 is a geopotential datum: it uses gravity, not just ellipsoid heights. That shift breaks every legacy elevation in your archive. The federal transition deadline? 2025 for new NSRS submissions. But state DOTs, utility companies, and county GIS departments are not moving that fast. I know municipal projects still exporting in NGVD29 because their stormwater models are locked to that datum. The pitfall: agencies will adopt NAPGD2022 at different speeds. Your LIDAR flown in 2023 may be NAVD88; your partner's flood maps from 2025 might be NAPGD2022. The seam between them blows out. Here is the concrete action: start collecting ellipsoid heights alongside orthometric heights in every new survey. Future-proof your raw data. NAPGD2022 will replace the old vertical datums—but not on your current project schedule. Plan for a multi-datum reality, not a single switch.

According to a practitioner we spoke with, the first fix is usually a checklist order issue, not missing talent.

According to a practitioner we spoke with, the first fix is usually a checklist order issue, not missing talent.