11.6. Analyzing the Processing Report

The most thorough approach to evaluating the results of session processing is to look at the Processing Report available through the “Show File” button on the left toolbar, as shown in Fig. 11.17.

The Show File button on the Manager's Page controls bar

Fig. 11.17 The Show File button on the Manager’s Page controls bar

Example of a session solution processing report (\*.txt file)

Fig. 11.18 Example of a session solution processing report (*.txt file)

Critical items to check in the Processing Report (Fig. 11.18) are the following:

  • The STANDARD ERROR OF UNIT WEIGHT should be near 1.0. The acceptable range is 0.1 to 1.1. Differences are tolerable, but be wary of order of magnitude differences: 0.725 is OK, but 7.25 and 0.072 are not!

  • The TOTAL NUMBER OF MARKS should be what the project manager expects.

  • Under session processing, only the hub(s) should be constrained (CONSTRAINED MARKS: 1).

  • OVERALL RMS should be small and less than the project preference threshold (typically ≤ 3 cm).

  • START TIME and STOP TIME should be as expected

  • The OBS count (number of observations used) should be near the expected number, based on the duration of the observation.

  • OMITTED (% observations omitted), and FIXED (% ambiguities fixed) should all reflect project specifications

  • The A PRIORI COORDINATE SHIFTS should all be small (≤ 2 cm horizontal, ≤ 4 cm vertical).

The table of a priori coordinate shifts (“MARK ESTIMATED - A PRIORI COORDINATE SHIFTS”) provides critical information on how the adjustment may have changed an assumed coordinate (on both survey marks and CORSs). Often, a large coordinate shift may result from poor a priori coordinates stemming from the first OPUS solution (see Glossary for more information on a priori coordinates, and Appendix C for coordinate shifts). A large shift might also be due to a bias at a CORS station. The user might want to remove that CORS from the list, and reprocess without that reference station. If there are no other large shifts remaining, that CORS should likely be excluded from all sessions. However, in some instances, the source of large shifts may remain elusive. Larger than recommended shifts may be fine if the peak-to-peak values (seen after multiple sessions are processed) are small (see Section 11.5.5).

Caution

In session processing, peak-to-peaks are a measure of repeatability among your replicate observations (how closely the session solutions match each other). Coordinate shifts indicate how those solutions compare to the a priori coordinates. For published stations, this could indicate a bias in your data, but also possibly a bias in the published coordinate. Only by running repeat session solutions (changing/removing CORSs, stations, or observations) can you attempt to locate the source of any disagreement