In a previous tutorial, we discussed uploading a file to OPUS. That tutorial ended here - at the upload confirmation screen. This tutorial is a follow-on describing the standard OPUS Static solution report. I’m Mark Schenewerk and I’ll be presenting this tutorial.

Typically, OPUS only requires a few minutes to finish processing an uploaded file.

Opening my email window, we see that I’ve already received the solution report from OPUS.

NGS uses a web-based email utility, so your email window will probably appear similar, but not identical to what you see here.

Note that the email is from “opus”, and the subject explicitly states that this email is the OPUS solution. My data file name is also given as is the processing ID. More on the processing ID in a few moments.

When I open the email, I see that the report appears a little jumbled at first glance. This is because the report is a simple text file that my email utility is trying to display as a formatted file. This is specific to my email utility and may not be the case with yours. Changing to a simple text window for this email and now I see the report is nicely structured.

Sending the report as a simple text file means you can save the email as a text file, either using your email utility or by “cutting and pasting” into a text file, then easily view or print it.

Let’s examine the report in detail.

At the very top, my email utility repeats the basic information about this email: who it is from, the date I received it and the subject. Below this header, the report starts in earnest.

First, the name of the file I uploaded and the processing ID are given. This is useful if your email tool doesn’t provide a header with this information.

Remember that OPUS keeps very little information about your activity unless you choose to create a profile or publish, but it does record its own activities. This ID can be used to identify the time of this solution and the specific processing hardware used: information that might prove useful in understanding a problem. If you need to communicate with the OPUS team about a solution report, I encourage you to include the process ID in that communication.

Next is the report banner with a reminder that the uncertainties are peak-to-peak, not 1 sigma standard deviations. This is because this is an OPUS Static solution. It also includes a URL, in other words a web address, where you can get more information about the uncertainties given in the OPUS report.

Below the report banner are the email address I used, the name of the RINEX created from the data file I uploaded, and the date and time that I uploaded my file.

Recall from the “What is OPUS” tutorial that while OPUS accepts many different data file formats, it automatically converts these to the RINEX format as needed, then uses that RINEX file in the processing. In this case, conversion was not required so the uploaded file name and the name of the file used in the processing are identical.

The next block is a short summary about the processing.

The left column explicitly identifies the software, ephemeris and broadcast navigation file used along with the antenna type and height that I entered.

On the right are the start and end times of the data, the corresponding number of observations (both as the actual count and the percentage of the total number of observations), the number of fixed integers (again as a count and percentage of the total) and the post-fit RMS of the result.

At this point, we can begin the quality control of this solution.

I should never need to know the software used, but it does have traceability value for reporting results. OPUS uses the best available, tested and stable NGS software. Although it doesn’t change often, but it does change as models and strategies improve over time. Having this software identification is comforting, to me at least, if I plan on revisiting marks or comparing to results from other software.

Similarly, OPUS always uses the best available ephemeris and broadcast navigation file.

The broadcast navigation file is composite of many nav files from around the globe; thus, there is little change that visible satellites will be missing.

Ephemerides are from the International GNSS Service, or IGS, and are generally recognized as the “gold standard.” An ephemeris is a table of time-tagged satellite positions. In other words, the satellite orbits. The IGS does produce three ephemeris products:

The ultra-rapid is released four times per day and includes both observed and predicted satellite positions.

The rapid is released once per day within 16 hours of the end of the (GPS) day, and only includes observed positions.

The precise, or final, is released about two weeks after the end of the week and includes observed positions only.

Although the precise is considered the most, the ultra-rapid the least accurate, the accuracy of all these products is so good that you should have no concerns about using any of them. So, while there is value in documenting the ephemeris and ephemeris type used, practically, the type can be ignored.

That being said, some projects may require that a specific ephemeris type be used. You’ll hear me say several times to come, follow your project’s specifications.

I always double check that I entered the correct antenna type and height, and I encourage you to do so too. Despite the simplicity of OPUS, it probably won’t surprise anyone to know that most OPUS errors are user errors.

For this data, I’m certain that the antenna used was a “TRMR8_GNSS3” and the antenna height was 2 m.

I also verify that the start and end times match my expectations. I know that the start time was about 18:00 GPS time and the occupation lasted about two hours.

These next three items are about the solution itself.

For the “OBS USED” and “# FIXED AMB”, the bigger the better.

The OPUS on-line documentation recommends the percentage of observations used be greater than 90% and the number of fixed ambiguities to be greater than 50%. However, your project may have its own specifications so, of course, those would supersede the on-line recommendations. My solution has 98% and 96% respectively, and I’m pleased with these.

for the “OVERALL RMS,” smaller is better.

The on-line recommendations suggest less than 3cm. Your project may have other specifications. Personally, I’m uncomfortable with an overall RMS greater than 2cm, so I’m pleased with this overall RMS of 1.0cm.

Below this, I find the information that I’m most interested in: the coordinates that were determined for my data.

Internally, OPUS uses the latest global reference frame, the IGS08 now, at the epoch of the data and always reports these. Then, if it is meaningful to do so, OPUS converts those to the NAD 83(2011) epoch 2010 and reports these derived coordinates.

These coordinate sets are given side-by-side: NAD 83(2011) epoch 2010 on the left; IGS08 at the mean epoch of the data on the right.

Note that the columns are labeled with the datum and reference frame names, and respective epochs.

The geocentric X, Y and Z coordinates, along with their uncertainties, are given first.

The geographic north latitude, east and west longitude and ellipsoid height with their uncertainties follow.

Although not explicitly mentioned, the GRS-80 reference ellipsoid is being used to compute the geographic coordinates.

At the bottom of this block is a derived orthometric height for this mark. This was computed using a hybrid geoid model, specifically the GEOID12A.

Note the uncertainty for the orthometric height is larger than that for the ellipsoid height because it includes the uncertainty from the hybrid geoid model.

This is another opportunity to evaluate this solution. OPUS on-line documentation recommends peak-to-peak uncertainties less than 5cm.

Furthermore, intuition suggests that the horizontal uncertainties should be a little smaller than the vertical, but failing this intuitive criteria is not sufficient to reject a solution.

In my solution I see that the latitude and longitude peak-to-peak uncertainties are both 0.7 cm, and the ellipsoid height uncertainty is 1.3cm.

In this case, the uncertainties are reasonable.

Scrolling down, I see a block of planar coordinates.

UTM, or Universal Transverse Mercator, coordinates can be computed anywhere on the Earth and are always given in the report.

SPC, or State Plane Coordinates, are defined in the United States and its territories and are given on the right if it is meaningful to compute them.

Note that the zones for these coordinates. If these are important for your work, I would advise you to verify that these coordinates are in the appropriate zones.

Although OPUS does its best to identify the appropriate zones for the computed coordinates, it is possible to “slip” into an adjacent zone if the location is near the boundary between zones. If your project requires a specific SPC zone, see the “OPUS Options” tutorial for instructions how to select the SPC zone.

Continuing down the report, below the planar coordinates, OPUS provides a US national grid designation.

Next we see a table summarizing the base stations used in this processing.

Each line contains

●  the Permanent Identifier, or PID, for the base station,

●  a four-character identifier

●  a slightly more human-friendly name,

●  the approximate latitude and longitude of the base station

●  along with its distance from the computed location from my data.

The base stations will invariably be CORS, and OPUS selects them based upon their proximity to my mark and the quality of the CORS data.

Most of the time, you should let OPUS choose the base stations to use, but here, again, your project may specify which CORS to use. Or you may know that a nearby CORS was unavailable, down for maintenance for example, and you want to be absolutely sure that this CORS isn’t used. For these cases, the “OPUS Options” tutorial describes specifying that a CORS be used or excluded from the processing.

Near the bottom of the report, OPUS provides the nearest NGS published control point. With this information, I could retrieve the datasheet for that published mark (assuming I hadn’t already done so).

I happen to know that surveys in this area were published previously and, sure enough, the data were taken on a published mark.

Finally, at the very bottom, we see a disclaimer reminding us that this solution was “computed without any knowledge by the National Geodetic Survey regarding the equipment or field operating procedures used.”

What does this mean?

Always remember that OPUS is a “black box” – a smart “black box” but a “black box” nonetheless. It is your responsibility to use best practices in collecting the data and verifying the OPUS results. In other words, do what you would normally do anyway, be a responsible surveyor.

This concludes the description of the standard OPUS report. We’ve defined all the content and identified a few key pieces of information that can help confirm that the results are valid. There are several other tutorials in this series that may be helpful now or in the future. Links to those tutorials are given at the end of the “What is OPUS” tutorial.