Returning later in the day, I found that he had stored his GNSS receiver for a total station. I asked him why he had done this, because he could have completed the job, which took all day with the total station, in a few hours with his GNSS receiver. It turned out that his company had done another site survey in the same area and had left monumented control. However, the checks into the control by the GNSS receiver were so poor that he had decided to store his receiver and pull out a total station to perform the job. 

This two-part article is about why the GNSS receiver successfully located the reference station very precisely but did not check into the company’s control and how to handle this situation when the need arises.

NAD83 (1986), NAD (HARN), NAD83 (2007), NAD83 (2011), WGS84 (G1674), and ITRF08 are all different data (also referred to as reference frames and incorrectly called datums; the plural of datum is data!), and thus different coordinate systems. Until February 2007, in many areas of the county you could not hold both a CORS and a High Accuracy Reference Network (HARN) passive station fixed in a GNSS adjustment because they were in different realizations of NAD83, and thus their coordinates did not agree with each other. 

In February 2007, the National Geodetic Survey (NGS) released a new realization of NAD83 called NAD83 (2007) that combined HARN, CORS, and thousands of other stations positioned by GPS into one adjustment and thus a single realization. Another improvement on this realization was completed in 2012 with NAD83 (2011). 

In the case of the aforementioned surveyor, what had happened is that the NGS had changed its realization of NAD83 between the two site surveys. The provider of the RTN had similarly, and correctly, also changed to NAD83 (2011). Thus, the company’s control from the previous site survey was in NAD83 (2007), but the RTN was in NAD83 (2011). This same problem would have occurred if the WGS84 reference frame from the broadcast ephemeris had been used by the surveyor because it also changed from WGS84 (G1150) to WGS84 (G1674) in 2012.

When performing a GNSS survey, you need to be aware of the fact that coordinates, whether determined by GNSS or by conventional surveys, may be in different realizations of the same reference frame. For example, the current GPS broadcast ephemeris is WGS84 (G1674). This realization of WGS84 was created by the National Geospatial-Intelligence Agency (NGA) from the ITRF 2008 coordinates of the tracking stations that are used to generate the broadcast ephemerides and has an epoch date of 2005. Previous to GPS week 1674, the broadcast ephemeris was in WGS84 (G1150). Similarly, NAD83 (2007) is not the same as NAD83 (1986), the original NAD83, nor the current NAD83 (2012), which is a realization of the IGS08 coordinates with an epoch date of 2010. Confusing? Maybe so, but this is the world we live in.

Solution to Combining Different Reference Frames

How do you handle these differences in the coordinate systems? With all this stated as the backdrop, surveyors must be aware of the sources of the control coordinates in a survey and must bring these various coordinate systems into agreement. 

For example, suppose you are performing an RTK-GNSS survey where the stakeout coordinates are either determined in the original NAD83 datum such as the PA SPCS83 coordinates. The GNSS receiver is determining its coordinates in the WGS84 (G1674) datum. If some conversion between the reference frames is not performed, the direct stakeout of points using the GNSS receiver will not properly place the points in their correct locations. 

Or suppose, for example, that your company has a continuing project using a real-time network, which started before the change to NAD83 (2011). In other words, your control was in NAD83 (2007). Now you come back to your job site to find that the control coordinates established previously using the RTN do not agree with your current surveyed coordinates. Why? 

Because the NGS changed the coordinates to NAD83 (2011) and so did your RTN provider.
How do you handle this difference in the reference frames? Actually, rather simply, because the software developers for GNSS survey controllers and adjustment packages have built the solution into their software. Its name varies but is typically called “site calibration” or “localization” by manufacturers. Unfortunately, the solution may not be the same, and thus different results are possible. So, let’s look at the possible solutions. 

In geodesy, the original solution to this problem was known as the Molodensky equations. However, today the Helmert transformation has shown that it produces a better transformation. The Helmert transformation, which was developed by Willem Helmert in the late 1800s, is a simplification of the three-dimensional conformal coordinate transformation. However, both the Molodensky and Helmert equations require that your “local” stations have “real-world” coordinates such as state plane coordinates and elevations, geodetic coordinates, or geocentric coordinates. 

Surveyors often like to work in an arbitrary project coordinate system such as (5000, 5000, 100), which last only as long as the monuments exist on the ground. To handle this situation, software developers use a two-dimensional conformal coordinate transformation to bring the horizontal coordinates from GNSS into agreement with the local horizontal coordinate system, and they have developed a three-parameter adjustment to bring the GNSS-derived heights into agreement with the local elevations. 

To perform the horizontal transformations, the software creates a temporal map projection system with its origin at the center of the local control or placed at the first occupied station. They often use an oblique stereographic map projection system to transform the GNSS-derived geodetic positions into northing-easting map coordinates. This map projection is set at or near the surface of the Earth to alleviate the problem of scaling differences between the ground and grid distances. 

Using the surveyor-generated arbitrary horizontal coordinates and the GNSS-derived map projection coordinates for the same stations, the software determines the scale, rotation, and translations necessary to convert the GNSS-derived horizontal coordinates into the local horizontal coordinate system. (Some surveyors like to fix the scale to 1 in this transformation. This should not be done because there is always a slight scaling difference between reference frames, even when the length units are in the same units, such as survey feet or meters.)

The local elevations and GNSS-derived heights will not match either. In fact, due to deflection of the vertical differences between the geoid and ellipsoid normal, the surface as determined by the local elevations may not be parallel with the ellipsoidal surface of the heights as derived by a GNSS receiver. Note that the curved surface of the ellipsoid will be close to a plane over a small region of the Earth. 
The conversion between the two surfaces is handled by a three-parameter equation that determines the rotational differences between the two surfaces in the cardinal directions of north-south and east-west, along with a translation. This brings the surface as defined by GNSS-derived heights into agreement with that as defined by the local elevations. 

Note that the differences in the geoid heights for each common bench mark station represent systematic errors, and thus by theory should be removed using the most current geoid model. This conversion from geodetic heights to orthometric heights/elevations is performed in the software  when the appropriate geoid model is loaded into the controller. 

If the geoid model is not included, a portion of these systematic errors from the difference in geodetic and orthometric heights will appear in the residuals of the results for the vertical solution; it will also change the transformation parameters slightly, resulting in a different solution to the transformation. In this two-part solution, if only one common point is known in its horizontal and vertical position, the software will simply determine the translations between the two systems at a much-reduced level of accuracy. 

However, once these transformation parameters are determined, the software then takes any subsequent GNSS-derived coordinates and transforms them into the local survey coordinate system. Thus, it gives the surveyor coordinates from his or her GNSS receiver in the surveyor-defined local coordinate system, which could also be orthometric heights and state plane coordinates.

Cautionary Notes

In the field, the procedure for bringing the reference frames into agreement involves starting the project by occupying a minimum of two control points with known “local” horizontal position and three with known “local” elevations. Of course, for the purposes of checking the results of the transformation, it is always better to have more than the minimum control, and the NGS recommends that you occupy four stations of each type and that these four be in four different quadrants of your project area. It is also wise to have one or two additional stations as checks after the transformation. 

After occupying the common points with a GNSS receiver, the software determines the transformation parameters and then uses these to convert the GNSS-derived coordinates into the desired datum for the survey. 

As stated earlier, always include a geoid model with your GNSS-derived heights to remove the systematic errors from the vertical part of the adjustment. Never perform this localization more than once because random errors created by the GNSS survey will result in a slightly different transformation each time it is performed. If performed more than once you will be creating different realization of the coordinate reference frame for your project! 

It is unwise to work outside of the area bounded by the common control points. This is because the transformation is valid inside the bounds of the control but can result in much larger positional errors due to the uncertainties in the derived transformation parameters outside the area bounded by the control.

Additionally, always include important points in this transformation. For example, in a highway alignment project involving a bridge with a bench mark on its abutment, the engineers designing the new bridge will most likely use this bench mark elevation in their design. It would be wise to include this bench mark as part of the control no matter where it lies in the project, as shown in Figure 1. This will provide you with a check on bench mark elevation and that of the other bench marks included in the survey, which ensures that the alignment will correctly meet the bridge deck.

Also note in Figure 1 how the four common points that are used as control are near the edges of the project area. Make sure that your common points do not lie in nearly a straight line as shown in Figure 2.

This is especially true on highway projects where control tends to lie near or within the alignment itself. What this creates is a knife-edge set of control, which means that the plane that defines the transformations can, and probably will, wobble significantly a short distance from this line. 

Theoretically, the standard deviations on the deflection of the vertical rotations will be large, resulting in large uncertainties as one travels away from this line. It will affect both the horizontal and vertical coordinates from the transformation with most of the error being seen in the vertical component. In essence, the transformation will only be valid for points along this line and will fail when off the line. 

This article presents a common problem in surveying practice today: the existing control used in a project is often not in the same reference frame obtained from a GNSS receiver. It is wise to check the reference frame for any control before entering the field and developing a plan for field crews to follow once in the field. If coordinates for the control exist in the two reference frames in the office, the transformation parameters can be determined in the office and uploaded into the controller(s). If this is not the case, the field crews need to perform the localization process in the field. 

However, once this is performed for the project, it should not be done again. Instead, the transformation parameters should be transferred to the appropriate controllers involved in the project.
In the second part of this article, I present a solution to another problem in the localization process. It deals with a proper method to decide whether the transformation process was successful or whether there are blunders in some of the local control or poor field practices with the GNSS observations.