F. Tying a Real-Time Network to the NSRS

OP may be used for tying coordinates of real-time network control stations to the NSRS. A more formal NGS NSRS validation process/service may be available in the future. The following is an outline of general ‘best practices’ for tying an RTN to the NSRS, mostly concatenated from current general guidelines outlined in Section V. of Henning et al (2013) NGS Guidelines for Real Time GNSS Networks.

F.1. Determining RTN Station Coordinates using OPUS Projects

It is recommended that the RTN Administrator follow the procedures outlined in this manual (especially Sections 10 and 11) to perform the sequential network adjustments on simultaneous observations from the real-time base stations as required for submitting the project to NGS. Following these procedures, the coordinates derived for the real-time base stations will be properly tied to the NSRS.

Tip

NGS accepts survey project proposals intended to tie RTN base stations to the NSRS via OP: a NGS Project Tracking ID will be issued as with any other GNSS survey project designed to be submitted to NGS

For this task, it is recommended that a minimum of five (5) twenty-four (24) hour data sets be used for each base station that is not a CORS in the network adjustment. The corresponding 24-hour data files are uploaded into the project through the regular OPUS data file upload page, noting that the antenna heights would be set to zero (0.0000 m).

Tip

For connecting RTN base stations to the NSRS, only RTN base station data (24-hour files) need to be downloaded from the network and uploaded to OP; there is no need to download/upload CORS data

F.2. Mon vs. GRP vs. ARP

Published CORS coordinates are automatically seeded into OP projects when RTN active station data is uploaded through OPUS to an OP project. In many cases, the published height at a CORS is with respect to the ARP, or “antenna reference point.” It may also be published with respect to the GRP, or “geometric reference point,” which is virtually the same as the ARP. In some cases, however, the published height is attributed to the MON, or “monument.” OPUS keeps track of any MON/GRP/ARP vertical offsets (even if it is 0.000m) but will always only report the MON ellipsoid height for CORS, if available. This distinction is typically unimportant for most projects, but in the case of an RTN project where CORS may also be part of the RTN, the project manager must be aware of this MON vs ARP distinction. The difference between coordinates for the MON vs. GRP vs. ARP may cause confusion, as RTN network software typically expects the ellipsoid heights at the ARP to be entered for all stations.

Example project which includes RTN base stations as user marks in OP

Fig. F.1 Example project which includes RTN base stations as user marks in OP

Large real-time networks can be completed sequentially in OP by creating multiple projects containing RTN clusters that overlap each other providing the ability to check the same station coordinates in different projects, as shown in Fig. F.1. Each cluster project must use identical constraining CORS. While this multi-project technique produces good results, adjusting the entire RTN as one project produces the best results.

F.3. Use the Latest Absolute Antenna Calibrations

Since 2011, NGS has been using Absolute Antenna calibrations in the definition of the national reference frames. The latest absolute antenna patterns are automatically used in OPUS and thus OP as well. Within each antenna calibration file there are north and east orientation values. For best results, therefore, each antenna’s North Reference Point (NRP) should be aligned to true north. Normally all CORS are orientated to north when they are installed. The NGS maintains an antenna calibration web page where absolute calibrations are provided for most geodetic GNSS antennas currently on the market.

F.4. Collect Station Data During Optimal Weather Conditions

Typically, the errors remaining in GNSS after modeled effects are removed result from signals going through the troposphere. It is therefore recommended to collect RTN station data (to use in processing) during a dry weather period when high pressure may dominate the entire RTN coverage area and tropospheric conditions are uniformly stable. Care should also be exercised not to use data taken during periods of high ionospheric disturbance. The National Weather Service Space Weather Prediction Center provides information and warnings of these periods; see https://www.swpc.noaa.gov/.

F.5. Tie RTN Stations to the NSRS Using Select CORSs

It is recommended that the RTN be tied to the NOAA CORS Network (NCN). This is very easy to achieve within OP as the access to the entire NCN is available within the program. At least 10% or a minimum of three (whichever is greater) of the RTN active reference stations should be part of the NCN. This provides a continuous real-time network tie to the NCN, the NSRS, and the geometric datum. The NCN sites to be constrained in the network should be distributed as uniformly as possible throughout the RTN service area. For the best tie, use CORS that have proven themselves to be reliable and stable over time, and have up to date log files with photos. Verify that the antenna and radome in the log file are the ones actually on the mount during the time the data are downloaded. Include constraining to one or more IGS CORS sites and refer to the IGS website for more information on the IGS site locations: http://igscb.jpl.nasa.gov/network/netindex.html

Caution

OP lists both NCN and IGS Stations (not in the NCN) as “CORS.” Clicking on the individual CORS for more information will reveal which kind of station it is.

F.6. Coordination

Real-time networks that are adjacent to one another may want to consider coordinating their efforts to position their networks such that rover operators may cross RTN borders and expect to work effectively with common, homogeneous coordinates. Thorough testing of the network correctors, supported by empirical data, may provide some assurance of common coordinates corroborated by independent OPUS Static solutions.

F.7. Field Tests

RTN Administrators may elect to occupy a subset of passive marks with rovers to compare RTN derived positions with the NGS national adjustment positions in the same reference frame. However, the correctors any given RTN provides may yield coordinates for an RTN rover, at passive control, that disagree with NAD 83(2011)2010.00 coordinates. Note that the processed vectors used in the national adjustment of 2011 (NA2011, which yielded NAD 83(2011)) are from surveys spanning nearly 20 years and therefore based on equipment and software used at the time of the original survey. Additionally the adjustment will not account for possible mark disturbance or movement since the observation date. Western states’ passive marks may be subject to significant tectonic plate motion which complicates efforts to assign long-lasting, stable coordinate positions. In fact, even in the most “stable” part of the North American Continent, residual interplate motions are known to exist. For checking the validity of RTN correctors after tying the network to the NSRS, it is recommended to perform a static GNSS occupation on the passive mark, and compare the new independent OPUS solution to the RTN-rover-based coordinate value. This method uses the identical survey epoch (with similar atmospheric conditions) and hardware, with the only difference being the method of computation (OPUS vs. RTN).

F.8. Monitoring RTN Station Coordinates

After a successful submission of the RTN project to NGS, NSRS coordinates will be published for the RTN base stations (not part of the NCN). The RTN Administrator should plan to monitor the positions of all RTN stations to ensure that their coordinates do not deviate more than expected from these newly published values. Administrators should provide quality assurance to users that the positions do not vary by more than an expected amount for any given day of RTN operation. How much variance or movement in position is acceptable? What are the seasonal effects on station positions? Each RTN should determine acceptable normal limits and beyond those limits consider re-positioning the station. For consistency, consider adopting procedures for updating the station’s coordinates and/or velocity if coordinate differences in excess of 2 cm in either horizontal dimension and/or 4 cm in ellipsoid height persist over a period of several days.

After completing a new RTN adjustment or updating individual station coordinates the RTN Administrator should consider publishing each station’s position on the RTN website. Include metadata about the adopted coordinates and relative positioning network accuracies for the RTN stations based on the assumption that CORS are errorless. Network accuracies should be published for each station so that users may include those errors when performing local project static network adjustments using the RTN stations. Thus local project network error will include the RTN network error. The network error should be normally reported at the 95% (2) confidence level.

F.9. Literature Cited

Henning, W., D. Martin, G. Schrock, G. Thompson, R. Snay. 2013. National Geodetic Survey Guidelines for Real Time Networks. Accessed online on November 16, 2020: https://geodesy.noaa.gov/PUBS_LIB/NGSGuidelinesForRealTimeGNSSNetworksV2.2.pdf. 64pp.