On April 13, the National Geodetic Survey (NGS) held a webinar that described the classifications, accuracy standards and general specifications for GNSS geodetic control surveys using OPUS Projects. The webinar provided a summary of NOAA Technical Memorandum NOS NGS 92, which will be published after it has been through a final review. The presentation can be downloaded here and here. I will highlight some important sections of the webinar, but would also encourage readers to download it and watch it in its entirety.
As described in my March column, OPUS Project 5.1 routine now allows the use of RTN vectors and post-processed vectors from vender software. See my March column or NGS’ January 2023 webinar to learn more about OPUS Project 5.1.
The April webinar described the specifications that are required for GNSS surveys that will be submitted to NGS for publication. It was noted that these specifications are limited to the use of OPUS Project (version 5) for the establishment of North American Datum of 1983 (1983) coordinates and orthometric heights of vertical datums that are part of the current National Spatial Reference System (NSRS). The intent of the NOAA Technical Memorandum NOS NGS 92 is to replace NOAA Technical Memorandum NOS NGS 58 — “Guidelines for Establishing GPS-Derived Ellipsoid Heights, (Standards: 2 cm and 5 cm), Version 4.3” of November 1997, and NOAA Technical Memorandum NOS NGS 59 — “Guidelines for Establishing GPS-Derived Orthometric Heights” of March 2008.
Why replace the guidelines now?
First, there have been improvements in GNSS processing and technology since NOS NGS 58 was published in 1997. The guidelines did not consider the use of real-time kinematic (RTK) technology, the number of NOAA CORS has significantly increased since the 1990s, and NGS’ web-based software OPUS Project 5.1 now allows the use of RTN vectors and post-processed vectors from vender software. In my opinion, there is a difference between guidelines and specifications. Guidelines provide recommended procedures to meet a specific outcome or standard while specifications are an explicit set of requirements that need to be satisfied to meet a specific outcome or standard. In other words, guidelines are general recommendations, and by nature, should be open to interpretation and revised to meet new technological developments.
The webinar described the standards and specifications in 10 tables, which are displayed below. I will highlight a few of these tables that address how RTN vectors and post-processed vectors from vender software can be included in OPUS Project 5.1.
List of Tables:
- Classifications of Network and Local Accuracy
- Description of Mark Types and Anticipated Usage
- Observation Method Requirements for Mark Types
- Standards for Observation Requirements by Method
- Standards for Network Design
- Standards for Monumentation
- Standards for Session Processing and Adjustment Results
- Standards for Achieving Valid Orthometric Heights
- Standards for Equipment Used in Field Observations and Office Procedures
- Standards for Required Documentation
First, NGS has defined three classifications for network and local accuracies in Table 1 — primary, secondary and local. As expected, the accuracy values are different based on the classification. See Table 1. Table 4 provides the observation specifications for each classification.
Table 2 provides definitions that are important to understand. NGS designates three different types of marks in the network design — NCN CORS, GVX base, and passive. See Table 2. Each of these types of marks has its own observation requirements which is described in Table 4.
Information about the GVX vector format can be obtained here. Basically, the GNSS Vector Exchange provides a standard file format for exchanging GNSS vectors derived from varying GNSS survey methods and manufacturer hardware. NGS’s goal for developing GVX is to make it possible to upload vector data to OPUS-Projects. There are different observation specifications for OPUS Project processing GNSS data and for OPUS Projects accepting GNSS data observed and processed by manufacturer hardware and software — that is GVX data.
Please see my October 2021 column for more information on NGS’s GVX format.
A note on abbreviations: PP stands for post-processed; that is, OPUS PP are baselines processed in OPUS Project. GVX PP are baselines processed using a vendor’s software. GVX NRTK and SRTK are baselines from a vendor’s RTK systems.
Table 4 provides the observation requirements for primary, secondary, and local marks. I have highlighted the following items in that table:
- All methods must repeat occupations and repeat sessions/occupations must be offset by 3 to 21 hours.
- Required total static GNSS observation time for OPUS PP is greater than total static GNSS observation time for GVX PP data. That said, OPUS PP requires at least two sessions while GVX PP requires at least three sessions.
- For GVX PP session, the duration of each session increases with distance and a GVX PP baseline cannot exceed 50 km (this is provided in Table 5: “Standards for Network Design”).
- For GVX NRTK, the number of sessions increases to six for primary marks, the duration of occupations decreases to 5 minutes, a GVX NRTK baseline cannot exceed 40 km (this is provided in Table 5 – Standards for Network Design), and the mark requires at least three occupations on different days.
- The use of GVX SRTK is not permitted for primary marks.
Table 5 provides the specifications for network design; that is, the number of NOAA CORS required and the allowable distance from the HUB CORS. The image titled “Project includes 3 or more NCN CORS” provides a depiction of the specifications.
Not all CORS are created equal, so users should evaluate the CORS they plan to include in their GNSS project. My December 2021 column discusses using NGS Map service to evaluate CORS data and plots. Some of the criteria that are used to evaluate CORS include the following: designated as “operational,” computed (measured) velocities rather than modeled (predicted) velocities, “consistent” data depicted in short-term time-series plots, network accuracies ~1 cm to 1.5 cm horizontally and less than ~2 cm to 3 cm in ellipsoid height.
Specifications for GVX vectors are also provided in Table 5. As indicated in Table 5 and previously stated, GVX PP baselines are limited to 50 km and GVX NRTK vectors are limited to 40 km.
An important specification that needs to be highlighted is that the maximum number of vector steps in a vector chain is two. This means there can only be one OPUS PP plus one GVX vector (either GVX PP or GVX RTK) in a vector chain. This is demonstrated in an example in the image below. Also, specification 5.4 states that if GVX vectors are uploaded to the project, then a project needs one or more OPUS PP verified passive marks as checkpoints (these are denoted as GVX Validation Stations). The checkpoint marks have been highlighted in the image below as well.
If your state has many CORS with an NRTK, as North Carolina does, then the image below provides an example of how OPUS projects and GVX vectors can be used to efficiently and effectively establish primary control marks.
Table 7 provides session processing and adjustment results. The achieved network standard highlighted in the image is the same as the classification standard provided in Table 1, which is what should be expected.
The maximum residual values in dN, dE, and dU are also provided in Table 7. This requirement is important because it helps to ensure that outliers are detected and removed, especially in the height component.
The webinar also had tables and diagrams for establishing orthometric heights. Table 8 and Figure 12 from the webinar provide a summary of the specifications. My January column described the specifications for establishing vertical control in the NSRS in more detail.
The image below describes specification 8.3 in Table 8. It is important to recognize that the marks that will be used as vertical constraints need to be observed for two to six hours depending their distance from newly established marks.
A lot of information was presented at the webinar and I only highlighted some important sections of it in this column. I would encourage everyone to download the webinar and watch it in its entirety. It should also be noted that NOAA Technical Memorandum NOS NGS 92 is in draft status and is awaiting several final approvals before it is made available for public comment. That said, the webinar’s contents are subject to minor changes as NGS receives feedback. I would encourage everyone to contact the authors with questions and comments.