Opus projects User Instructions and Technical Guide

User Instructions and Technical Guide 
 
OPUS Projects 
 
76 | 
P a g e  
 
NOAA | National Geodetic Survey 
 
  The STANDARD ERROR OF UNIT WEIGHT
4
 should be near 1.  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 OVERALL RMS should be less than the project preference threshold (Section 
1.3.5.2.3
). 
Each baseline’s RMS should be less than the project preference threshold (Section 
1.3.5.2.3
). 
  The OBS count (number of observations used) for each baseline should be near the expected 
number based upon data duration and field logs. 
  The percentage of OMITTED observations should be smaller than the implied preference.  If the 
Observations Used preference (Section 
1.3.5.2.3
) was set at 80%, then the OMITTED should be 
less than 20%. 
  Ambiguities FIXED to integers should also meet the preference set (Section 
1.3.5.2.3
). 
The uncertainties for the coordinates should be less than the project preference thresholds 
(Section 
1.3.5.2.3
). 
 
Figure 2.0 - OP solution report 
                                                           
 
4
 The standard error of unit weight is a scale factor generated from the least squares adjustment which (in effect) 
judges how well your a-priori weights were set.  If you set them too low, the standard error of unit weight will be 
greater than 1; if you set them too high, it will be less than 1.   
                   NGS OPUS-PROJECTS SESSION SOLUTION 
REPORT 
                  
=========================================== 
 
 All coordinate accuracies reported here are 
1 times the formal 
 uncertainties from the solution. For 
additional information: 
 dev.ngs.noaa.gov/OPUS/Using_OPUS-
Projects.html#accuracy 
 
 These positions were computed without any 
knowledge by the National 
 Geodetic Survey regarding the equipment or 
field operating procedures used. 
 
 SUBMITTED BY:                  
mark.l.armstrong 
 SOLUTION FILE NAME:            2006-275-
B.sum 
 SOLUTION SOFTWARE:             
page5(1212.04) 
 SOLUTION DATE:                 2013-05-
15T17:09:23 UTC 
 STANDARD ERROR OF UNIT WEIGHT: 0.742 
 TOTAL NUMBER OF OBSERVATIONS:  45498 
 TOTAL NUMBER OF MARKS:         8 
 NUMBER OF CONSTRAINED MARKS:   4 
 
 OVERALL RMS:                   1.5 cm 
 START TIME:                    2006-10-
02T00:00:00 GPS 
 STOP TIME:                     2006-10-
03T23:59:30 GPS 
 PROGRAM OPERATION:             FULL RUN 
 FREQUENCY:                     L1-ONLY TO 
ION-FREE [BY BASELINE LENGTH] 
 OBSERVATION INTERVAL:          30 s 
 ELEVATION CUTOFF:              15 deg 
 TROPO INTERVAL:                7200 s 
[PIECE-WISE LINEAR PARAMETERIZATION] 
 DD CORRELATIONS:               ON 
 

---

OPUS Projects 
 
User Instructions and Technical Guide 
 
NOAA | National Geodetic Survey 
 
 
P a g e
 | 77 
 
 
2.1.1  Other Solution Reports 
Processing reports sent via email from sessions include the report summary in both text (*.txt) and 
Extensible Markup Language (*.xml) formats, the output from the processing engine (*.sum) file, a 
Solution Independent Exchange (*.snx) formatted file, and several files (serfil, g-file, b-file) useful for 
submitting to the NGS, i.e. “bluebooking”.   All files may be open with Notepad, TextPad or some other 
similar text reading program.  The solution summary is described in Section 2.1 and Appendix C.  The 
Extensible Markup Language, or XML, file may be used to create a custom formatted report or be read 
by other software.  The processing engine output is challenging to read, but contains the most complete 
description of the solution.  The Solution Independent Exchange, or SINEX, file is commonly used in 
academic applications.  It contains enough information to derive the solution or combine the results 
with others to create new solutions.  The serfil provides a list of four digit mark IDs for use in a separate 
post processing scenario.  
 
 
2.1.2  The Bluebooking Reports 
Figure 2.1 - Example final network solution summary 
The OVERALL RMS should be less 
than the preference threshold set by 
the Manager. 
 
Standard Error of Unit Weight for a 
normal solution should be between 
0.1 and 1.1  

---

User Instructions and Technical Guide 
 
OPUS Projects 
 
78 | 
P a g e  
 
NOAA | National Geodetic Survey 
 
For every session solution, a GPS data transfer file, more commonly called a g-file, is created using the 
NGS standard SINEX2G program.  A complete description of this file format is found in the FGCS Blue 
Book document “
Annex N: Global Positioning System Data Transfer Format (G-File)
”.  The g-files are 
stored with the session solutions and, as mentioned, included in the reports emailed to the individual 
performing the processing.  The SINEX2G program also creates several useful supporting files.  Most 
important of these is the serfil.  This is a simple text file providing a cross-reference between  station 
serial numbers (SSNs) and mark ID ( see “
Annex L: Guidelines For Submitting GPS Relative Positioning 
Data
”).  The *.pos files contain a list of mark coordinates.  The *.r80 files also contain the marks’ 
horizontal coordinates, but in a specific (*80*) format.  The *.vec files contain the baseline vector 
components. 
After network adjustments, the g-files from the included session solutions are combined thereby 
creating the g-file for the adjustment; while the adjustment’s HORIZONTAL OBSERVATION (HZTL OBS) 
DATA, commonly called the b-file (“
Chapter 2: Horizontal Observation (HZTL OBS) Data
”) is created using 
the network adjustment plus the occupation information from the marks included in that adjustment. 
Remember that the occupation information for a mark defaults to the information in and provided with 
the mark’s data files when they were uploaded.  Also remember that this default information can be 
modified through the mark web page (Section 
1.5
 and 
2.2
).  Needless to say, the more complete and 
accurate the occupation information, the more complete and accurate the b-file will be created.  The 
network adjustment b- and g-files are stored with the adjustment and included with the reports emailed 
after the adjustment.  All session processing and network adjustment reports are also available through 
the project’s web pages.  Once the b- and g-files are in hand, it remains the project manager’s 
responsibility to verify the files and to complete the other steps required to submit to the NGS for 
bluebooking. 
2.2 
Project Mark Web Pages 
The project mark web pages offer two critical tools for evaluating and analyzing processing results: the 
Processing Results Plots (Section 
1.5.7
) and Tables (Section 
1.5.8
).  These display the resulting 
coordinates for a mark from all or selected project processing results.  Provided that consistency was 
maintained in the processing, similar classes of results, for example session processing results, should 
“cluster” together.  Outliers can be identified, and the occupation and source processing solution 
scrutinized.  This “repeatability” does not guarantee, but it is necessary for, a valid adjustment. 
 
Figure 2.2 shows a contrived case, but one based upon actual incidents, where a vertical outlier is found. 
The outlier is evident in the Up versus GPS Time, the plot on the right, at approximately 2006-276T20.  In 
this case, both the OPUS-S solution and session solution gave similar results, and there is no similar issue 
in the North versus East plot on the left.  A hypothesis explaining this evidence is an ARP height error.  A 
comparison of the Occupation information for this mark to the field log for the offending data file 
confirmed an ARP height input error at upload.  Correcting this on the mark’s page and reprocessing 
gave the results shown in figure 2.3.  After the correction, the horizontal and vertical session processing 
results agree.  The OPUS-S solution corrupted by the incorrect ARP height remains serving as a reminder 
of the original error.  Another possible response would have been to upload the offending data file again 
using the correct ARP height.  The data file and information from the re-upload would have replaced the 
original and, after reprocessing, the OPUS-S and session processing results would all agree. 
 
 
 
 
 
 
 
 
 

---