4.3. Data & Solution Quality Thresholds

Data & Solution Quality Thresholds help identify blunders (e.g. an unrealistic antenna height) as well as poor quality data (too few observations used in the GNSS solution, or higher than expected uncertainties). Thresholds also define how processing results are displayed on the project’s web pages. This includes the OPUS processing results produced when data files are uploaded to the project, as well as the results of session baseline processing and network adjustments. The thresholds will flag individual GNSS observation files and specific user marks/CORSs that do not meet the identified quality criteria. For more information on Quality Thresholds, see the About OPUS page. A notification is emailed to the person uploading a data file if its OPUS results fail any of these quality metrics (see Section 6.4). This gives OP a limited, near real-time problem detection capability if data files can be uploaded while teams are still in the field. For this reason, it is best to set these preferences prior to the field campaign for maximum utility. Fig. 4.5 demonstrates the default Data & Solution Quality Thresholds for OP.

Tip

The default values of the preference parameters are appropriate for most projects. A project manager might consider relaxing or tightening the thresholds as needed to support project specifications.

Data & Solution Quality Thresholds

Fig. 4.5 Data & Solution Quality Thresholds

Ephemeris:

If PRECISE is chosen but the “final precise” ephemerides are not yet available (see ephemeris, in Glossary), OP will warn that the manager’s preference was not met. If BEST AVAILABLE is chosen, there is no relevant flag or warning to issue. If the user intends to submit the project to NGS, or otherwise wants to make sure that the very best ephemerides are used, it is recommended to (re)process the project’s sessions after two or three weeks from the date of the last GNSS observation. By this time the “final precise” ephemerides should be available for OP to use.

Caution

For publication, NGS requires that the “final precise” ephemerides be used in processing

Minimum ARP Height / Maximum ARP Height:

The minimum and maximum Antenna Reference Point (ARP) heights are designed to catch blunders (e.g. typographical entry errors). NGS does not recommend antenna heights over three meters to ensure antenna stability.

Minimum Observations Used / Minimum Ambiguities Fixed:

The minimum observations used and minimum ambiguities fixed relate to how noisy the data are, and if there were obstructions which impeded the efficient tracking of each satellite. Higher values are better.

Maximum Solution RMS:

The solution’s Root Mean Square (RMS) is an estimate of the three-dimensional error associated with the post-processed solution. The definition of RMS differs slightly depending on the stage of processing within OP. In the case of an OPUS solution, the RMS is computed as the sum of squared residuals between observed and computed values of phase signal at each observation epoch, for each of the CORSs selected by OPUS. For session processing, the computation is similar, except that the differences are summed for the network of baselines in the session. The lower the RMS, the better.

Maximum Uncertainties:

Height, Latitude and Longitude uncertainties relate to the disaggregation of three-dimensional error into each of the three one-dimensional components. The definition of these uncertainties depends on the stage of processing within OP. In the case of initial OPUS solutions, these errors are expressed as “peak-to-peak” errors which approximate 1.7 times the expected standard deviation among the different one-dimensional coordinate estimates (see OPUS Accuracy for more information). For session baseline processing these uncertainties refer to one standard deviation. As a rule of thumb, maximum latitude and longitude uncertainties should be around 4 cm, and maximum height uncertainty should be about 8 cm for individual OPUS solutions. The lower the uncertainties, the better.

Maximum Pdop:

Option specific to GVX data. Your selected maximum Position (3D) Dilution of Precision (PDOP). Lower values are better.

Minimum Duration(s):

Option specific to GVX data. Your selected minimum duration for a GVX vector, in seconds. If you are submitting your project to NGS remember that the minimum duration is 5 minutes (300 seconds).

Minimum Epoch Used (epochs):

Option specific to GVX data. Your selected minimum epoch requirements for a GVX vector. Higher values are better.

Coordinate Type:

Option specific to GVX data. There are six options:

  • Best Available - no specific requirement

  • Fixed(default) - Coordinates that were derived with GNSS phase angles with fixed ambiguities

  • PartialFixed - coordinates that were derived with GNSS phase angles with partially-fixed integer ambiguities

  • Float - coordinates that were derived from GNSS phase angles without integer ambiguity fixing

  • Code - coordinates that were derived from only the GNSS pseudorange codes

  • Keyed-in - coordinates that were keyed in or entered to the file

Caution

Any recommended thresholds for uncertainties, residuals, differences, errors, etc. given in this document are provided as general guidelines, and are not to be interpreted as standards or project specifications. Refer to your project specifications for exact thresholds.

These thresholds have to be interpreted within the context of a GNSS project. If an observation file is very long, a lower percent observations used, or a lower percent ambiguities fixed may still result in an acceptable solution. In addition, after session processing, quality metrics relative to the initial OPUS solutions often improve (often having to do with the manual selection of CORSs used to control the larger project). Refer to Section 6.4 for checking the quality of your solutions.

Tip

A particular GNSS data file may be flagged as not meeting the Data & Solution Quality Thresholds set of the project but still may process successfully.