Opus projects User Instructions and Technical Guide

OPUS Projects 
 
User Instructions and Technical Guide 
 
NOAA | National Geodetic Survey 
 
 
P a g e
 | 79 
 
 
Figure 2.2 - Processing results plots showing an ARP height error 
 
Figure 2.3 - Processing session results plot after ARP height correction 
 
 
 

---

User Instructions and Technical Guide 
 
OPUS Projects 
 
80 | 
P a g e  
 
NOAA | National Geodetic Survey 
 
Section 3 
OPUS Projects Technical Guide
 
Section 3 provides some general guidance and help with making the best decisions while planning a 
GNSS survey and using OP.  This is not meant to be a "survey planning" guide, but only to provide some 
key steps in obtaining good survey data in preparation for use with OP. 
3.0  
Network and Session Design Considerations 
Network Design  
  Each session requires that baselines be defined.  
  Baselines are defined by selecting Hub marks.  
  Every mark that is not a Hub tries to connect directly to a Hub.  
  Only 1 Hub per session is recommended.  A different Hub for a second session where the same 
marks were observed a second time provides closure.  Make the Hub a CORS or other active 
station with 24 hour files if at all possible.  
  Observed mark positions are relative to constrained marks.  
 
Hub mark selection 
  Minimize observations lost to the need for mutual visibility by keeping the distance to the Hub  
< ~100 km.  
  To meet the previous requirement, spatially large projects might require different Hubs be used 
in different sessions.  
  Do not connect a project mark with just a few hours of data to distant CORS (too few mutual 
observations).  
  Take advantage of their continuous data collection by using CORS as Hub(s).  
Troposphere Modeling 
  Model style can be either Step-offsets (SO) between intervals or Piecewise Linear (PWL).  
  In the spirit of avoiding discrete steps transitioning from one tropo interval to the next, PWL 
troposphere adjustments are preferred - nature does not move in discrete steps.  
 
Constraint Weighting 
  The choice is almost always between Tight or Normal constraint weight for the CORS.  
  Hubs (even if CORS) should not be constrained.  Rather the other constrained CORS should 
position the hubs. 
  Many CORS display seasonal motion which makes Tight constraint weight suboptimal.  
  Because multiple CORS will always be used (at least 1 Hub + 1 distant CORS), Normal constraint 
weight seems preferred.  There maybe exceptions to this in places of excessive plate motion 
(velocities) occuring over relatively short periods of time causing unexpected results reflected in 
the coordinates.  If this occurs it is recommended to use Tight constraint weighting. 
 
Network Components 
  Think of a project as having two components: 
o
  Local Network - Think precision and get the best relative positions 

  Use common-mode errors to your advantage.  

  Use identical antennas when possible.  

  Keep baselines short maximizing simultaneous observations.  

  Use a single Hub per session.  

  Use alternate second Hub for next session with observations on the same marks as 
the first session.  Creates closing vectors to marks from two hubs. 

---

OPUS Projects 
 
User Instructions and Technical Guide 
 
NOAA | National Geodetic Survey 
 
 
P a g e
 | 81 
 

  Include at least one distant CORS to stabilize tropo corrections and do not constrain 
it.  

  Use 'Normal' constraint weighting.  
 
o
  Reference Network - Think accuracy (truth) by tying the local network into the NSRS 
(CORS/IGS network). 

  Include the Hub(s) and distant CORS in all sessions.  

  Multiple CORS remove single reference mark bias.  

  Normal constraint weights allow for small variations in positions typical of CORS or 
any group of active stations. If large variations occur (several cm) use 'Tight' 
constraint weighting. 

---

User Instructions and Technical Guide 
 
OPUS Projects 
 
82 | 
P a g e  
 
NOAA | National Geodetic Survey 
 
The plan is to expand this Technical Guide section in the future with more detailed guidelines for 
performing specific types of common NGS surveys using OPUS Projects.  Over time, OP may evolve to 
provide automated specification guidance for people planning to perform NGS-specific surveys.  If you 
are using OP to perform FAA, GNSS Height Modernization surveys, have a good understanding of the 
requirements, and would like to contribute additional "how to" text to this section, please contact the 
OPUS Projects Team at 
[e-mail]
. 
 
 
3.1 
IGS Stations 
For large and/or important projects, include IGS (International GNSS Service) stations (sites) as part of 
the global network control.  This: 
  Provides for an alignment  of your survey to an accurate global reference frame. 
  Some IGS stations are also NGS CORS. 
  Include long and short baselines to IGS/CORS stations. 
The few IGS stations within the USA are part of the CORS network, but in general, CORS stations are not 
IGS stations.  Be sure to review the site log file and history of the station on the IGS web site: 
(
http://igscb.jpl.nasa.gov/network/list.html
). 
 
 
Figure 3.1 - Using IGS stations in your survey 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
3.2 
Verify Correct Antenna Model 
Verify with the CORS site owner that the 'log file' with antenna model named is up to date and 
correct.  Remember that CORS are mostly owned by private firms, city, county and state agencies.  Site 
owners are responsible for maintaining the CORS log file.  The log file reports the current station GNSS 
antenna and receiver equipment, mount details, and owner contact information.  It is prudent to check 
with the owner to make sure the antenna named in the log file is correct.  Processing a project with the 
wrong antenna at any active station, IGS or CORS can introduce large errors into the processing. 
 
 
 
 
 
 
 
  
 
 
 
 
 
 
 
 
 
 
IGS Stations 
 

---