Opus projects User Instructions and Technical Guide

User Instructions and Technical Guide 
 
OPUS Projects 
 
22 | 
P a g e  
 
NOAA | National Geodetic Survey 
 
Figure 1.6 - Preferences  
 
 
 
 
1.1 
Before Any Data Are Uploaded  
Before any data are uploaded into a project, the manager should assign the appropriate project 
preferences.  Preferences allow the appropriate flag and project mark icon to be set.  Changing some 
preferences after the data is uploaded may not result in the correct display.  All project preferences are 
described in section 
1.3.5.2.3
, but those of particular interest immediately after a project is first created 
are: 
 
Data & Solution Quality Thresholds (section 
1.3.5.2.3
): define how processing results are displayed on 
the project’s web pages. This includes the OPUS processing results produced when data files are 
uploaded to the project.  In these cases, a notification is emailed to the person uploading a data file if its 
OPUS results exceed any of these preferences.  This gives OP a limited near real-time problem detection 
capability if data files can be uploaded while teams are still in the field.   Although these preferences can 
be changed at any time, setting them before any data are uploaded enhances their usefulness. 
 
Data Processing Defaults: define the defaults offered on the processing controls. While these 
preferences can be changed at any time or overridden for individual processing requests, they are most 
effective when set before any processing begins thereby helping to impose consistency in the 
processing. 
 
Session Definition: defines how data files are grouped into sessions, i.e. logical associations of data files 
that overlap in time. Sessions define the context of project processing and cannot be changed after 
processing begins without invalidating that processing. 
 
Mark Co-location Definition (section 
1.3.5.2.6
): defines how data files are associated with project 
marks. This cannot be changed after session processing begins without invalidating that processing. 
 
Access the project Preferences 
button here. 
 
 
 

---

OPUS Projects 
 
User Instructions and Technical Guide 
 
NOAA | National Geodetic Survey 
 
 
P a g e
 | 23 
 
1.2 
Uploading Data to a Project 
Currently all data are uploaded to a project through OPUS-S.   [NGS is currently considering a future 
version of OP to allow the use of OPUS-RS for shorter occupation times perhaps down to 30 minutes for 
short baselines.]  OPUS-S provides an easy and accurate way for the project field crew members to 
upload data files to a project and the project manager can review the quality of each solution. 
 
If OPUS-S cannot process a data file, an unusual but not impossible circumstance, OP almost certainly 
won’t be able to either.  So, if OPUS-S aborts processing for any reason, the data file is not uploaded to 
the designated project.  If OPUS-S succeeds in processing a data file, the project will indicate the quality 
of the OPUS-S result based upon the project’s preferences for data and solution quality (Section 
1.3.5.2.3
). The project indicates the quality using the appropriate icon on maps and in lists and by 
background/foreground colors in tables.  
 
Furthermore, if the project’s preferences are not met, OP will send a warning message to the project 
member who uploaded the file.  Receiving one of these warning messages does not prevent a data file 
from being uploaded to or used in a project.  It simply helps highlight potential issues.  It is the project 
manager’s responsibility to make other project members aware of this possibility and its implications.  
The project manager should carefully review each project mark's OPUS-S solution.  The 
coordinate for the first OPUS-S solution for a project mark will be used as the a priori input for the 
processing.  In the rare occurrence that the project manager wishes to change the a priori coordinate for 
a mark, it should be done now before any sessions are processed that contain the mark.  This may be 
accomplished by navigating to the project mark’s web page and editing the a priori coordinate values 
(Section 
2.2
). 
 
As data files are uploaded and marks appear in a project, its manager should also verify the data files 
and related information associated with the project marks.  Quick checks can be made by clicking the 
project mark icons on the manager’s page map.  This will cause an information “bubble” to appear 
displaying the list of data files associated with the project mark and related information such as antenna 
name and ARP height entered with the upload.  A more thorough check can be made from the project 
mark web pages.  There, the data files are also listed along with their related information, and the 
information can be changed, if needed, or data files moved from one project mark to another.  Very 
rarely, other information associated with a project mark, such as the state plane coordinate zone, may 
need to be changed.  This can be done through the ‘Manage Coordinates’ control on the project mark 
page (Section
 1.5.6.2.1
). 
This is also a good time for the project manager to insert appropriate project mark ID if desired. 
Recall that the four character project mark ID are normally taken from the first four characters of the 
vendor proprietary file type or RINEX file uploaded through OPUS to your project.  If inconsistencies are 
found, mark ID's such as a001, a002, etc. will appear.  These are “placeholder” names automatically 
generated by OP.  While there is no programmatic reason to change these automatically generated 
names, it is usually preferable to do so to keep project nomenclature as consistent as possible with field 
logs, datasheets and the like.  A mark’s ID can be changed on its web page. 
Finally, although session processing can begin before all data for the session are uploaded, this is 
not recommended.  Processing before all data are available may be prudent if errors or inconsistencies 
are found and cannot be otherwise rectified, but should be avoided otherwise.  
Please always bear in mind that if a session is processed before all of its data are uploaded, it is 
almost certain that the session will need to be reprocessed after all data has been uploaded.  The user 
has the option to delete individual sessions or overwrite the session by reprocessing using the same 
session name or reprocessing the session but changing the session name thus keeping both sessions. 

---