PNEZD vs PENZD: Check and Convert Point Order

Establish the point before interpreting the row

Start with one point whose Easting and Northing are independently documented. Suppose point 001 belongs at Easting one hundred, Northing two hundred and elevation ten, with description CONTROL. A PNEZD row writes the Northing before the Easting; a PENZD row writes the Easting before the Northing. The same point therefore has two valid serializations. Neither format is intrinsically more accurate, and neither specifies the coordinate reference or the physical unit.

Do not use an example with equal horizontal coordinates to check this distinction. If both values are one hundred, an exchange is invisible. Also avoid relying on the overall shape of a plot: exchanging axes can preserve distances and some recognizable shapes. The test is whether a named known point retains the correct Easting and Northing meanings. Once that is established, inspect several more points, including one far from the local origin.

PNEZD: 001,200,100,10,CONTROL
PENZD: 001,100,200,10,CONTROL
Same point: E = 100, N = 200, Z = 10

Read the actual file instead of trusting its name

A filename containing PNEZD is useful documentation, but the contents are what the importer will read. Open a small extract as plain text. Identify the delimiter, whether there is a header, and how descriptions containing punctuation are quoted. If the first row says Point, Easting, Northing, Elevation, Description while the filename says PNEZD, resolve the contradiction with the source before selecting a shortcut. A heading can itself be wrong after manual editing.

The point-file checker lets you map each field explicitly. For a PNEZD source, assign the second column to Northing and the third to Easting. For PENZD, reverse those two assignments. Keep the identifier, elevation and description mapping tied to the actual source rather than to an assumed five-column pattern. Some exports contain extra codes or omit heights, and those variants need an explicit custom interpretation instead of a guessed standard.

Diagnose an axis swap without inventing a transformation

If known point positions appear exchanged, first check the input map. Correcting a mistaken interpretation is different from numerically transforming a coordinate. A column-map repair assigns the existing numbers their correct roles. A rotation, translation or fitted transformation would create new numbers and can conceal the original error. Do not try to make a mirrored plot look right by moving it before you have ruled out an Easting/Northing mapping problem.

Compare signed coordinate differences from a control as well as absolute values. A wrong grid, wrong unit or different design revision can also produce unexpected positions, and swapping columns will not solve those causes. After correcting the mapping, check the same point in an independently understood reference. If the source still disagrees, stop and investigate the reference information rather than repeatedly changing settings until the display resembles a drawing.

Reorder output only after the source is correct

Once the source is interpreted correctly, choose the destination layout in the converter. Converting PNEZD to PENZD places the already understood Easting before Northing in the new row; it does not move the point. Keep the existing precision unless the delivery specification requires a change. Leave unit conversion disabled when the task is only rearranging fields. Decide separately whether the destination accepts a header and which delimiter it expects.

Save the converted file under a name that describes the actual output layout and version, and keep the source unchanged. Include the source and destination field orders in your handoff note. If a receiving program uses a custom format definition, its column meanings matter more than the format's display name. Review that definition rather than assuming a label such as standard points always means the same arrangement across drawings, templates and software installations.

Perform a round-trip check on every field

Reimport the new file using the destination mapping and compare it with the original interpretation. Easting, Northing, elevation, identifier and description should agree when no value-changing options were selected. Count all records, not only the points shown in a preview. Include a leading-zero identifier and a description containing a comma or quote, because a clean numeric control row cannot reveal quoting or identifier problems elsewhere in the file.

The supplied clean rectangle is a convenient exercise. After changing its serialization, the same four corners should produce area six hundred and perimeter one hundred under their documented metre interpretation. These checks complement the coordinate comparison; they do not replace it. For a real delivery, verify a known project control in the receiving application after import. That additional step can expose a destination format, unit or duplicate-ID rule that differs from the browser settings.

Deal with X/Y headings and missing columns carefully

X and Y are not a universal synonym for Easting and Northing across all surveying documents. Consult the actual export convention and a control point. Where only three coordinate columns exist, NEZ or ENZ may be appropriate, but there is no point identifier to preserve unless another source supplies one. Do not generate arbitrary numbers and then treat them as original field identifiers. If names are created for a downstream workflow, state how and keep the mapping.

A missing elevation does not make a two-dimensional position invalid by itself, but it limits operations that require height. The converter must not fill it with zero merely to satisfy a destination template. Ask whether the receiving task can accept an omitted height, a clearly documented two-dimensional projection or a different file specification. A zero elevation can be a real measurement, so using zero as an undocumented missing-value marker creates ambiguity.

Recognize when field order is not the problem

PNEZD and PENZD do not resolve feet versus metres, grid versus ground distances, different height datums or projected versus geographic coordinates. They also do not encode a project revision, control adjustment or local calibration. Once the row order is correct, those issues remain separate. Use the appropriate confirmed conversion or project workflow instead of expecting a file-layout selector to establish physical compatibility.

For CAD or map files, ordinary point columns may lose information that the original format carries. A TIN needs triangle connectivity; an ordered line needs its vertex order; a KML point needs confirmed WGS84 longitude and latitude. Choose the dedicated tool when the receiving object requires those semantics. Keep the final point file together with its interpretation note and calculation report so another person can distinguish a simple column reorder from a numerical transformation.

Questions and answers