1 / 14

Use OPUS Projects (OP) to provide coordinates for RTN stations

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

kineta
Download Presentation

Use OPUS Projects (OP) to provide coordinates for RTN stations

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Best Practices for Real-Time GNSS Network Administration WebinarMarch 20, 2014 2-5pm ETKey Considerations and Concerns When Using OPUS Projects to Position RTN Active Stations Mark L. Armstrong, PLS – GeodesistOregon State Geodetic AdvisorNOAA’s, National Geodetic Surveymark.l.armstrong@noaa.gov

  2. 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

  3. Key Considerations and Concerns When Using OPUS Projects to Position RTN Active Stations • Discussion Topics • Controlling a priori coordinates for a mark or active station • Dealing with the 99 mark + CORS limitation in OP • How many CORS is enough to adequately control the RTN • The MON vs. ARP height issue for CORS that are also active RTN stations • 5. Reviewing network adjustment reports in OPUS Projects

  4. 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

  5. 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

  6. *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

  7. 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.

  8. Dealing with the 99 mark + CORS limitation is a session within OP *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. WESTERN CLUSTER CENTRAL CLUSER

  9. 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.

  10. 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).

  11. 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

  12. 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 adjustment • Baseline lengths, RMS, and observation stats. • Std error of unit wt for the adjustment

  13. Additional Network Adjustment reports include: • Summary (XML) • SINEX • G-File • G-File (POS) • G-File (r80) • G-File (Vec) • B-File • and graphs for each mark or station

  14. 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.shtml http://www.geodesy.noaa.gov/PUBS_LIB/NGSRealTimeUserGuidelines.v2.1.pdf

More Related