On paper, a coordinate system can look like a simple project setting. In practice, it can become one of the first things that causes problems when design data moves between surveyors, engineers, GIS platforms, CAD software, and field technology.
The reason is not necessarily that coordinate systems are overly complicated. It is that the information needed to correctly identify a coordinate system is often scattered across different pieces of project documentation, and terms that sound interchangeable are not always describing the same thing.
One common source of confusion is the difference between an EPSG code and a State Plane coordinate system.
EPSG codes vs. State Plane
An EPSG code is essentially an identifier. The EPSG Dataset assigns codes to coordinate reference systems and other geodetic objects so that software and users can consistently refer to a specific definition.
State Plane, on the other hand, is a system of projected coordinate zones developed by the National Geodetic Survey for surveying, engineering, and mapping in the United States. The system dates back to the 1930s, with the State Plane Coordinate System of 1983 being its second major generation.
The important distinction is that these are not competing choices. A State Plane coordinate reference system can have an EPSG code. For example, EPSG identifies “NAD27 / Missouri East” as EPSG:26796 and defines it as a projected coordinate reference system with easting and northing axes and U.S. survey feet as its unit.
This is why simply telling someone that a project uses “State Plane” is usually not enough. They may still need to know the state, zone, datum or realization, and units.
Why this becomes a project problem
Consider a design team that receives a file containing coordinates such as Easting and Northing. Without additional information, those numbers do not tell you where the data is located. The same type of coordinate values can represent very different locations depending on the coordinate reference system.
Even within State Plane, there are multiple zones and different generations of the system. NGS notes that State Plane zones can use different map projections depending on their geographic configuration, including Lambert Conformal Conic and Transverse Mercator.
Units can create another layer of uncertainty. Historically, State Plane data has been published in meters as well as feet, and different states have had different requirements concerning foot definitions. Although the U.S. survey foot was officially retired from new national reference system work after 2022, legacy State Plane 1927 and 1983 data may still use it.
The result is a deceptively simple setup question: What coordinate system is this data actually using?
If that question is not answered before data is exchanged, teams can end up troubleshooting apparent alignment problems that are actually reference-system problems. A model can appear shifted, field coordinates can fail to line up with design data, or two datasets can appear correct individually but disagree when brought together.
The practical solution
Coordinate system information should be treated as part of the project data itself, not as an afterthought.
When exchanging design or survey data, teams should clearly document the coordinate reference system, including the EPSG code when one is available, the datum or reference frame, State Plane zone if applicable, and linear units. When there is uncertainty, tools such as the National Geodetic Survey’s Coordinate Conversion and Transformation Tool can be used to verify and convert coordinates between systems.
This becomes particularly important as the geospatial industry moves through another major reference-system transition. NGS has introduced the State Plane Coordinate System of 2022 as the third generation of State Plane, alongside the modernization of the National Spatial Reference System.
For construction teams, the lesson is straightforward: before asking why two datasets do not line up, first make sure they are speaking the same coordinate language.
What this means for VSite
Coordinate-system consistency is especially important when design information needs to move from the office into field applications. VSite relies on correctly referenced project data so that digital models, GIS information, and field observations can occupy the same real-world location. Making coordinate-system information explicit during project setup can help teams identify potential alignment issues before they become field problems.
