The PNEZD Format: How Survey Point Files Actually Work

Every survey workflow eventually funnels through a small text file of points. Whatever your field app or CAD package, the lingua franca is a delimited file where each line is one point. The most common arrangement in the US goes by the name PNEZD, and understanding it (and its traps) will save you from some of the most expensive silent errors in surveying.

What PNEZD stands for

PNEZD is simply the column order:

• P — Point number (or point name): a unique identifier, usually an integer
• N — Northing: the north coordinate
• E — Easting: the east coordinate
• Z — Elevation (the "Z" coordinate)
• D — Description: a free-text field, typically starting with a feature code

A minimal comma-delimited PNEZD file looks like this:

1,4999.987,5000.012,101.25,CP1 FOUND IRON ROD
2,5123.450,5087.220,100.98,EP
3,5124.101,5121.870,100.87,EP
4,5150.223,5099.010,101.55,TREE 12IN OAK
5,5010.550,5155.780,102.10,FH FIRE HYDRANT

Five points, five fields each, human-readable in any text editor. That simplicity is why the format has survived for decades.

Why column order matters so much

Here is the trap: a PNEZD file and a PENZD file look identical to the eye. Both are five columns of a point number, two similar-magnitude coordinates, an elevation, and a description. The only difference is whether column 2 is the northing or the easting. When CAD software imports the file, you tell it the format ("PNEZD comma delimited" is a stock choice in Civil 3D and similar packages). Pick the wrong one and every point lands with its X and Y swapped, mirrored across the northeast diagonal.

On a site with similar northing and easting magnitudes, a swapped import can look plausible at first glance, which is exactly what makes it dangerous. The defense is procedural: always confirm the ordering with whoever produced the file, and always check one known point after import before trusting the rest.

Common variants

Delimiters vary too. Comma is the norm today, but space-delimited files are still common from older data collectors. Space delimiting has its own trap: a description like "FOUND IRON ROD" contains spaces, so naive parsers split it into extra columns. Comma-delimited files have the mirror problem when a description contains a comma. The safe conventions are: comma-delimited, descriptions last, and if your software supports it, descriptions quoted.

Point codes and descriptions

The description field usually carries more than prose. Most crews use a code list: EP for edge of pavement, FH for fire hydrant, TC for top of curb, and so on. In CAD, description keys match those codes to symbols, layers, and label styles automatically. Field-to-finish workflows go further, using codes plus line control (start line, end line) to draw the linework itself from the point file. This is why a disciplined code library matters: the description field is effectively an instruction stream for the drafting software, not just a note. (Code libraries and automatic linework are among the features some field apps reserve for paid tiers; see our Emlid Flow alternatives roundup.)

The units trap: three kinds of "feet"

Nothing in a bare CSV says what units it is in. Three candidates are in circulation:

• Meters — what GNSS processing works in natively
• International foot — exactly 0.3048 m
• US survey foot — 1200/3937 m, about 2 parts per million longer

Two ppm sounds negligible until you remember state plane coordinates run into the millions of feet. Interpreting a US survey foot coordinate as international feet shifts positions by several feet in absolute terms, a classic and well-documented blunder. The US survey foot was officially deprecated for new work at the end of 2022, but decades of legacy state plane data still use it, and several states used different feet historically. If a fit against control shows a small systematic scale error, suspect the foot definition first; the symptom also shows up as a strange scale factor in a site calibration.

What a bare CSV silently loses

A PNEZD file records coordinates but not what they mean. Missing from the file itself:

• The coordinate reference system and zone (which state plane zone? local grid?)
• The datum realization and epoch (NAD83(2011) 2010.00? ITRF2020 current epoch? These differ by 1 to 2 meters)
• Whether elevations are ellipsoidal or orthometric, and which geoid model (GEOID18, EGM2008) was applied
• Units, as covered above
• Quality metadata: fix type, RMS, PDOP at the moment of each shot (see why per-shot metadata matters)

The file "works" without any of it, right up until someone combines it with data on a different basis. Write the metadata down: in the transmittal email, in a header comment, in the filename if nothing else. Open Survey, currently in development, plans to stamp datum and epoch on every export, including PNEZD CSV, precisely because bare files lose this so easily.

Tips for clean round-trips between field and CAD

• Standardize on one format (comma-delimited PNEZD is a sane default) and state it explicitly with every file transfer.
• Keep descriptions comma-free, or quote them, so parsers never mangle a line.
• Reserve point-number ranges (control in 1–99, topo from 1000, staked points from 5000) so re-imports never collide with existing numbers.
• Never renumber points mid-project; the point number is the join key between field notes, raw observations, and the drawing.
• After every import, spot-check a known point's coordinates and units before drafting on top of the data.
• Archive the raw export alongside the drawing, with datum, epoch, units, and correction source recorded next to it.

The PNEZD file is not going anywhere. Treat it as what it is, a five-column contract between your field app and your CAD package, and make the missing metadata explicit every time it changes hands. If you are newer to GNSS field work, our RTK GNSS surveying primer covers where these coordinates come from in the first place.