NAD83, State Plane and the geoid: getting the coordinate system right on drone topo in CA, GA and FL

A drone LiDAR point cloud can be clean, dense and well within its accuracy spec, and still land in the wrong place on your CAD sheet. The cause is rarely the sensor. It is usually the coordinate system the data was delivered in.

One conference speaker from a drone-data processing company put the starting point plainly: "you don't just fly a lidar drone and ... have everything in wgs84 most of your projects are going to be localized" (Aerotas, Western Regional Survey Conference, 2022). Someone has to decide what the data is in, and write it down.

This post lists the five decisions that make up a coordinate reference system for drone topo. For each one it puts numbers on what goes wrong in California, Georgia and Florida. The numbers come from NGS CORS files, the GEOID18 model and a grid-factor calculation you can rerun from the files in this post's folder.

The five decisions hiding inside "State Plane NAD83 NAVD88"

A project's coordinate system answers five questions. Most handoff errors are one of them left unstated.

1. Horizontal datum and epoch. Which realization of NAD83, and at what date?
2. Projection and zone. Which State Plane zone, and which one does the county actually use?
3. Units. Meters, US survey feet or international feet?
4. Vertical datum and geoid model. NAVD88 through GEOID18, or raw ellipsoid heights?
5. Grid or ground. Are distances scaled to the projection surface or to the terrain?

The sections below take them in order, then show how to write the answers into a scope.

Horizontal datum: NAD83(2011) epoch 2010.0, and why the date matters

NGS publishes the current NAD83 realization as NAD83(2011), epoch 2010.0. Its GEOID18 page states that GEOID18 is for coordinates in "NAD 83 (2011) epoch 2010.00." NGS-published control is on that date.

California adds a wrinkle. Its official geodetic datum is the California Spatial Reference System, published by the California Spatial Reference Center under Public Resources Code sections 8850 to 8861. The current realization is CSRN Epoch 2025.00 NAD83(2011), effective January 1, 2025. It replaced Epoch 2017.50, and some horizontal coordinates changed by over 300 mm (GPS World, Sept 2025). So "NAD83(2011)" alone does not say which California epoch was held.

The ground has not stayed on that date. NGS publishes a NAD83(2011) velocity for each CORS station. Multiply it by the time since 2010.0 for an estimate of how far the station has moved from its epoch 2010.0 position. The table uses 16.8 years, 2010.0 to late 2026. These are constant-velocity extrapolations (my arithmetic), not measured displacements.

What this means in practice:

• In Southern California, a CORS at constant velocity would now sit more than half a meter from its epoch 2010.0 coordinate. Anyone tying to published control needs to know which epoch the processing assumed.
• In Atlanta and Miami the same mistake costs a few centimeters. That is small enough to hide inside normal error, which is why a Georgia or Florida workflow can look fine and then fail when it crosses into California.
• NGS computed these velocities in June 2019 from data through GPS week 1933 (January 2017), and the Georgia and Florida values are near the noise level of GNSS velocities (inferred; the files give no uncertainty). Earthquakes can also move stations. Treat the table as an order of magnitude, not a correction to apply.

The bigger offset is between frames. In the same CORS files, the ITRF2014 position differs from the NAD83(2011) position by about 1.5 m in California (JPLM), 1.7 m in Georgia (GALV) and 1.8 m in Florida (ZMA1). NGS says on its new datums page that NAD83 is "misaligned to the earth's center by about 2.2 meters." Raw satellite coordinates that are never transformed to NAD83 are meters off, not centimeters. I expect the same to hold for raw WGS84 coordinates, which are tied to the same global frames, but I did not verify that here.

What to ask for: the datum realization (for example NAD83(2011)), the epoch (2010.0), and what the base station or network coordinates were held to.

Projection and zone: know which zone your county uses

State Plane zones are set by county, not by where a site feels like it belongs. Three states, three different patterns.

California. The California Coordinate System of 1983 has six zones. Public Resources Code section 8802 puts Los Angeles, San Bernardino, Ventura, Kern, Santa Barbara and San Luis Obispo in Zone 5. It puts Imperial, Orange, Riverside and San Diego in Zone 6. So an Inland Empire project may be Zone 5 (San Bernardino) or Zone 6 (Riverside). A county line, not a freeway, decides it.

Georgia. There are two zones. The EPSG area of use for Georgia West lists Fulton, Cobb, DeKalb, Gwinnett, Clayton, Cherokee, Forsyth and Henry among its counties, so most of Metro Atlanta is West. Georgia East covers counties such as Richmond (Augusta) and Chatham (Savannah). Georgia's code also defines the two zones around central meridians at 84 degrees 10 minutes west and 82 degrees 10 minutes west.

Florida. There are three zones: East, West and North. Florida East includes Miami-Dade (listed as Dade), Broward and Palm Beach, along with Orange and Duval. Florida West includes Hillsborough and Pinellas. Check the county before you assume.

The EPSG codes below are for NAD83(2011) in each zone. Code and unit travel together, and the codes are easy to swap.

I looked up these codes in the EPSG registry bundled with PROJ (the pyproj library, version 3.8) and checked 6423 and 6424 on epsg.io. One caution if you copy older write-ups: some list 6424 as the meter version of California Zone 5. It is the US survey foot version.

Units: the two-part-per-million trap

The international foot is exactly 0.3048 m. The US survey foot is 12/39.37 m. They differ by exactly 2 ppm, or about 0.01 ft per mile, according to that article's summary of the NIST and NGS notice.

Two ppm sounds harmless on a distance. On a coordinate it is not. State Plane eastings and northings run into the millions of feet. A coordinate of 2,000,000 ft read in the wrong foot is off by 4.0 ft (2,000,000 x 0.000002, my arithmetic). Every point shifts by a different amount, so the data is moved and slightly stretched at once.

The same source says NGS keeps SPCS 83 coordinates in US survey feet where that is their current definition. It also says the modernized SPCS2022 will use the international foot. Many California, Georgia and Florida firms still deliver and receive US survey feet today. So put the foot in the scope.

Vertical datum: where zero is

GNSS, including the RTK or PPK on a drone, measures height above the GRS80 ellipsoid. Engineers work in NAVD88 elevations. GEOID18 converts one to the other. NGS describes hybrid geoid models as the way to convert NAD83 ellipsoid heights from GPS to orthometric heights.

The gap is large. I sampled the GEOID18 grid at the CORS station coordinates:

• Pasadena (JPLM): geoid height of -33.4 m, so elevation is about 110 ft above the ellipsoid height.
• San Diego (SIO3): -35.0 m, about 115 ft.
• Lawrenceville, GA (GALV): -29.5 m, about 97 ft.
• Miami (ZMA1): -25.1 m, about 82 ft.

Among the CORS stations I sampled, the geoid height runs from -22.4 m at Marathon Key, FL to -35.0 m at San Diego. A rough "about 100 feet" is not a fix. A surface delivered in ellipsoid heights is internally consistent and looks right in a viewer. Slopes, contours and volumes all work. It just sits roughly 74 to 115 feet (at the stations sampled) from every benchmark and every design elevation.

Note one more trap. NGS says on its new datums page that NAVD88 is "biased (by about one-half meter) and tilted (about 1 meter coast to coast)" relative to current global geoid models. That is a reason NGS is replacing it. It does not change what a design set in NAVD88 expects today.

The NGS GEOID18 page I read does not give an accuracy figure for the model. So I do not quote one. If your project needs tight vertical agreement, tie to published benchmarks and report what you find.

What to ask for: the vertical datum (NAVD88), the geoid model (GEOID18), and the vertical unit. Also ask whether the ellipsoid heights are delivered at all.

Grid or ground: the scale factor nobody mentions until quantities disagree

State Plane coordinates are on a projection surface. A distance computed from them is a grid distance. A tape or a lot dimension on the terrain is a ground distance. Two things separate them:

• Grid scale factor. The projection stretches or shrinks distances depending on where you are in the zone.
• Elevation factor. Terrain above the ellipsoid is larger than the same arc at the ellipsoid. The factor is R/(R+h), using the ellipsoid height h.

Multiply them for the combined factor. I computed both with pyproj for 19 places, using USGS 3DEP elevations and the GEOID18 value for each to get ellipsoid height. R is 6,371 km, a round mean radius. The elevation factor is a standard formula, not one I sourced from a single document.

A few results from my calculation:

Three things stand out.

• The elevation factor is not the whole story. In Atlanta, the grid scale factor (about -95 ppm) is twice the elevation factor (about -46 ppm). A rule of thumb based on elevation alone misses it.
• Coastal sites can have a small factor that is positive. Miami and San Diego are near 1.0 for two reasons: their elevation is low, and the zone scale is slightly above 1 there.
• Where the factor is large, it matters for quantities. At Atlanta's -140 ppm, a 1,000 ft ground distance becomes 999.86 ft on the grid. That is 1.7 inches. At Big Bear it is about 4.3 inches (my arithmetic).

This is why many projects use a localized or ground-scaled system. If your engineer's file is ground-scaled and your data is on the grid, everything is a little the wrong size. Neither choice is wrong. A mismatch is.

What to ask for: whether the design is on grid or ground. If ground, ask for the combined factor and the point it is applied about.

How this compares to sensor accuracy

Compare these numbers to what a drone LiDAR system can deliver. DJI specifies the Zenmuse L2 at 5 cm horizontal and 4 cm vertical at 150 m, measured in a laboratory. An independent test by Tamimi and Toth reported about 7 cm RMSE on an open road and 21 cm under forest canopy.

Set those beside the coordinate errors above:

• A missed epoch in Southern California: about 57 to 67 cm (constant-velocity estimate).
• A missing geoid step: about 22 to 35 m.
• An unstated foot: 4 ft on a coordinate of 2,000,000 ft.
• A grid-versus-ground mismatch in Atlanta: about 0.74 ft per mile.

The ASPRS Positional Accuracy Standards, 2nd Edition, call for a minimum of 30 checkpoints when you report accuracy. Those checkpoints only mean something if they are in the delivered coordinate system. A check against shots in the wrong zone or the wrong vertical datum fails for a reason that has nothing to do with the sensor.

The same conference speaker argues for ground control for this reason: "it just increases the redundancy so much to have ground control points" and to confirm the LiDAR data is in the right datum.

Who is responsible for the coordinate decision

Topo, contours and DTMs delivered for design or a permit need a licensee in responsible charge, and Twinn does not stamp. In California that is a PLS, or a civil engineer legally authorized to practice land surveying. California's Business and Professions Code section 8726 and the Board's Bulletin 50 cover the surveying activity and the responsibility for accuracy. In Georgia it is a PLS. Rule 180-7-.04 treats topographic mapping by remote sensing, including LiDAR, as land surveying. In Florida it is a Professional Surveyor and Mapper (PSM), registered as a surveyor and mapper under Chapter 472.

The licensee picks the project coordinate system. A capture and processing partner should ask for it in writing and deliver to it, not choose it.

A modernization note

NGS says NAD83 and NAVD88 are "still the official horizontal and vertical datums of the NSRS" and will be replaced by new frames and a new geoid-based vertical datum. It says coordinates will change by as much as four meters. On a recent Geoholics panel (episode 294, Sept 2026), one speaker warned about people "expecting to take this state plane coordinate that was done in '83 and think that they can go find what they need to find in 22."

I could not confirm the current release status of the new datums or SPCS2022. Check NGS before any job that will be held against them. Whatever happens, a dataset labeled with its datum, realization and epoch can be converted. One labeled "State Plane" cannot.

One practical next step

Before the next flight, send your capture and processing partner one block of text. Fill in every line.

1. Horizontal datum, realization and epoch (for example NAD83(2011), epoch 2010.0, or CSRN Epoch 2025.00 in California).
2. Projection and zone, with the EPSG code (for example 6446 for Georgia West in meters).
3. Horizontal and vertical units, and which foot.
4. Vertical datum and geoid model (for example NAVD88, GEOID18).
5. Grid or ground, and the combined factor if ground.
6. Control and checkpoints: which published or surveyed points, in which system, and who reports RMSEv.

Then ask for the same block back on every deliverable. It takes five minutes and removes the most common reason a clean dataset fails to line up.

To scope capture and processing with a licensed partner responsible for the survey, see Twinn Digital for surveyors and engineers.