Opus projects User Instructions and Technical Guide

User Instructions and Technical Guide 
 
OPUS Projects 
 
36 | 
P a g e  
 
NOAA | National Geodetic Survey 
 
Figure 1.22 - Session solution Constraints  
 
 
 
 
1.3.5.2.4.7 
Constraint Weights 
Constraint weights are 
applied only to project 
marks or CORS selected to 
be held as constrained 
points in the processing.  
Again, any value initially 
shown here will only be a 
default that can be 
changed when the 
processing is performed.  
Please be aware that 
currently there is no 
differentiation between 
the weights applied to 
horizontal and vertical 
constraints. 
 
Before defining the 
available Constraint 
Weight choices, it may be 
beneficial to preview 
constraints being set for 
session processing so that 
the implications of Constraint Weights default can be more fully appreciated.  At the bottom of Figure 
1.22 one sees that a Constraint Weight of NORMAL was selected.  This could be the default for this 
project, or might have been chosen specifically for this session processing.  The three choices for 
Constraint Weights are: 
 
LOOSE       -allows up to one meter of float for the constrained points in the adjustment. 
NORMAL   -allows up to one centimeter * of float for the constrained points in the adjustment. 
TIGHT        -allows up to one-tenth of a millimeter of float for the constrained points in the adjustment 
(effectively fixing and not allowing the constrained control points to move). 
 
TIGHT (sometimes called fixed) is the default for new projects, but, as the name implies, 
NORMAL should be considered a recommendation allowing up to 1 cm* of float for the constrained 
control points to be adjusted to a true best-fit solution.  *
The constraints are not barriers.  
The NORMAL constraints instruct the program to limit the adjustment to less than about 1 cm, but if it 
"wants" to be greater than 1 cm, it will, although the constraint will increasingly hinder taking on larger 
and larger values.  Think of it as a rubber band.  For adjustments less than a couple cm, 
the rubberband is not stretched tightly and the adjustment can "easily" reach (take on) any of those 
values if the solution demands.  Beyond that, the rubber band is stretched tighter and tighter.  The 
adjustment can reach (take on) larger values, but its got to work harder to do so.  Be aware that 
the rubber band is never slack.  It is always "pulling" towards the specified constraint value to some 
extent.   
 
 
Continuing with the preview, at the center-right of Figure 1.22 example, we see that project marks and 
CORS have been chosen to be constrained as either 3-D, HOR-ONLY, VER-ONLY, or NONE (i.e. completely 
unconstrained).  The default settings for new processing is 3-D constraints on all CORS; NONE for all 
project marks.  The session processing should always follow the intent of the field survey plan. 

---

OPUS Projects 
 
User Instructions and Technical Guide 
 
NOAA | National Geodetic Survey 
 
 
P a g e
 | 37 
 
Figure 1.23 - 'USER' network design 
 
Figure 1.24 - 'CORS' network design 
 
 
 
1.3.5.2.4.8 
Session Network Baseline Design 
The Session Network Baseline Design provides a basic network design strategy for the baselines created 
during session processing.  These network baseline design options for processing should be kept in mind 
during the survey design and preparation stage so that simultaneous observations of project marks and 
CORS, constrained and unconstrained marks will form baselines that are purposely occupied and 
processed.  The Session Network Design default can be changed at processing and, to a limited extent, 
modified by selecting project marks to be excluded from the processing or to be assigned as HUBs.  You 
can only process baselines for marks or hubs that have been simultaneously occupied.  The term “hub” 
is NGS jargon meaning a mark that is preferentially selected for inclusion in baselines.  In other words, 
an included project mark that is a hub is more likely to be connected to other project marks. The four 
Session Network Baseline Designs are: 
 
 
 
 
 
 
USER: Any or all included project marks or 
CORS can be selected as hubs offering a 
limited opportunity to customize the 
network design for the session.  However, 
it is recommended that a hub(s) selected 
be CORS or other active stations with 24 
hour files.  While any selection of one or 
more hubs is possible it is recommended 
to select just one hub per session.  This 
strategy is explained fully in the Technical 
Guide portion of this document.  When 
this happens, the Session Network 
Baseline Design selection will change to 
USER simply to indicate that the selections 
no longer conform to one of the other 
strategies.  Figure 1.23 is an example in 
which the user selected one mark (2139) 
and one CORS (covg) as hubs. As a result, 
the Network Design selection changed to 
USER, since these choices are not 
standard to any of the other options and 
the resulting baselines are indicated on 
the map.  Processing should follow the 
intent of the field survey plan. 
 
CORS:  The CORS Network Design strategy 
automatically selects all included CORS, 
and only the CORS, as hubs (Figure 1.24). 
This emphasizes the number of baselines 
to the CORS which can be a useful design 
if the CORS are to be constrained in the 
processing.  CORS are monitored daily, 
have well determined NSRS coordinates 
and provide strong ties to the global 
network.  Furthermore, CORS that have been in existence for more than 3 years have computed 
(measured) rather than modeled velocities, a characteristic that  is desirable.  Managers should weigh 
CORS quality when planning their surveys. 
 

---