Best Practices for Real-Time GNSS Network Administration Webinar
March 20, 2014 2-5pm ET
Key Considerations and Concerns When Using OPUS Projects to Position RTN Active
Stations
Mark L. Armstrong, PLS – GeodesistOregon State Geodetic Advisor
NOAA’s, National Geodetic [email protected]
Use OPUS Projects (OP) to provide coordinates for RTN stations
Provides a network adjustment constrained by CORS which are the backbone of the NSRS and the geometric datum with integral connection to the global frame..ITRF08/IGS08(2005) provides solution reports with global, NAD 83, and local coordinates provides important statistics, graphs, charts and maps provides the ability to match station coordinates of adjacent RTNs (NSRS aligned) provides for NGS corroboration (verification) training for OPUS Projects is available• register for a class here:http://www.ngs.noaa.gov/corbin/calendar.shtml
Key Considerations and Concerns When Using OPUS Projects to Position RTN Active Stations
Discussion Topics
1.Controlling a priori coordinates for a mark or active station
2.Dealing with the 99 mark + CORS limitation in OP
3.How many CORS is enough to adequately control the RTN
4.The MON vs. ARP height issue for CORS that are also active RTN stations
5. Reviewing network adjustment reports in OPUS Projects
Controlling a priori coordinates within OPUS Projects
For each mark or active station added to a project OP uses the first OPUS solution assigned to the project for the a priori coordinate.
While OPUS solutions are known to be reliable and accurate poorer qualtiy may result for several possible reasons i.e., if the GNSS mask is obstructed.
OPUS Projects uniquely provides the ability to change the starting position (a priori coordinate) used in baseline processing for the potential of improved results.
Especially when considering longer baselines and shorter observation times ambiguity resolution and integer fixing are more sensitive to the starting (a priori) coordinate.
• If your a priori position is 0.5 cycles or more in error, then you start increasing the risk that you will fix to the wrong integer. A cycle is ~20cm. 0.5 cy x ~20 cm/cy = ~10cm
Within OP – Controlling a priori coordinates for a mark or active station
*Option 1.)-If the user has a “better” position [NSRS] perhaps from the average of many OPUS solutions under ideal atmosphere etc. [example 10 days of 24 hour files]may be substituted as the new a priori coordinate.
This action may be performed by the project manager on the individual mark page as shown above
*Option 2.)-The manager may also use the a priori coordinate of a mark or station from it’s NGS IDB datasheet. This may be accomplished from the mark page as well.
Select the triangle icon representing the PID for the mark and then select “Use Coordinates”.
Changing the a priori coordinate must be done before baseline processing. Changing it after will invalidate any processing that includes data from that mark.
Pick triangle icon
Dealing with the 99 mark + CORS limitation in a session within OP
Within any particular project session, OP has a built in limitation of 99 marks + CORS (active stations) for all network design selections except the TRI method. There could perhaps be many more stations than that within a statewide RTN that will need to be adjusted within a project.*Option 1.) – Under the managers “Preferences” assign the TRI (Delaunay triangulation algorithm ) for network design as there is no limit to the number of marks + active stations in this sequential baseline processing method.
*For RTN’s the benefit to this TRI method is that all adjacent RTN stations will have baselines (and thus adjusted vectors) between them which can later be compared to the daily RT network QA processing to detect movement in stations.
*Option 2.) – Create separate sessions (or projects) for groups (clusters) of RTN stations each containing less than 99 marks + CORS. Constrain each session/project with all of the same controlling CORS. Overlap of RTN stations between sessions/projects will allow the comparison of final coordinates.
CENTRAL CLUSERWESTERN CLUSTER
Dealing with the 99 mark + CORS limitation is a session within OP
How many CORS is enough to adequately control a RTN adjustment?
General guideline: As a minimum, 3 or 10% (whichever is larger) of the active stations within an RTN should be NGS CORS.
This provides a tie from the continuous real-time network to the CORS Network, the NSRS and the geometric datum.
The NGS CORS sites to be constrained in the network should be distributed as uniformly as possible around and throughout the RTN service area. For the best adjustment of the RTN only use CORS that have the most stable mounts, have proven themselves to be reliable over time (more than 2.5 years old), and have up to date log files with photos. Constraining the RTN to CORS with unknown mounts or unreliable log files can lead to unsatisfactory results. Verify that the antenna and dome in the log file are the ones actually installed at the site. Consider also including one or more IGS CORS sites and refer to the IGS web site for more information on the IGS site locations.
Addressing the MON vs. ARP height issue for CORS that are also active RTN stations
OPUS (and OP) keeps track of the MON to ARP vertical difference (even if it is 0.000m) but will always only report the MON ellipsoid height for CORS in solutions.
This may cause confusion as typically RTN network software wants the ellipsoid heights at the ARP to be entered for all stations. This can be controlled within OP by manually uploading the RINEX files to OPUS for the CORS considered part of the RTN and entering 0.000m for the antenna height. If CORS data is uploaded as a project mark the manager becomes responsible for getting the antenna and coordinates right. When that is done the final adjusted ellipsoid height in the reports will represent the ARP (bottom of the antenna).
Addressing the MON vs. ARP height issue for CORS that are also active RTN stations
Generally CORS owned /operated by UNAVCO’s Plate Boundary Observatory (PBO) have non zero MON to ARP vertical differences…also IGS stations and older PANGA stations.
Most PBO CORS have a MON to ARP height difference of 0.0083 m BUT some have a much larger difference.Care must be taken with station naming such that such that manual upload of a CORS does not conflict with OP automatically including the same CORS. Conflicted icons etc.
CORS automatically added by OP
CORS manually uploaded to OPUS by manager
Reviewing network adjustment reports in OPUS Projects
OP provides reports from OPUS solutions, each session solution, and network adjustments for all marks, active stations, and CORS within a project.
After the network adjustment is completed the following reports are available.
Summary Report: Contains unconstrained , constrained marks and CORS with coordinates in global, NAD 83, and local coordinates.
Sessions included in the network adjustmentBaseline lengths, RMS, and observation stats.Std error of unit wt for the adjustment
Summary (XML)SINEXG-FileG-File (POS)G-File (r80)G-File (Vec)B-Fileand graphs for each mark or station
Additional Network Adjustment reports include:
Questions• For further reading see the ‘NGS Real Time Network
Guidelines’ and NGS User Guidelines for Single Base RT GNSS Positioning
http://www.geodesy.noaa.gov/web/news/Draft_RealTime_Network_Guide.shtmlhttp://www.geodesy.noaa.gov/PUBS_LIB/NGSRealTimeUserGuidelines.v2.1.pdf
