Mastering PNEZD Imports in Orbitas

Table of Contents

The Ultimate Guide to Coordinate Accuracy [2026]

If you have ever needed to navigate directly to a known coordinate in the field, you already know how crucial precise data entry is. In our software, Orbitas, the absolute easiest and most universal way to bring your known coordinates into the system is by importing a PNEZD file.

Once uploaded, these points unlock full Orbitas functionality. You can navigate directly to them, add units, perform bisects, attach photos, and manage your assets.

But what exactly is a PNEZD file, and how do you ensure your data lands exactly where it’s supposed to? Let’s dive into the technical details, the common pitfalls, and the math behind the mapping.

What is a PNEZD File?

PNEZD is a standard, comma-separated value (CSV) file format made popular by land surveyors for easy import into Computer Aided Design (CAD) software like AutoCAD Civil 3D. The acronym stands for the specific orders of the data columns:

  • P: Point (the unique ID or number of the point.
  • N: Northing (Y coordinate).
  • E: Easting (X coordinate).
  • Z: Zed (elevation).
  • D: Descriptor (the descriptor label, e.g., “Pole_01”).

Because it is plain text format, you don’t need fancy software to create one. You can use Notepad, Excel, Google Sheets, or Apple Numbers. This universal accessibility is exactly why Tri-Global chose PNEZD as the default import format for Orbitas. While we support proprietary or unique formats like Shapefiles, Google KMZ, and Autodesk DWG, those formats vary wildly from company to company. PNEZD remains specific, simple, and standard across every single subscription. 

Need a visual on how to create these? Check out our archived YouTube tutorial demonstrating how to generate coordinates using the free online tool GeoPlaner. Or, feel free to reach out to us directly at support@triglobal.net.

The Caveat of PNEZD: Datums & Coordinate Systems

While PNEZD is incredibly simple, its simplicity is a double-edged sword. The format itself contains zero metadata about its inherent coordinate system or reference datum. If you import a list of numbers without knowing what system they were generated in, Orbitas won’t know how to project them, and your data will not import properly. Before you upload, you must understand your source data’s system. 

For a deep dive into the history and mechanics of geographic baselines, check out our companion article explaining the North American Datum

3 Tips for Flawless Imports

To ensure your data imports flawlessly, let’s break down the common mistakes associated with Lat/Lon, State Plane systems, and Elevation values.

The X/Y Transposition (Latitude vs. Longitude)

The single most common error when building a PNEZD file is flipping the Northing and Easting. In standard mathematics and grid systems, we’re accustomed to think in terms of 

(X, Y).

However, the PNEZD standard dictates that Northing comes before Easting. Because Northing is your Y-axis and Easting is your X-axis, the format is actually

(Y, X).

If you are using Latitude and Longitude, it’s easier to spot errors if you remember the geography of your hemisphere. For example, at our headquarters in Athens, Georgia:

  • Y (Latitude/Northing) looks like: 33.7 (positive, because we are in the Northern Hemisphere).
  • X (Longitude/Easting) looks like: -84.4 (negative, because we are in the Western Hemisphere).

Decoding State Plane Coordinates

When working in a State Plane coordinate system, identifying a flipped X and Y can be trickier, but there is a reliable rule of thumb. 

Typically, the Y value (Northing) will be significantly larger than the X value (Easting). This is because your distance north of the system’s Latitude of Origin is usually much greater than your distance east or west of the Central Meridian. State Plane systems deliberately use massive “false eastings” so that all coordinates remain positive numbers. If you ever see a negative number in a State Plane, you have likely projected it using the wrong zone.

The Exception to the Rule

You must always reference your specific State Plane system specification, as there are exceptions. For example, using the same Atlanta coordinates in the Georgia West Zone:

  • X Value (Easting): ~2,225,619 feet.
  • Y Value (Northing): ~1,345,980 feet.

In this specific zone, the X value is larger due to a massive false easting offset of 2,296,583 feet. This highlights exactly why knowing your specific zone parameters is vital.

The Complexity of Z (Elevation)

Elevation data is inherently tricky. GPS devices natively collect elevation as HAE (Height Above Ellipsoid), which calculates elevation based on a smooth, perfect mathematical model of the earth. However, we live on a rugged, irregular Geoid.

Orbitas assumes that any data entered into the Z column of your PNEZD files uses a Geoidal model, or what most people refer to as Mean Sea Level (MSL). 

  • The 2D Shortcut: If you are simply doing standard, two-dimensional navigation back to a point in the field, the Z value won’t affect your XY mapping. You can simply enter “0” for all your Z values. 
  • The Unit Rule: Orbitas assumes the Z value matches the units of your coordinate system. The only exception is Lat/Lon; since elevation in “degrees” makes no sense, Orbitas defaults to meters for Lat/Lon Z-data.

Need Support?

Getting coordinate systems, datums, and file formats to align perfectly can be difficult. If you’re running into issues with an import, or if your points aren’t landing where they should, don’t guess! Reach out to our support team directly, and we’ll help you get your data back on point. 

support@triglobal.net

706-410-2372

Let’s Build What’s Next—Together

Ready to take the next step? Upload your resume and share any relevant work or project links. If there’s a role for you now, or in the future, we’ll be in touch.