This demonstration again processes the same GPS data using both the “base files” and “base provider” reference position options to evaluate workflows for post-processing GPS data.
- Post-process the same .ssf file in duplicate N1 and N2 project folders
- Export .cor files with NAD83(Conus) null transformation
- Assign resulting .shp files ITRF00 projection files (.prj)
Choose Reference Position Source
1st Option: Base Files
NGS-provided coordinates are embedded in the RINEX header of downloaded base station files. Although not at all evident in PFO software or documentation, these coordinates are NAD83. To be specific, these are were updated in June 2012 from NAD83(CORS96) to NAD83(2011) epoch 2010.00. NGS will update these again as needed for changes of more than 2 cm horizontal and 4 cm vertical. They are displayed on the confirmation screen and in the Correction.txt file both of which are described below.
2nd Option: Base Provider
As indicated by the base station names in the Trimble CBS, these coordinates are ITRF00 – or more specifically, ITRF00 derived from IGS08 as described in demo # 1. According to Julian Idle, Trimble CBS administrator, the CBS List is populated by entering IGS08 epoch 2005 coordinates into HTDP and transforming to ITRF2000 Epoch 1997.0. The resulting CBS location can be viewed on the Base Station/Properties tab as shown on page 6.
Distance from base
Prior to initiating the differential correction, the confirmation screen provides a number of settings including “distance from base provider”. This same valuable metadata is preserved in the project folder as a Correction.txt file. Genuine thanks to Trimble for providing such essential documentation.
N2 has a “distance from base” of 1.23 m. It was calculated from a 40 24 59.47919 N and 119 21 19.59158 W. This location is that of the reference position in the RINEX header of the downloaded base files i.e. N1. It is also noted that while the coordinates in the RINEX header are NAD83 (2011) may differ from those published on the NGS datasheet. In fact, for GARL - and many other bases stations, these coordinates match those listed on the NGS “Old” ITRF00 coordinates for ARP. It is unclear if this is mere coincidence (seems unlikely!) or if not, why these should be an exact match.
J. Idle, Trimble has noted that the coordinates you get in the log file when downloading from UFCORS as well as those you may find on the website may also differ. We can only make note of these observations but cannot offer any explanation.
Resulting .cor file
TerraSync receives and stores all collected GPS data in WGS84, the same reference frame on which the GPS signal is broadcast. When this .ssf file is differentially corrected, the resulting corrected GPS data in the .cor file takes in the reference frame of the base station. The reason for this becomes apparent in the literal interpretation of “differential correction.”
A base station continually reports its position as calculated by the satellites. Since the base station remains stationary, the difference between the GPS-reported position and true surveyed location is calculated and stored in base station files. To correct your GPS data (.ssf file), post-processing subtracts this known amount of error in the base station file. This adjusts for this known amount of difference in your collected GPS data - hence, the term “differential correction”. As a direct result, your corrected GPS data in the newly-created .cor file, takes on the reference frame of the base station.
Export: Choose Reference System and Transformation
Lat/Long ITRF00 and NAD83(Conus)
All 3 parameters for NAD83(Conus) are set at 0; it is a null transformation
5. Assign .prj file and Resulting .shp file
The .prj file informs ArcGIS of the projection of our data.
NAD83(Conus) null transformation will not get us to the desired the NAD83 but it does keep things simple as we systematically go through our analysis.
B. View results in ArcMap
1. Start a new ArcMap document to ensure the data frame contains no
2. From View / Data Frame / Properties verify map projection is Unknown
3. Add N1 and N2 via the Add Data button or drag them in from ArcCatalog
4. From View / Data Frame / Properties verify map projection is now ITRF00
5. For both N1 and N2, right-click Properties / Source tab, verify each is in ITRF00
· N1 is 1.23 m southeast of N2
· 1.23 m corresponds to the “distance from base” observed for N2
· 1.23 m also corresponds to the NAD83 and ITRF00 difference in this area
N1 and N2 originated from the same GPS- collected point. Both were post-processed in the exact same manner except the reference position source. N1 was from the 1st Option- coordinates in the RINEX header. N2 was from the 2nd Option- Trimble CBS coordinates.
Based on the observed 1.23 m distance between the 2 resulting locations, it is logical to conclude that -
1) the N1 location indicates the RINEX header coordinates are NAD83. While this fact is not apparent in PFO software or documentation, Giovanni Selli, NGS confirms that these are NAD83(2011).
2) the N2 location confirms that coordinates in Trimble CBS coordinates are ITRF00. As discussed in demo # 1, the N2 location is “HTDP-ITRF00,” not truly ITRF00. A shift was introduced when the original IGS08 coordinates were HTDP-transformed to ITRF00.
The resulting N1 location would be acceptable IF we were able to match CBS ITRF00 base station coordinates with those on the NGS datasheet. As was saw in demo # 1, we could not. It impossible to recommend the N1 workflow for post-processing your GPS data.
The resulting N2 location derived from the “HTDP-ITRF00” coordinates are shifted an unknown amount from its true ITRF00 location. It also fails to meet our original goal of a NAD83 export. It impossible to recommend the N2 workflow for post-processing your GPS data.
The next demonstration mutes this issue of comparison by manually entering base station coordinates directly from NGS datasheets.