Datum-Free PNEZD: When the Numbers Look Like State Plane But Aren't Declared

The problem with “looks fine”

Local-grid archives announce themselves. A PNEZD with (N: 5000, E: 5000) on the first row is unambiguous – you know immediately you don’t have a real datum. You can tag it, set it aside, and budget a Helmert pair for the day it earns its keep.

A datum-free state-plane-looking PNEZD is harder because nothing about it screams “I’m broken.” A typical Tennessee North file might open with:

1, 568432.12, 1820156.78, 612.45, IP-FOUND
2, 568445.31, 1820219.04, 612.78, IP-FOUND
3, 568478.92, 1820301.15, 613.02, RW-MARK

That looks great. The northings are in the 560,000s, which is correct for Tennessee North. The eastings are in the 1,820,000s, which is also correct for Tennessee North. The elevations are reasonable. The descriptions are surveyor-grade.

So you type 2274 into your CRS picker and hit import. The points plot perfectly on a satellite basemap. Everything looks right.

And you might be 30 feet off, or 80 feet off, or somewhere in between, because the file was actually in NAD27 / Tennessee North, not NAD83 / Tennessee North, and the datum shift between those two – depending on your latitude – is exactly the kind of error that doesn’t show up in a visual inspection but does show up the day a client compares your work against an adjacent recent survey.

The numbers being in the right magnitude range tells you nothing about the datum realization. That’s the whole problem.

Four clues in the file itself

When a PNEZD shows up without metadata, you have four pieces of forensic evidence inside the file. None of them is conclusive on its own. Two or three of them lining up gets you to high confidence. One or zero of them means you should call the source.

Clue 1: Coordinate magnitudes (necessary, not sufficient)

This narrows the state plane zone but not the datum.

• Northings in the 100,000-400,000 ft range + eastings in the 500,000-2,000,000 ft range: probably a US state plane in US Survey Feet. Which zone depends on the specific values; cross-reference against the EPSG state-plane reference for your region.
• Northings or eastings in the 5,000,000+ range: probably a state plane in international feet, or possibly UTM in meters. UTM eastings sit in the 100,000-900,000 m range and northings in the 0-10,000,000 m range, depending on hemisphere.
• Magnitudes in the 5,000-100,000 range: probably a local grid – see last week’s post.
• Magnitudes in the single millions, both N and E: probably a state plane in meters, less commonly an international-feet zone.

The magnitude check rules zones in or out but is silent on datum. Tennessee North in NAD27 has the same coordinate range as Tennessee North in NAD83. Same for every other state-plane zone that exists in both realizations.

Clue 2: The point descriptions

This is the most underused source of information in a PNEZD. The description field often contains the answer.

Look for:

• **NAD83**, **NAD27**, **WGS84**, **HARN**, **NAD83(2011)** written into the description of a setup or reference point. Surveyors sometimes note the datum on the first occupied station: 1, 568432.12, 1820156.78, 612.45, SETUP NAD83 TN NORTH. If you see this anywhere in the file, treat it as authoritative.
• **SPC83** or **SPC27**: state plane coordinates, NAD83 or NAD27 respectively.
• **ftUS** or **ftINTL**: explicit unit declarations. Most US state-plane zones default to US Survey Feet, but a handful (e.g., Michigan) use International Feet.
• **WGS84** references in a CAD file’s header that came with the PNEZD: usually means GPS-grade data, post-1995, NAD83 or its successors.

The description field is the surveyor’s freeform note to themselves and to the next person reading the file. Read it before you do anything else with the numbers.

Clue 3: The vintage of the survey

Date metadata – if you have it – narrows the datum candidates substantially.

• Pre-1986: almost certainly NAD27. The shift from NAD27 to NAD83 happened around 1986 in the US and rolled out unevenly state by state through the early 1990s. A 1980 survey is NAD27 unless the surveyor explicitly converted it.
• 1986 to mid-1990s: could be either. Survey firms adopted NAD83 on different timelines. A 1990 boundary survey from a slow-to-adopt firm could still be NAD27.
• Mid-1990s to 2010: usually NAD83 (the original 1986 realization). Sometimes HARN (NAD83 High Accuracy Reference Network) in states that completed their HARN readjustment.
• 2010 to today: usually NAD83(2011) or one of its predecessors (NAD83(NSRS2007)). Some firms doing GIS-grade work use WGS84 directly. The differences between NAD83, NAD83(NSRS2007), and NAD83(2011) are usually under a foot but can be up to a couple of meters in some regions.

A survey date doesn’t have to be in the PNEZD itself – it can come from the CAD file’s title block, the job folder name, the filesystem modified date, or a phone call to whoever handed you the file. If you can pin the survey to a decade, you’ve cut the datum candidate list dramatically.

Clue 4: Adjacent known-CRS work

If the file is part of a larger archive where some files are correctly tagged and others aren’t, the tagged neighbors are evidence. A firm doesn’t usually switch CRS mid-project. If the boundary survey for parcel 47 is correctly labeled NAD83(2011) / Tennessee North ftUS, the topographic survey for parcel 47 done by the same crew the same week is almost certainly the same datum.

This works in the other direction too: if the adjacent work is NAD27, the untagged file is also likely NAD27 unless something in the date metadata suggests otherwise.

The obvious-guess failure modes

Three patterns to watch for, because they catch people who do everything else right:

Guessing the modern datum on an old file. A 1985 PNEZD with Tennessee North-looking coordinates is NAD27, not NAD83. Importing it as NAD83 puts you 60 to 80 feet off because the NAD27-to-NAD83 datum shift is that large in the southeastern US.

Guessing the original NAD83 on a modern file. Conversely, a 2024 PNEZD might be in NAD83(2011), which differs from the original NAD83(1986) by up to a couple of meters in regions where the readjustment was significant. Importing 2011 data as 1986 – or vice versa – usually doesn’t show up as a visual error, but it shows up as inconsistency the day the client cross-checks against an authoritative source.

Confusing US Survey Foot and International Foot. In US Survey Feet, 1 ft = 1200/3937 meters exactly. In International Feet, 1 ft = 0.3048 meters exactly. The difference is 2 parts per million – about a tenth of a millimeter per foot, which sounds negligible until you multiply by a 600,000-ft state-plane northing and end up about a foot off. Most US state-plane zones default to US Survey Feet, but you should never assume; check the EPSG code.

When to phone the source surveyor

If after working through all four clues you still have two or more datum candidates that all look plausible, the answer is to make a phone call instead of guessing. The phone call is cheaper than the rework. Specifically:

1. Two or more state-plane zones overlap your magnitudes (e.g., you’re near a state border and the coordinates could fit either side’s zone). Ask which zone.
2. The survey is from the 1985-1995 transition window and there’s no datum declared anywhere in the descriptions or the CAD header. Ask which datum.
3. The file mixes NAD83 and NAD83(2011) decimals – some points line up better against one realization, others against the other. This is rare but it happens when an addendum gets bolted onto an older base file. Ask whether the file has been merged or readjusted.
4. The descriptions reference “HARN” or “NSRS2007” without committing to a specific epoch. Those are real datum realizations with real differences. Get the year.

A two-minute call to confirm “NAD83(2011), Tennessee North, US Survey Feet” beats an afternoon of cleaning up downstream coordinates that landed in the wrong place because you guessed NAD83(1986).

The safety net: a “wrong datum” warning at import time

The way to make this less stressful operationally is to build the assumption check into your import workflow. PointScout Mobile’s CSV import asks for the EPSG code explicitly and warns when the code you typed disagrees with the datum family you picked from the radio buttons – selecting NAD83 and then typing 32016 (which is NAD27 / Tennessee North) gets you a “datum mismatch, continue anyway?” dialog before any points get transformed.

That doesn’t stop you from making the wrong call. It just makes sure the wrong call is conscious. The dialog has the actual datum name and the resolved CRS name, so you see “EPSG:32016 is NAD27 / Tennessee North” right next to “you picked NAD83” and have a chance to abort.

The dialog isn’t there for the careful operator who already knows what they’re doing. It’s there for the operator who hasn’t slept in four days and is about to type the wrong code while juggling a phone call. We’ve all been that operator. The dialog is the difference between catching a mistake and finding it three weeks later.

What to do if you have a stack of these

If you’re walking into a firm’s archive that has 200 PNEZD files of unknown provenance, the operational pattern is:

1. Triage by magnitudes first. Sort by the first point’s northing. The local-grid files cluster at the bottom (5,000-ish). The state-plane files cluster wherever your region’s state plane lives. Files that don’t fit either pattern get flagged for manual review.

2. Read every description field of every first row. The five seconds per file pays off across 200 files; the surveyors did try to tell you what the datum is, in about a third of cases.

3. Cross-reference dates against known datum transitions. Pre-1986 files are NAD27. The 1986-1995 files need a closer look. Post-2010 files are usually NAD83(2011) or compatible.

4. For everything still uncertain, route to a “needs phone call” pile. Don’t import it. Don’t guess. Let it sit until you can confirm.

5. Document what you decided for each file. This is the metadata that should have been in the original PNEZD, and now you’re the one writing it. The next person who touches this archive will thank you.

Most firms find that 60 to 80 percent of their undeclared-datum files are confidently resolvable from clues 1-4 above. Another 10-15 percent need a phone call. The rest are unresolvable without ground-truth re-survey – those go in the same pile as the local-grid files and only get touched when a client asks.