The New Datum and Real-Time GNSS Networks

We asked U.S. RTN what their plans are for the upcoming changes to the National Spatial Reference System.

When it comes to geodetic reference frameworks, “shift happens.” Surveyors (and others) have been through this before, like changes from NAD27 to NAD83, NGVD29 to NAVD88, from NAD83(CORS96) to NAD83(NSRS2007), and to the current NAD83(2011). Remember the “I Survived the NAD Shift” T-shirts? However, the next one will be a rather large shift, and while delayed from the originally envisioned 2022-time frame, could come in the next three to five years.  Without a firm timeline, the shift seems a distant reality, but the matter is already becoming a key discussion point within the surveying community. So we decided to address this now.

Change is not always smooth and without pain, but this time around, the shift comes with the bonus of some of the most significant improvements to the National Spatial Reference System (NSRS) to date. And it will include models and tools that can, once folks get used to them, greatly improve the ability to achieve and maintain high geodetic fidelity.

The National Geodetic Survey (NGS), part of the National Oceanic and Atmospheric Administration (NOAA), of the United States Department of Commerce, will replace NAD83 and NAVD88 with new datums. While some like to quibble about the term “datums,” and how it might not strictly apply, “datums” is what the NGS is calling this on its website. That aside, this is not just another iteration of NAD83. The underlying ellipsoid definition will change, bringing the NSRS more in line with global reference frameworks (e.g. International Terrestrial Reference Frame).

How Much of a Shift?

As the NGS notes: “NAD83 is non-geocentric by about 2.2 meters, and NAVD 88 is both biased (by about one-half meter) and tilted (about one meter coast to coast) relative to the best global geoid models available today.” The upcoming National Terrestrial Reference Frame (NATRF2022, a new datum for the continental U.S. and Alaska) could differ from NAD83(2011) by as much as 2.5m (horizontal), and 2.0m (vertical, ellipsoid height). Check the NGS site for more details, and about the new geoid, etc. Users will surely see some not-insignificant differences if they mixed reference frameworks. In some ways this might be a blessing, as differences between past NAD83 realizations may have been frustratingly small and made it easy to mistake one datum for another.

End users will face the same challenges as with earlier datum shifts: dealing with long-term projects, legacy datum specific requirements, and dealing with time dependent shifts (i.e. due to plate velocities). NATRF2022 (it will still be called 2022 even if it does not happen for several years) will initially be nearly coincident with ITRF. However, the NGS will plate fix NATRF2022, and it will diverge from ITRF over time. It was decided that perhaps the end user constituencies—their equipment and software as well—might not be ready for a completely dynamic reference framework yet. Someday… someday…

Approximate horizontal (left) and vertical (right) coordinate differences between NAD83 and NATRF2022. Source: National Geodetic Survey

To help users deal with the datum shift, and the effects of velocity, there will be new time dependent and intra-frame transformation tools. These are being developed using many years of data, from multiple sources, including the NGS National CORS Network (NCN), global geodetic sensor networks, airborne and satellite gravity data, and a helping hand from end users through programs like GPS on Benchmarks.

The Role of RTN

RTN have become an integral part of the geodetic infrastructure that many users rely upon for their day-to-day operations. Most, if not all RTN in the U.S., are highly constrained to the NSRS, with most including some NCN CORS in their arrays of reference stations. An RTN, regardless of which kind, has to apply consistent coordinate values, with high integrity across the entire network, to each reference station. Plus, most end users desire results with high fidelity to published datums. So, it is no surprise that all but a few application-specific RTN, “run” on the NSRS, and presently this means NAD83(2011). An RTN is “on” this datum, and the end user (unless they choose a different or incorrect transformation in their field or office applications) get results in the same datum. I’ve operated an RTN for almost 20 years, and know from experience if you put loose, or inconsistent coordinates into the system, it will set off all kinds of alarms and errors and may not run at all. RTN software suites have become quite sophisticated, with coordinate integrity monitoring features that act as geodetic “canaries in a coal mine.”

Certain misconceptions persist about how RTN work related to datums, transformations, and projections. One misconception is that an RTN is “giving you state plane coordinates” or “LDP coordinates” (low distortion projections). No, those are projections. These happen, including the apllication of geoid models,  in the user’s field software (on the fly), or in their office software. Coincident with the datum shift, there will be, for most U.S. states, new state plane (and in some cases new LDP) projections documented by the NGS and integrated into field/office software by surveying hardware/software manufacturers. This may be source of some confusion and take some getting used to, but as many users have been using RTK and RTN for two decades, they have become quite savvy about the subject.

An RTN is only concerned with the underlying reference frame. It needs to operate in one datum but can output corrections for multiple datums. For instance, an RTN could run—at its core—on NATRF2022, and have outputs for corrections for that but also apply a transformation for NAD83(2011) and offer alternate correction outputs as well. This is not uncommon. Multi-region correction services providers like VRSNow, Smartnet, and Topnet Live already must accommodate multiple datums. Many RTN offered both NAD83(CORS96) and NAD83(2011), at least for a transition period, after that past shift. Some RTN continue to offer multiple correction outputs for different datums, like the Minnesota RTN that offers NAD83(1996), NAD83(2007), and NAD83(2011).

So, what do the RTN have in mind for NATRF2022? We asked U.S. operators, and some in Australia, who went through a similar datum change a few years ago.

Responses from RTN Operators

We sent a link to an online questionnaire to 36 RTN operators in the U.S., to get a good representation of different kinds of RTN: private, public, state run, vendor run, public-private cooperatives, and different brands. For the most part, the responses were nearly identical.

About 40 percent said their plan for the datum change is already decided. But comments noted that the reasons for 60 percent being undecided at this time was dependent on expected announcements from the NGS about the release of datum definitions, and from vendors about integration into RTN software systems. Indeed, there is no firm timeline for the shift yet, so it is understandable that final plans have not been made.

Beyond that initial question, there was a fairly clear picture of how RTN will, or are leaning towards, accommodating the datum change. About 10 percent indicate that they plan to shift immediately after the NGS launch; 10 percent said they are leaning that way, but with 80 percent saying they are not fully committed yet—again, waiting for the pending NGS announcement of the new datum, and vendors about software integration.

In response to a separate question about what additional feedback RTN operators need to finalize plans (an all-that-apply prompt), 45 percent are waiting on the NGS, 70 percent on the RTN software vendors, and 50 percent are seeking more feedback from RTN end users and stakeholders. 

Of the approaches RTN could take to accommodate multiple datums, one option is to run two separate instances of their RTN (i.e. on different servers, with different NTRIP casters). About 10 percent said they were leaning towards this approach, 50 percent said they might do this for a period of time, with 50 percent saying they would not do this. There were several RTN that took this approach for the NAD83(CORS96) to NAD83(2011) shift. That may have been one of the few options a decade ago, but the following is now an option, that is more resource friendly.

This other option is to simply provide alternate mountpoints for different datums. To help the user choose mountpoints, naming conventions could include prefixes or suffixes for the respective datums (e.g. XXXX-NAD832011, XXXX-NATRF2022, etc.) Or NTRIP caster port numbers could reflect the datums (e.g. xxxxRTN:2011, xxxxRTN:2022). About 40 percent said they are committed to providing alternate, datum-specific mountpoints, with another 50 percent willing to do this for a specified period of time. Ten percent indicated they may do no alternate sources, choosing instead to go “cold turkey.”

But what would end users do if an RTN went exclusively to the new datum? About 80 percent of RTN operators responded that they expect users would primarily rely on localize/calibrate methods to match legacy or local datums. Another 20 percent responded that using time-dependent transformation tools could be the primary method their users would rely on. Though these are not viewed as one-or-the-other, respondents indicated they would expect combinations of both depending on specific situations. The NGS plans to release improved time-dependent and intra-frame tools for NATRF2022, similar to, but much improved over present tools like HTDP, and NCAT. Plus, there are new tools in beta from academic geoscience institutions to help work with velocities, like the SOPAC Coordinate Interpolator.

Many respondents provided additional comments; here are some examples: 

  • Shawn Roy, PLS of Michigan DOT, operator of MDOT CORS said, “We plan on moving forward ASAP. Dragging it out only causes more complications as with the change from NAD83(2007).”
  • Randy Osborne of C4Gnet, the statewide RTN in Louisiana said, “We are already offering ITRF2014 and NAD83(2011) mountpoints for users to work in and we will add NATRF2022 as mountpoints once NGS switches to the new datum, and we expect that the software manufacturer will support the new reference frame once NGS publishes it.”
  • Travis Thompson of AZGPS and CALVRS said, “Our Users in California are more likely to use tools like HTDP than our Arizona customers. Although I try to standardize the operations of both, I expect the transition period will be slightly different.”
  • Randy Oberg of Oregon DOT, operator of the ORGN said, “I believe this will be similar to when we moved to NAD83(2011).”
  • Mat Wellslager, operator of the SC RTN reiterated, as many did, that they are awaiting specifics on how the new datum will be implemented in the RTN software, and added, “Besides completing a localization, I foresee the need to have a setting for new jobs to create the job using the NATRF2022 datum without doing any transformation to the data. The corrections will already be derived from the coordinates of the reference stations being on NATRF2022.”
  • Yet another comment put the questions into perspective, “Ask me in a few years when we are closer to the change.”

While plans are not completely firm yet, a fairly clear picture is beginning to emerge. Between the prospects for many RTN to provide mountpoints for multiple datums, and the improved tools from the NGS, RTN users should be well placed to deal with the new datum.

Then we asked some RTN operators down-under how they dealt with their one recent shift…

Australian Example

There was big geodetic shift down-under in 2020. A new reference frame, GDA2020 supersedes the GDA94 datum and older coordinate systems, such as Australian Geodetic Datum 1966 and 1984 (AGD66 and AGD84). The news of this shift gained international attention, but not always for the right reason—some of the coverage was quite a bit off base. It was little disappointing to see headlines like “Australia Is Drifting So Fast GPS Can’t Keep Up,” even in some publications of otherwise high repute. No, it is not that GPS “could not keep up,” it is more of a case of misunderstanding basic geodesy. But all of the silliness aside, Australia undertook this shift for serious, legitimate, and appropriate reasons, much like the NGS is about to.

Michael London is acting deputy surveyor general for the Australian state of New South Wales, which is about 1.15 times the size of Texas.

“My substantive role is a senior surveyor for SCIMS (Survey Control Information Management System), basically our survey control network, and how we publish that information,” said London in a recent web interview. “And obviously, as a manager for CORSNet, which is our real-time network for New South Wales.” There are several state level RTN, commercial, and vendor networks in Australia, and some of these operate, in many ways, in a similar manner.

CORSNet operates 204 CORS for the Australian state of New South Wales. Source: CORSNet

Joining London in the interview was Russell Commins, “I’m the senior systems coordinator for CORSNet, acting in Michael’s role when needed, to coordinate the efforts of the New South Wales coordinates team, and to keep the green lights on the system green.

Salman Shahabudeen, systems administrator for SCIMS & CORS also joined in, as well as other members of the CORSNet team. “I’m a techie working in the team, to make sure that the system doesn’t fall apart,” said Shahabudeen. “And if it does, we started running around and asking for more money.”

Incidentally, I grew up down under, and began surveying there, so it was refreshing to again be treated to the Aussie way of putting things. CORSNet falls under the New South Wales Department of Customer Services (DCS), so there is an emphasis on good customer service—this was key in how they approached the datum shift.

There are a lot of similarities in how geodetic infrastructure is managed in Australia and the U.S. Both have federal entities that operate a nationwide network of CORS; the NGS NCN in the U.S., and Geosciences Australia, with about 100 CORS across Australia and parts of the South Pacific Region. Individual CORS in CORSNet, and most networks around the country are constrained to these national CORS.

“For each of our CORS, we get what they call a Regulation 13 certificate,” said London.  “We submit about a week of observation data for each CORS to Geoscience Australia. They process that against their network to give us a report. That gives us the coordinates that we then use within [the RTN software] to establish what the broadcast coordinates for these particular marks are. So, we have both GDA94 (the old datum), and GDA2020 (the new datum) coordinates for those marks.”

The team noted that while Australia is pretty lucky in that the entire continent is practically one big tectonic plate, there is still a slight rotation and there is velocity. “There is good velocity data that works for about 15 years either side of 2020,” said London.

Though the shift was about 1.8m, he added, “The semi-major axis is the same, and inverse flattening is the same between GDA94 and GDA2020. It’s just the reference frame that is slightly different.” The team said that in terms of NSW they are in a pretty good position (no pun intended) to keep ahead of these matters.

We Should Emulate the Aussie CORS Coordination Approach

Having these federally certified coordinates is good thing, and there are similar resources in place in the U.S. For instance, some RTN submit their stations for NGS “Blue Booking.” But there is another option in the works, that is similar to that which has been very successful in Australia and elsewhere: The NGS is working out details of an “alignment” service for operators of continuously operating reference stations, which are not currently included in the NCN. For example, GNSS reference stations in state, local, and regional real-time networks (RTN).

With this new service, that may commence in coming years, operators of such third-tier reference stations or “community CORS” will provide the NGS with access to station observation files for some or all of its stations. The NGS will process this data to provide up-to-date coordinates and position time-series, just as it does for NCN stations in the first and second tiers (also referred to at the moment as “foundation” and “definitional” CORS respectively). Though this data will not be used as control in the NGS Online Positioning User System (OPUS) solutions.

This provides the NGS with a greater density of position data for NSRS modeling, and the community CORS operators with positions that are aligned directly to the NSRS. This provides a greater density of CORS that can be utilized with alternate methods for GPS on Bench Marks. “Community CORS” could be elevated to “definitional CORS” if deemed to be very stable and of high quality, or necessary to fill in a geographic gap. As an RTN operator, I would say this NGS “alignment” service should be a high priority for the NGS, essential for a successful transition to the new datum.

Accommodating the Users

To accommodate the transition, CORSNet’s approach was to offer NTRIP mountpoints for both datums for their end users. In the RTN software, explained Shahabudeen, you choose the corresponding tectonic plate (and transformation) in the system properties, but in each individual station module you can insert real-time outputs with the default transformation, and different ones for other datums. In their case GDA2020, and additional outputs in GDA94. This is what the U.S. RTN we contacted are likely to do, for NATRF0222 and NAD83(2011).

“We had to maintain GDA94 for the customer,” said Commins. “Obviously, there’s large-scale projects that are still operating on GDA94. We still have to be able to deliver to the customer those coordinates, and that’s all done in the real time streams.” They added an additional caster. The default caster (with port 2101) is on GDA94, and the additional caster (with port 2020) is GDA2020. Users have both choices with the same logins.

I asked what they thought would have happened if they had gone cold turkey to GDA2020 alone. They indicated that there might have been confusion and a tough transition for many users, but also that even with their current dual solution there are challenges.

“We’re now two years down the track, but we’ve still got the majority of users still using 2101 for GDA94,” said Commins. “I’m even finding surveys done in GDA94, and then they transform it to GDA2020 for the paperwork; because that’s just the way they used to do it.”

They did find a way to motivate users to transition to GDA2020. “For GDA2020 we’re offering all of the mountpoints in RTCM 3.2-MSM,” said Commins. “But only selected RTCM3.2-MSM for GDA94. We just kept the old system as the old system, so if people want to use the extra satellites with multi-constellation, they’re going to find it much easier if they move to GDA2020.”

Another interesting note about CORSNet is its operational and funding model. “The way that it works here is we’re completely public, but we’re meant to work as a cost neutral operation,” said London. “But we could never do that. It’s way too expensive to run what we run. So, it’s been recognized within the government that this is critical infrastructure. As such, it’s going to have a certain amount of budget to be able to run each year. We have to apply for any capital, but we very rarely get denied anything.” They offer subscriptions to their own internal users, about 50 internal surveyors, with the subscriptions tied to equipment.

Then there are partners and vendors. “We use local government buildings or sites, as much as possible, or just sites, and build the station there. If they host it, they get subscriptions for free,” said London. “The way we get our external revenue is via bulk data supply to resellers.” This is much akin to how this is done in other countries where the network infrastructure is government, but they lease or sell raw data or corrections to resellers. For example, the Ordnance Survey of the UK licenses data to several of the vendor networks, as does Japan. This can work well for users who work in multiple parts of the country, accessing corrections from a single vendor account.

Ready for the Eventual

In addition to asking CORSNet team members about their experiences, and polling U.S. operators on their tentative plans, I had spoken with operators of some of the RTN in Europe about this same subject.  Many have had to accommodate multiple datums and transitions. The approaches each have taken are uncannily similar. This will likely be the same for this upcoming shift in the U.S.

This time around for the U.S. it will be a big positional shift but should not be any more disruptive than past shifts. Of course, there needs to be related outreach and education initiatives, by the NGS, the vendors, and the RTN.  Surveyors have had to deal with successive reference frameworks and are adept (or should be) at making the right choices for their operations to deal with them.