Opus Projects – A Web-Based Application to Administer and Process Multi-Day GPS Campaign DataNeil D. WESTON, Gerald L. MADER and Tomás SOLER, USAKey words: GPS, positioning, campaign SUMMARYThe National Geodetic Survey (NGS) has operated the Online Positioning User Service (OPUS) since March 2001, to provide end-users easy access to the National Spatial Reference System (NSRS) using GPS data. Due to the program's popularity and the continuing list of requests for new features and enhancements, NGS has recently introduced a beta version of a new product called OPUS Projects. This program has been designed to automatically process, in a robust and consistent fashion, GPS data collected during a predefined campaign or project. A project manager, who is tasked with designing, implementing and reviewing the activities associated with a GPS campaign, assigns a specific project code for each GPS project. During the GPS data submittal phase, field personnel submit their GPS data on a daily basis to OPUS, in either native receiver or RINEX format, with the assigned project code. Each dataset is then processed by OPUS to determine initial data quality and position of the station. A solution report for each submitted dataset is then sent to the field personnel and to the project manager for review. If each RINEX file processed by OPUS also passes an additional set of criteria, web-based files, statistics and maps of the project area are updated in a dynamic fashion to include the station associated with the RINEX file before they are saved by project code, session and day number for subsequent network processing. Once all the datasets have been submitted, OPUS Projects generates a list of sessions, each of which can now be processed in a more robust, network fashion. The project manager will then determine which stations to constrain in each session before submitting them for the network adjustment in OPUS Projects. In the final phase of OPUS Projects, the solutions from each of the sessions during a multi-day project are combined using program GPSCOM to produce a single output in the form of a SINEX file. This particular file will now contain the final set of coordinates for each station in the project. OPUS Projects will provide managers and field personnel the ability to manage and view the status of several GPS campaigns via the web. Once NGS has finished internally reviewing OPUS Projects, a publicly available test version may be made available by 2008. 1. INTRODUCTIONThe National Geodetic Survey (NGS) has operated the Online Positioning User Service (OPUS) since March 2001, to provide end-users easy access to the National Spatial Reference System (NSRS) using GPS data. Due to the program's popularity and the continuing list of requests for new features and enhancements, NGS has recently introduced a beta version of a new product called OPUS Projects. This program has been designed to automatically process, in a robust and consistent fashion, GPS data collected during a predefined campaign or project. A project manager, who is tasked with designing, implementing and reviewing the activities associated with a GPS campaign, assigns a specific project code for each GPS project. During the GPS data submittal phase, field personnel submit their GPS data on a daily basis to OPUS, in either native receiver or RINEX format, with the assigned project code. Each dataset is then processed by OPUS to determine initial data quality and position of the station. A solution report for each submitted dataset is then sent to the field personnel and to the project manager for review. If each RINEX file processed by OPUS also passes an additional set of criteria, web-based files, statistics and maps of the project area are updated dynamically to include the station associated with the RINEX file before they are saved by project code, session and day number for subsequent network processing. Once all the datasets have been submitted, OPUS Projects generates a list of sessions, each of which can now be processed in a more robust, network fashion. The project manager will then determine which stations to constrain in each session before submitting them for the network adjustment in OPUS Projects. In the final phase of OPUS Projects, the solutions from each of the sessions during a multi-day project are combined using program GPSCOM to produce a single output in the form of a SINEX file. This particular file will now contain the final set of coordinates for each station in the project. 2. PROJECT CREATIONOPUS Projects was initially designed so all administrative and data processing tasks associated with a GPS campaign could be managed through a number of web pages and tools at NGS. The web pages, in turn, are linked to a number of cgi-based programs to perform several administrative tasks such as creating new projects, adding supplementary data to a project, processing GPS data or modifying an existing project. A project manager could then oversee a number of GPS projects with a web browser, either from their office computer or from a remote location via the Internet. The main web page for OPUS Projects is divided into four primary sections. The first section is used for creating new projects under the OPUS system. A project manager would enter their email address, for electronic correspondence, and the name of the new project and then OPUS Projects would randomly generate the appropriate access keywords for managing and processing GPS data. A database for the email addresses of all the personnel associated with the new project as well as building the directory structure, on the OPUS RAID, to store the campaign data, would also be created. The process, project and manager keywords are then emailed to the project manager who would then distribute them to additional personnel who might be associated with a specific project. Figure 2.1 illustrates the first of four sections on the main OPUS Projects web page where a project can be created. Once a GPS campaign has been started, the field personnel typically submit their observation files through the standard OPUS web site on a daily basis. The project keyword is supplied on the OPUS options web page during each submission so each member of the project receives a copy of the solution report for each site via email. Archiving of the RINEX data and intermediate files are then performed during the file management process.  Fig 2.1 The main OPUS Projects web page contains four sections for administering and processing GPS campaign data associated with a project. The second section of the main OPUS Projects web page is currently under construction but will eventually be used to add supplemental CORS data to any of the defined projects. A series of pull-down menus will allow a manager to include GPS data, which was observed during the same time period as the project, from one or more of the currently available CORS sites in the National CORS network. The data from the CORS sites will then be included in all of the appropriate sessions of the project. The third section illustrated in Fig. 2.1 is primarily used to access the processing web page. To process a specific observation session from a pre-defined project, a manager must identify the project they wish to access and supply the correct process keyword. OPUS Projects has been designed with the anticipation that a manager might administer many projects simultaneously and therefore one method to distinguish each project is through the use of project keywords. The final section on the main OPUS Projects web page is used to access the project administration menus (see Fig. 2.2) and a number of additional features. From this section, modifications to the project name and changes to any of the keywords of the particular project can be preformed. The email database associated with the project can also be edited at this menu as well as managing project files and accessing the project session generator.  Fig 2.2 The OPUS Projects Administration web page provides access to change a number of features associate with a particular project. 2. DATA MANAGEMENTOne of the primary responsibilities of the OPUS Projects manager is to review the solution report for each of the submitted datasets. The data management web page (see FIG. 3.1) provides a pull-down menu which lists each dataset, the time the dataset was submitted and the submitters email address. If a problem is discovered with the RINEX data or the solution, the manager can either contact the submitter in the field or delete the file and request a re-occupation of the site. This tool is useful for tracking and scheduling multiple site occupations during the course of a project. Another equally important tool for processing and verifying site occupations is the session viewer where each session is determined by common occupation times from all the observation data collected during the course of the project. Each dataset which successfully passes through OPUS is deposited into the appropriate session for the day in which the data was collected. Depending on the occupation length and start/stop times of the datasets, a day may contain more than one session or a session may span multiple days. Figure 3.2 shows two sessions for the data collected on October 3rd and 4th of 2006. Session 1 started on the 3rd of the month, had a duration of approximately 19.5 hours, and ends on the next day while session 2 was limited to October 3rd, 2006.  Fig 3.1 The OPUS Data Management web page provides access to each OPUS solution and provides the ability to edit or remove specific data files.  Fig 3.2 The OPUS session viewer lists all the sessions for each day of the project. A pull-down menu displays the stations which were observed in each session. Once a GPS data file has been uploaded to OPUS, the first few steps are to determine the date of occupation and the station’s approximate location on the Earth’s surface. The date is used to retrieve ancillary information from the International GNSS Service (IGS), such as the broadcast and precise ephemeris, while the position of the station is used to select up to three neighboring reference stations from the IGS and/or CORS networks, each of which will participate in a single baseline solution with the user’s station. In the second step, three independent, double-difference solutions are performed, in the ITRF reference frame, between the user’s station and each reference station. The results from the solutions are compared and averaged, but if any section fails to meet a certain set of quality criteria, an additional reference station is selected for a fourth baseline. The main tasks in the final step are to transform the ITRF coordinates into the adopted NAD83 datum (if appropriate) and other mapping projections, such as the UTM, and SPC before producing the final solution report. Once the GPS data file has been uploaded, these three processing steps typically take about three to four minutes to complete but can vary depending on the occupation length. A number of procedures to monitor the quality of the GPS data have been implemented as part of the beta version of OPUS Projects. These routines scan the solution reports to check the overall RMS of the solution, the number of observations used by the processing software and to verify that the minimum occupation time at the site was met. If any of the criteria for a project are not met, then each solution can be reviewed by the manager on a case by case basis. The information in each OPUS solution report is grouped in three main sections. The first section contains information about the user’s dataset such as the start and stop time, the antenna type and height, the number of observations used, as well as the overall accuracy. The second section reports the positional information in the ITRF at the observation epoch, and NAD83 and UTM at the datum epoch. Peak-to-peak values are also stated and are useful in determining the level of agreement between the three individual baselines. The orthometric height at the station is computed from a geoid model produced by NGS and reported if the GPS data were collected in the US. The final section contains information on the three reference stations used in the solution. The distance to each reference station, as well as the distance to the nearest NGS published control point, are also given. Additional reference station information is also given in the third section if the extended output option is selected. Figure 3.3 shows a typical OPUS solution report for 24 hours of data collected at a station (gait) on April 1, 2006.  Fig 3.3 An OPUS solution report for station gait taken on December 13th, 2006. 4. PROCESSING SESSIONSOnce the occupation phase of a campaign has been completed, the project manager can then review each session to determine if adequate observations have been recorded. When a session is selected from panel 1 in Fig. 4.1, the stations assigned to the session are listed in panel 2. A map of the project area is also displayed with the reference stations displayed as blue diamonds and the rover stations displayed as red stars. Additional software coding is currently underway to bring up additional metadata on a station once it is highlighted with the mouse curser. Any station listed in panel 2 can then be selected as a fixed station or hub station for the next processing phase. One or more stations may be removed from a session if they fail to meet certain criteria specified by the project instructions. To prepare for the session processing phase, a number of reference stations are selected to be fixed while others are selected as hubs. Reference station coordinates are usually not adjusted during the least squares process, while stations which are selected as hub sites have additional baselines that radiate to other rover stations. The PROCESS button listed in Fig. 4.1 queues the session for a network adjustment with the selected fixed and hub sites. The hub and rover station coordinates are then solved for in a rigorous network fashion using a least squares adjustment. Each processed session produces a number of auxiliary files containing station coordinates, covariance matrices, normal matrices and additional metadata. The station coordinates are available in SINEX format as well as in the G-file format used by the program ADJUST. The log file and several input files are saved after the processing phase and allow for a detailed examination of all the reference and rover station coordinates, antenna types and velocities applied during the adjustment. Once all the sessions have been processed, the normal matrices from each network adjustment can be combined by program GPSCOM to produce a single SINEX file containing the adjusted coordinates of all the stations in the project. The SINEX format is widely used among the IGS analysis centers and provides a convenient way to exchange station coordinates and information. 
Fig 4.1 The sessions of a project are listed in a dialog box along with the rover and reference stations for each session. A dynamic map is also generated which illustrates the rover and reference stations as each session is selected. 5. CONCLUSIONOPUS is an extremely popular web-based tool for processing GPS data. With a minimal amount of input from a user, a solution for a submitted GPS data file is usually processed within a few minutes and is accurate to a few centimeters. Several modifications to the OPUS processing engine and to the options web page to customize the processing, were made to allow GPS campaign data to be submitted to NGS. GPS data submitted to a project is processed in a quick and consistent fashion using pre-determined parameters and minimizes the impact from having field personnel process the data independtly on a daily basis. Project managers can now define and process projects in a rigorous network adjustment and track their status through a number of web pages hosted by NGS. REFERENCES
BIOGRAPHICAL NOTESN.D. Weston is OPUS Development Team Leader; G.L. Mader is Chief, Geosciences Research Division; T. Soler is Chief Technical Officer for the Spatial Reference System Division. CONTACTS
Neil D. Weston
|
