When 'State Plane' Isn't State Plane: The Custom-Scale-Factor Trap

The setup that usually works

A modern surveying workflow looks roughly like this: a crew shoots points in NAD83 state plane (with US Survey Foot as the unit, in most US states), the data collector emits a PNEZD file with northing and easting in those state-plane coordinates, and downstream tools transform to WGS84 lat/lon when needed for a map view or a Google Earth overlay.

This works because state plane is a real, well-defined projection with a real EPSG code – 2274 for NAD83 Tennessee, 2966 for NAD83(HARN) Indiana East ftUS, and so on. pyproj knows about it. QGIS knows about it. The transformation is deterministic. If your point’s WGS84 location lands within a few feet of expected, congratulations: the projection worked.

The trap

A nontrivial fraction of surveying firms – maybe 5 to 10 percent of the archives we’ve looked at so far – have applied a small, undocumented modification to “their” state plane. They apply a custom scale factor (typically 0.99996 to 1.00004) and sometimes a rotation (usually under 0.01 degrees) to make their working coordinate system align with a particular local monument: a USGS benchmark, a county-section corner, a previous boundary survey they trust.

Why does anyone do this? Pre-GPS, surveyors who tied multiple jobs to a common physical reference used an empirical adjustment to make new work line up with old work to within a quarter-inch. State-plane only gives you projected accuracy at the projection’s defined origin and scale; working 30 miles from origin, the on-the-ground distance between two of your points won’t quite match the difference between their state-plane northing/easting values. Sub-foot accuracy is real money in survey work, so the firm baked in a correction.

The correction is usually written into the firm’s CAD coordinate-system definition once and then forgotten about. New employees don’t know it exists. Old PNEZD files have it baked in. The firm’s job notes might mention “Smith Farm scale factor” but most people in the office have no idea what that means.

How it shows up in verification

You’re doing a verification cohort – 50 random points across 5 jobs in the firm’s archive, transformed via the state-plane EPSG code your CRS classifier auto-detected. You plot them on a real map. The points cluster correctly by job (Smith Farm points are near Smith Farm). But every single point is offset from where it should be:

• Sometimes the offset is systematic in direction – everything’s 12 ft NE of expected. That’s a translation, the simplest case.
• Sometimes the offset is proportional to distance from a reference point – points near the office origin are spot-on; points 5 miles away are 30 ft off. That’s a scale factor.
• Sometimes both – a translation plus a scale, with a tiny rotation thrown in. That’s a full 2D Helmert pair.

If you see this and the points were tagged EXACT by your CRS classifier, the classifier isn’t wrong about the EPSG code. It’s right about the projection. It’s just that the firm modified the projection.

Diagnosing

Three quick checks before going down the Helmert rabbit hole:

1. Sanity-check the units. US Survey Foot vs International Foot is a 2 ppm difference. Over a 10,000-ft baseline, that’s 0.02 ft – noise. Over a 5-mile baseline, that’s 5+ ft. If your offsets are always proportional to distance and roughly 2 ppm, units are suspect #1, not a custom scale factor.

2. Check the datum. Older archives (pre-1990s) may be NAD27, not NAD83. NAD27 vs NAD83 is a 30 to 100 ft offset depending on where in the country you are. If your “state plane” archive spans the datum boundary, the older jobs land hundreds of feet off.

3. Check for a documented scale factor. Ask the senior surveyor or the head CAD tech directly: “Do you have a project-specific transformation you apply to state plane in this archive?” A surprising number of firms answer “Oh, yeah – it’s in the notes for jobs from before 2018.” Sometimes that’s the entire investigation. Most firms don’t volunteer this information unless asked, because they treat it as obvious context.

If all three are clean and the offsets are still systematic, you’re looking at a custom transformation pair the firm has internalized but never formally written down.

The Helmert solution

A 2D Helmert transformation is four parameters: x-translation, y-translation, scale factor, rotation. With those four numbers, you can map any (E, N) coordinate from “the firm’s state plane” to “real state plane” exactly.

The extraction process: pick 3 to 5 points in the archive that have independently-verifiable real-world locations (a county section corner, a USGS benchmark, a previous-survey monument with a known WGS84 location). Compute what the firm’s coordinates say for those points. Compute what the real coordinates should be. Solve a least-squares system for the four Helmert parameters.

Once you have the pair, every coordinate in that archive can be corrected. Forward and inverse are both straightforward.

Why we don’t auto-detect this

Detecting a custom Helmert pair automatically requires a ground-truth comparison set (real WGS84 locations for points in the archive). Without that, you can’t distinguish a deliberate firm-applied transformation from a botched coordinate system from a data-entry error. We considered baking automatic Helmert detection into FieldIntel’s CRS classifier and decided against it for that reason.

What FieldIntel does instead: flags the archive’s verification cohort as APPROXIMATE rather than PASS, surfaces the systematic offset pattern in the verification report, and prompts a conversation about whether the customer has a documented transformation pair. If they do, we add it to their fieldintel.yaml as a per-archive correction. If they don’t, we work with them to extract one from a small set of ground-truth points.

We’ve done this work on three archives so far. None of the firms knew the transformation existed. In two cases, we found old CAD project files with it written in a comment block; in the third, we extracted it from a set of monumented points the firm had real-world coordinates for.

What to do if this is your archive

If you’re at a firm and your verification points keep landing systematically offset, the right path:

1. Ask the senior surveyors and CAD techs whether anyone remembers a project-specific scale factor or transformation. Specifically ask about pre-GPS-era jobs.
2. Pull two or three CAD files from different decades and look for coordinate-system definitions or comment blocks documenting any custom transformation. Modern AutoCAD stores this; older versions sometimes don’t.
3. Identify three to five points in the archive that have independent ground truth – monumented benchmarks, section corners, points from a BLM cadastral survey if you have any.
4. If you can’t find the transformation pair, get help. This is a real time investment to extract from scratch – four to eight hours of careful work for a typical archive.

The Helmert pair, once known, applies to the entire archive forever. You only have to do this once.