GPS Receiver Datum Shift Tests - Spatial-Ed

GPS Receiver Datum Shift Tests
Kaloko Honokohau National Historic Park
March 23 – 27, 2009
Tests conducted the week of a 3.5 Day Trimble Training Course
Author: Joel Cusick 4-14-09 (National Park Service)
Purpose: Joel Cusick conducted GPS receiver datum shift tests on survey control on Hawaii (Big
Island) near the Kaloko Honokohau National Historic Park visitor center, Kailua-Kona Hawaii. As
earlier tests in February 2009 indicated, Trimble Pathfinder Office software datum shifters were
not providing typical horizontal accuracies for a user that holds ITRF00 (EPOCH 1997)
coordinates from COR base stations to export to NAD83 reference frames using parameters to
go from ITRF00 (EPOCH 1997) to NAD83 (PACP00) EPOCH 2003. Using new PACP00 (NEW)
parameters (as identified by Michael Dennis and supported by Richard Snay (see email thread in
Appendix 3)), Joel Cusick occupied OPUS control and compared various GPS receivers using
the latest shifters within a traditional Trimble Pathfinder Office workflow. This includes postprocessing against CORS stations using “Use reference position from base provider”, exporting
to ESRI shapefile format using UTM Zone 5 NAD83 (PACPOO) NEW parameters. Datum shift
comparison was the primary goal of this test as well as an opportunity to observe WAAS and
various receivers on control.
The 7 parameter datum shift parameters that have been identified in Appendix 3 and currently not
in Trimble or ESRI workflows are:
The coordinates to enter are here (for copy paste)
>
>
>
>
>
>
>
Tx = 0.91023 m
Ty = -2.10411 m
Tz = -0.56015 m
Rx = 0.027741 sec
Ry = 0.013468 sec
Rz = 0.002712 sec
S = 0.0
ppm
Methods:
Control
Survey control was collected by Tim Smith (NPS GPS Coordinator) on Feb. 12, 2009. See
Appendix A for OPUS sheet.
Figure 1a and 1b – OPUS control setup.
GPS Tests – Hawaii March 26, 28, 2009
Page 1 of 32
On-Ground GPS Tests
Joel Cusick occupied the OPUS control spot on 2 separate days. Majority of all tests were
conducted on the morning of March 26, 2009, while a smaller test with just a JunoSB, Garmin
Map76CSx and an SXBlue setup was run on March 28, 2009. GPS field software common to all
systems was TerraSync 3.3 software running either on handheld/GPS units or a datalogger.
Standard configuration settings included PDOP mask 6, SNR 39, Mask Angle 15deg and Velocity
filtering off were set on all systems. The intent was also to test H-star equipment with Zephyr
antenna’s but the author did not set Carrier collection to YES or Auto, so these tests will only use
L1 Code phase testing parameters. SBAS (WAAS) was enabled on all systems (Exception was
with ProXR system) and both PRN’s were enabled as healthy. This allows each system to be
tested as a WAAS realtime system as well as Postprocessed against CORS
Systems tested included:
Pathfinder Pro XR NDGPS Beacon System with a Ranger Mobile 5 Datalogger
Pathfinder ProXH with Zephyr Antenna and Recon Mobile 5 datalogger
GeoXT 2003 Handheld with Hurricane antenna
Juno SB with Internal GPS antenna
Garmin Map76CSx with internal GPS Antenna
Individual rover files were opened and named according to the System used. Each GPS was
warmed up for 20 minutes in open sky. GPS antennas were mounted on top of a tripod leveled
over the control point using a Tribrech and bubble level. Antenna height was measured 3 times
from cap top to base of antenna used and entered into TerraSync before first position was
logged. A data dictionary was used to standardize all position collection into a point feature. This
ensures this test follows a standard GPS for GIS data collection procedure where GIS personnel
collect GPS data into Point features. The point feature was set to log at 1 second logging interval
and auto-pause was set to 5 seconds. This ensured only 5 positions (at 1 second) were logged
for each point feature. Then, each point feature was repeated for at least 30 times. Therefore
each rover file contained at least 150 positions stored within at least 30 point features.
The Pathfinder ProXR system was set to Manual KHZ beacon rate for Paulo Point USCG station
and the datum for CORS96 was used in TerraSync. NOTE: This is an error in TerraSync that
does not include the PACP00 reference frame for Hawaii and Pacific. This did not effect this test
however since 100% of the SSF file collected with the ProXR was realtime corrected.
Systems were swapped out on the same tripod system and rover files closed upon completion of
tests.
In addition, a Junes was setup on top of tripod and collected positions across two separate days
as well as a Garmin Map76CSx set to collect tracklog points at 1second intervals with WAAS
enabled.
The following files were now ready for postprocessing:
JUNO032607B.SSF
JUNO032814B.SSF
XHZWAAS032606A.SSF
XHZWAAS032606B.SSF
XRB032606A.SSF
XRB032606B.SSF
XRB032606C.SSF
XTHWAAS032608A.SSF
GPS Data Post-Processing
All rover files were downloaded to Pathfinder Office via data transfer and differentially corrected
against 3 nearby CORS stations. All stations coordinates were verified with the CORS coordinate
page L1 phase center ITRF00 (EPOCH 1997) coordinates. Though Upulo Point 6, Mauna Kea
GPS Tests – Hawaii March 26, 28, 2009
Page 2 of 32
(MKEA) and Mauna Loa (MLO1) were compared only MLO1 was tested at 95% accuracy levels.
The integrity index was high (93%) ofr MLO1 and with a baseline of 60KM from test location. In
all postprocessing, standard cod/carrier collection mode was enabled, and the Use reference
position from base provider option was used. This ensured that all COR files were based in the
ITRF00 (EPOCH 1997) reference frame at conclusion of differential correction.
The Juno SB files were not Postprocessed, nor were the Garmin TrackLog files. Garmin
TrackLogs were downloaded via DNRGarmin with a Set Projection of WGS84 (to ensure no shift
from WGS84/ITRFOO) reference frame.
Here are the list of GPS COR and Raw Files sent to Export for testing
JUNO032607B.SSF
JUNO032814B.SSF
XHZMLO1032606A.cor
XHZMLO1032606B.cor
XRBMLO1032606A.cor
XRBMLO1032606B.cor
XRBMLO1032606C.cor
XTHMLO1032608A.cor
As reported from Trimble 100% of all features by time were available for postprocessing. Here
are the precision results for files tested.
XH
30-50cm
0.5-1m
66.3%
33.7%
15-30cm
30-50cm
17.7%
81.6%
30-50cm
0.5-1m
64.8%
35.2%
XR
XT
GPS Data Export
All raw (WAAS) SSF files and Post-processed differential COR files were exported to ESRI
Shapefile format. The coordinate system used in all cases was UTM Zone 5. NOTE: Though
this park is really in UTM Zone 4, it is the Hawaii National Park Regional Office decision to
maintain one constant UTM Zone for all parks on Hawaii.
Precision and Units were all set to Meters, 95% precision. All autogenerated attributes were
selected and only Corrected positions were set for export.
The Datum used for export for all tests was the new datum parameters (see Appendix 3 – Email
thread). This datum is known temporarily in PFO as NAD83 (PACPOO) NEW).
NOTE: Pathfinder ProXR SSF files that are already in NAD83 PACP00 (EPOCH 2003.0) were
exported exactly the same as other files, but the datum was switched to NAD83 (CONUS) which
is a 3 parameter datum shifter with values 0,0,0. In other words, the data was not transformed
from native NAD83 datum, but tagged as UTM Zone 5, NAD83.
GIS Processing
OPUS control was converted from UTM Zone 4 to UTM Zone 5 using CORPSCON 6 for windows
with no datum shift. A test was conducted within CORPSCON to convert the LAT/LONG NAD83
coordinate to UTM Zone 4 and no difference was seen. Once the coordinates were transformed
GPS Tests – Hawaii March 26, 28, 2009
Page 3 of 32
to UTM Zone 5, the table was added to ArcMap and a feature class created from the coordinates
in Easting/Northing. Then, the point was loaded into a Geodatabase featureclass.
Within the same file Geodatabase feature dataset (set to UTM Zone NAD83 with a precision of
0.001 meters) a feature class called GPSReceivertest Data was created from one of the
shapefiles, and all subsequent datasets were loaded into this feature class for a total of 483
records. All data including different CORS postprocessing files and their associated features
were also loaded into this feature class.
The ArcToolBox Near command was then used to calculate in meters the distance to the OPUS
control. The field Near_Dist was populated with this distance. Attributes System_Diff and
CORSStation were appended to feature class to indicate the GPS system and the type of
differential used in processing as well as the CORS station. Not applicable was the value given
to WAAS data that did not have postprocessing steps applied.
Then a query was used to pull out only those files corrected with MLO1 and a summary table was
built on the Diff. System attribute. The values of Average, min and max Near_Dist was
summarized as well as the average Northing and Easting (as supplied by Trimble’s PFO Export
position attribute). Summarized tables were then loaded into ArcMap via Add XY to create an
event. These event themes were then exported as individual feature classes in the Geodatabase
to allow for an averaged point for all the point features corrected with MLO1 CORS station.
Datum Shift Comparison in ArcGIS
One of the main drivers of this test was to the new datum shift parameters in Pathfinder Office
against the NAD83 (PACP00) parameters that were identified by Snay as the HARN NAD83
(1993) parameters (See email Thread in Appendix 3). The HARN NAD83 (1993) parameters are
found in PFO, ESRI and ArcPad workflows.
Using the survey control point as “truth” based in NAD83 (PACP00) (EPOCH 2003.0) the
averaged points for the three GPS systems (XR, XH with Zephyr and XT with Hurricane) were
tested relative to the older datum. This was done by inserting a datum configuration
(NAD_1983_WGS_1984_PACP00-NEW.gtf) in ArcMap and shifting the averaged points for the
three GPS systems back to WGS84, then shifting these same data to “NAD83” using ESRI’s
default NAD_1983_WGS_1984_PACP00 shifter.
Horizontal Accuracy Tests
Joel Cusick used an excel spreadsheet provided by Michael Dennis that calculates the National
Standard for Spatial Data Accuracy (NSSDA, 1998) statistic for mapped coordinates with respect
to surveyed coordinates. The know position of the OPUS solution was the test point or control,
while the average 5 second point feature coordinates in UTM Zone 5 NAD83 meters for each
GPS system was the Test statistic. Vertical tests were not conducted. This was horizontal only.
Number of Sample tested are as follows:
ProXHPostprocessed Code CORS StationMLO1
GeoXTPostprocessed Code CORS StationMLO1
ProXRPostprocessed Code CORS StationMLO1
ProXRReal-time Code CORS StationPAHOA-Realtime
Juno SB/SCReal-time SBAS Corrected CORS StationNot Applicable
ProXHReal-time SBAS Corrected CORS StationNot Applicable
GeoXTReal-time SBAS Corrected CORS StationNot Applicable
GPS Tests – Hawaii March 26, 28, 2009
35
31
33
33
60
31
31
Page 4 of 32
Results and Discussion
Datum Shift Comparison in ArcGIS
A 72 cm relative shift was observed between the exact same dataset when shifted from the New
PACP00 parameters and the NAD83 (HARN) Parameters found in ESRI and Trimble products.
See Figure 2.
Figure 2 – Map depicting relative shift between the two NAD83 (PACP00) parameters tested.
This difference of approximately 70 centimeters was confirmed in earlier tests (See Appendix 3 –
Email Thread). If a user intends to use submeter or even sub-foot GPS systems and desire to
use the NAD83 (PACP00) EPOCH 2003.0 reference frame in the Pacific region, it would appear
to this author that the datum shifters in Trimble and ESRI product lines be modified to the 7
parameters identified in the Email thread.
Horizontal Accuracy Tests
Figures 3a and 3b depict the horizontal accuracies (meters in 95% NSSDA) of the GPS systems
tested and differentially corrected against the MLO1 CORS station (post-Processed), or in
realtime NDGPS (Pahoa Pt) or with WAAS.
GPS Tests – Hawaii March 26, 28, 2009
Page 5 of 32
Horizontal accuracies for the equipment used fall within company specifications. Trimble reports
horizontal RMS (HRMS) accuracies at the 68% statistic, while this report offers the more
conservative 95% NSSDA accuracy statistic.
WAAS results exceeded 3 meters at 95% for the Juno, but this combines two days of data
collection that revealed significant differences (see Figure 5).
Figure 3a.
PostProcessing Results with MLO1 CORS and ProXR Realtime with PAHOA
GPS Receiver Tests on OPUS Control - 95% Horizontal
NSSDA Accuracy
1.2
1
0.8
0.6
Horiz- Meters
0.4
0.2
0
ProXHPostprocessed Code
CORS StationMLO1
GeoXTPostprocessed Code
CORS StationMLO1
ProXRPostprocessed Code
CORS StationMLO1
ProXRReal-time Code CORS
StationPAHOA-Realtime
Figure 3b.
Realtime SBAS-WAAS
GPS Receiver Tests on OPUS Control - 95% Horizontal
NSSDA Accuracy
4
3
Horiz- m
2
1
0
Juno SB/SCReal-time SBAS Corrected ProXHReal-time SBAS Corrected CORS GeoXTReal-time SBAS Corrected CORS
CORS StationNot Applicable
StationNot Applicable
StationNot Applicable
GPS Tests – Hawaii March 26, 28, 2009
Page 6 of 32
Figure 4 depicts all 3 GPS systems that were Postprocessed against 3 of the nearest and highest
integrity CORS stations as identified in Trimble Pathfinder Office. In addition, the Pathfinder
ProXR beacon system is also shown for comparison. The ProXR receives realtime NAD83
(PACP00) (EPOCH 2003.0) signals and can incorporate them into the SSF file, eliminating postprocessing steps. As you can see, the ProXR provides outstanding results relative to the other
more modern systems – great news considering some of these hardy systems are over 10 years
old, but can be modernized when bound to modern Windows CE based dataloggers like was
done in this test
Figure 4.
GPS Tests – Hawaii March 26, 28, 2009
Page 7 of 32
An interesting result was observed with the JunoSB receiver. This author conducted two tests on
the same setup on two different dates. The Figure 5. shows that between the two dates, over the
same control a significant shift between the dates can be observed. It was observed that on the
second date (March 28, 2009), the Juno would lose WAAS lock during or between each 5 second
point feature collection. This up/down with WAAS could explain the higher errors.
Documentation provided by Trimble does recommend that constant lock be maintained prior to
data collection to allow receiver to settle.
Figure 5. WAAS comparisons and the high inter day collection errors seen with a Juno SB.
GPS Tests – Hawaii March 26, 28, 2009
Page 8 of 32
Figure 6 depicts the Garmin Map76CSx WAAS enabled receiver relative to Survey Control. Like
the Juno, the Garmin was tested on two different dates. The Garmin performed poorly on the
second test date relative to the first date. Since these two different receivers show similar relative
shifts between these two dates the reasons for the shift are yet unexplained. Regardless, the
Garmin with WAAS enabled in the open should perform adequately for large spatial scale
mapping, but reliability may be suspect.
Summary:
Tests conducted in Hawaii by this author does confirm a relative shift of approximately 70
centimeters between the NAD83 (PACPOO) HARN 7-parameter shifter found today in both
Trimble and ESRI software and the modified NAD83 (PACPOO) datum shifter. The archival
projection settled for all Pacific National Park units is based on the UTM coordinate system and
NAD83 projection library. Specifically, for the park tested, NAD83 UTM Zone 5 is the preferred
coordinate system. This test reveals that for tagging data for UTM “NAD83” storage the new
parameters are more precisely for NAD83 data at ITRF2000 at time 1997.00 to NAD83 at time
2003.0 as defined by the CORS network. These 7 parameters are not yet in the Trimble
Coordinate System Definition with latest version (4.1). These 7 parameters are neither found in
ArcGIS or ArcPad workflows.
Horizontal accuracies for the receiver systems tested reveal under these conditions, against
OPUS control in the NAD83 (PACPOO) (EPOCH 2003.0) reference frame a user will meet unit
specifications.
GPS Tests – Hawaii March 26, 28, 2009
Page 9 of 32
WAAS tests reveal higher errors than what has been observed by this author in Alaska and in the
Lower 48 conterminous states. Until further testing is done, it is this author’s opinion, that WAAS
be used on the Trimble system as a navigational aide and not for storage of submeter data
relative to high quality NAD83 (PACPOO) (EPOCH 2003.0) reference frames.
National Differential GPS systems (NDGPS) that broadcast NAD83 (PACPOO) (EPOCH 2003.0)
reference frame data appear to have outstanding horizontal accuracies relative to survey control.
The double Beacon coverage seen for the Hawaiian Islands (See
http://www.navcen.uscg.gov/dgps/coverage/Hawaii.htm proximity to coasts and high reliance on
marine mapping makes the use of this system in Hawaii especially useful.
GPS Tests – Hawaii March 26, 28, 2009
Page 10 of 32
Appendix 2– OPUS Sheet
FILE: 87950501.09o 000522768
NGS OPUS SOLUTION REPORT
========================
All computed coordinate accuracies are listed as peak-to-peak values.
For additional information: www.ngs.noaa.gov/OPUS/Using_OPUS.html#accuracy
USER: tim_smith@beforethewind.net
RINEX FILE: 8795050t.09o
DATE: February 21, 2009
TIME: 17:18:39 UTC
SOFTWARE: page5 0810.20 master50.pl 081023
START: 2009/02/19 19:26:00
EPHEMERIS: igr15194.eph [rapid]
STOP: 2009/02/20 01:50:00
NAV FILE: brdc0500.09n
OBS USED: 15561 / 16870 : 92%
ANT NAME: TRM_R8_GNSS NONE
# FIXED AMB: 74 / 85 : 87%
ARP HEIGHT: 2.0
OVERALL RMS: 0.014(m)
REF FRAME: NAD_83(PACP00)(EPOCH:2002.0000)
X:
Y:
Z:
-5489438.795(m) 0.042(m)
-2441588.060(m) 0.015(m)
2134255.008(m) 0.038(m)
ITRF00 (EPOCH:2009.1368)
-5489439.721(m) 0.042(m)
-2441585.651(m) 0.015(m)
2134255.979(m) 0.038(m)
LAT: 19 40 43.49747
0.039(m)
19 40 43.52865
0.039(m)
E LON: 203 58 42.60777
0.021(m)
203 58 42.51928
0.021(m)
W LON: 156 1 17.39223
0.021(m)
156 1 17.48072
0.021(m)
EL HGT:
31.509(m) 0.037(m)
31.711(m) 0.037(m)
ORTHO HGT:
13.207(m) D.N.E. [No official datum supported (FAQs 19,20).]
UTM COORDINATES STATE PLANE COORDINATES
UTM (Zone 04)
SPC (5101 HI 1)
Northing (Y) [meters] 2178667.611
93664.141
Easting (X) [meters]
812303.586
445318.150
Convergence [degrees] 1.00381502
-0.17561671
Point Scale
1.00080574
1.00000361
Combined Factor
1.00080079
0.99999866
US NATIONAL GRID DESIGNATOR: 4QHG1230478668(NAD 83)
BASE STATIONS USED
PID
DESIGNATION
LATITUDE LONGITUDE DISTANCE(m)
DK2662 UPO5 UPOLU POINT 5 CORS ARP
N201445.166 W1555301.653 64417.1
DG9765 MLO1 MAUNA LOA OBSERVA CORS ARP N193209.281 W1553434.277 49448.4
DE6589 MKEA MAUNA KEA CORS ARP
N194804.847 W1552722.744 60907.3
TU2619
NEAREST NGS PUBLISHED CONTROL POINT
KEAHUOLU PT NE RNG MARKER
N193958.329 W1560144.162
1599.5
This position and the above vector components were computed without any
knowledge by the National Geodetic Survey regarding the equipment or
field operating procedures used.
GPS Tests – Hawaii March 26, 28, 2009
Page 11 of 32
Appendix 3
Email Thread Resulting in New NAD83 PACP00 parameters being
suggested for Pathfinder Office.
Relates to Users in Hawaii, Guam, Samoa, Marshall Islands (Pacific Plate)
December 15 – December 29, 2008
Players:
Michael L. Dennis, P.E., Geodetic Analysis, LLC
Sandy Margriter, National Park Service, Geographer
Lisa Marrack – Ground GPS Tester – Hawaii
Richard Snay - NOAA's National Geodetic Survey
Dave Doyle - NOAA's National Geodetic Survey
Joel Cusick, Alaska Regional Office, National Park Service
Tim Smith – GPS Coordinator, National Park Service
Summary:
This email thread is probably the best way to showcase a recent discovery of a datum
transformation error within Trimble’s Pathfinder Office version 4.1. The datum transformation
parameters highlighted below to go from ITRF2000 to NAD 83 (PACP00) are correct for those
referencing to ITRF00 EPOCH 1997.00 (= January 1, 1997) during the differential correction
process. The epoch of 1997.0 is used by Trimble when selecting “Use reference position from
base provider” option. By providing these new datum shift parameters a user can meet accuracy
specifications when exporting GIS data with NAD83 (PACP00) parameters for when comparing
with data referenced into the NAD_1983 PACP00 reference frame designed by NGS for Hawaii
and Pacific Plate regions. Comments by Dr. Snay about how this addresses the symptom, but
not the illness of ignoring velocities.
***************************
From Joel Cusick
To Michael Dennis
Hi Michael,
See KAHOGeoXHZephyrTestHoldITRF00.pdf
I just got a great dataset from Hawaii. Gal occupied a survey
control using GeoXH, Zephyr, and collected 30 features all with 30-1 second
positions. The draft PDF is attached. Pretty pleased with results, but
want to confirm, once more about putting all apples with apples.
Am I apples to apples then when I compare the independents coming from a
CORS ITRF00 1997 and exporting said data to NAD83 using 7 parameter PACP00?. Of
course, I'm constrained in PFO not to handle velocities, but want to ensure
my OPUS shot in 2006, is in the "right place".
The OPUS generated point I’m comparing against is in NAD_1983 PACP00 EPOCH 2002.0
***************************
From Michael Dennis
To Joel Cusick
GPS Tests – Hawaii March 26, 28, 2009
Page 12 of 32
…Sic the results indicate bias -- the precisions are better
than the accuracies. I would expect better consistency between the
post-processed positions and the OPUS point, but perhaps there is
differential movement (i.e., all CORS are not moving as a single block). I
am assuming that the Trimble PACP00 transformation parameters are correct -has this been checked against NGS values?
One possible problem is the very short occupation time, especially for the
distance to the CORS. That's part of the reason the solutions are "float"
rather than "fixed" (but also because the receiver is single frequency?).
At any rate, the tight clustering of the GPS positions is typical for short
occupations; GPS errors are highly time-correlated, so short occupations
will usually give precisions that are better than the accuracy, sometimes a
lot better (can fool yourself).
The WAAS positions are way out. Assuming PFO correctly applied the PACP00
transformation (at 1997.0), then the only difference would be due to ITRF 00
velocity since 1997. I did some quick calcs with coordinates from HTDP for
ITRF 00 from 7/2/2006 (OPUS) to 1/1/1997. The position change is 0.68 m
(0.32 m south, 0.60 m east). That's similar direction but looks to be about
half as far as shown on the map. Not sure what's going on there -transformation double applied or wrong direction? In any case, it looks
like ITRF velocity is a big deal in Hawaii -- WAAS users beware! (at least
if you use Trimble to do all your datum transformations).
For OPUS, I recommend waiting at least long enough to get the IGS rapid
orbits (rather than ultra-rapid). The latency is about 12 hrs, as I recall,
but it may take a bit longer for those to be available in OPUS. I also
recommend at least 3 hours of data for OPUS. The peak-to-peak errors look
pretty reasonable, though.
Only one of the CORS used in the test was also used by OPUS (MLO1). Might
be good to use same CORS for both.
***************************
From Joel
To Michael Dennis
Michael,
thanks for your time on this issue.
Seat of pants reply to your questions.
Trimble's PACP00 parameters are exact - given the same 7 parameters. That’s a go.
Occupation time. Her data file was opened 15 minutes. She locked with carrier 10 seconds after
opening file, and closed file, losing lock at 15 minutes. So a block of data required by Trimble to
post process should be good.
The short test was intentional - to replicate what a GIS person does. But, wish to know that the
GPS was warmed for 20 minutes prior (this helps WAAS too). Don’t know that.
Sky is excellent there, and we intentionally locked onto GeoSat PRN 135 for WAAS. I'm shocked
about the WAAS, and maybe this WAAS using current epoch is going to be a concern, but 60cm
is a lot (by your calc). yikes.
GPS Tests – Hawaii March 26, 28, 2009
Page 13 of 32
As for using CORS, were GIS guys, and rarely have the opp. to choose bases. I did a mix of
CORS (they have 6 all within 200miles), so want to not "bias", this test in matching what OPUS
used. Besides, two of the CORS used on OPUS were simply not reporting today for those data.
Tim Smith thinks maybe the bubble was off, or something else….
Regardless, pleased in general, but not that excited that they are not meeting tech specs for Hstar with Zephyr (a dual freq. antenna) - Trimble says at 68% should be 10cm.
***************************
From Joel
To Lisa Marrack
Okay,
You ready! We are sitting on a well collected GPS dataset. See this latest map
KAHOGeoXHZephyrTestHold83.pdf
What's different here, is I held the NAD83 coordinate from CORS and exported doing "nothing" to
the data. This option is always available when using high quality stations, like CORS. Now, this
is the type of results I was expecting.
Strange, though that SOPAC is over 2.5meters away. In Alaska, a SOPAC site could be treated
(in my tests) as a CORS – hence the shift away from the center is odd.
WAAS data is not shown, since its Off the chart still at 1.+ meter away.
Even KOKB, A CORS site, some 466KM will get you inside 30cm. Those sort of long baselines is
what us Alaskans are use too though. Still, were pleased that a number of CORS is making us
hit the target as expected.
Again, We are all on the way to understanding your issues. Hang in there, but this map is more
along the lines of what your gear is capable of.
But, with a simple click in a software, you can move data meters away!
***************************
From Sandy Margriter
To Joel Cusick
Joel,
When you say you did "nothing" to the data, do you mean you didn't differentially correct the
data? Very curious that doing nothing is more accurate than doing something - I like it!
***************************
From Joel Cusick
To Sandy Margriter
Sandy,
Oh no. These excellent results are due to Differential correction. In fact, in this test its pretty
clear that WAAS (what the file was set too, is "a bust" relative to postprocessing. The PDF I sent
is zoomed in too far to even see the WAAS data sitting 1+ meter away.
GPS Tests – Hawaii March 26, 28, 2009
Page 14 of 32
With this test same SSF file, corrected against all those different CORS (you guys are truly
blessed in a GPS sort of way), but we held "used" the NAD83 coordinates for the stations (this is
not what we teach in Alaska, but appears to be the "Hawaiian" way). We then Exported, the last
step in the process of postprocessing, and used the datum choice in PFO called NAD83
(CONUS). This "does nothing" to the data that is already in NAD83 (PACP00). That’s what I
meant by doing nothing. Doing nothing in export to shape.
***************************
To Dave Doyle and Michael Dennis
From Joel Cusick
Can you guys confirm the parameters found in Pathfinder Office's Coordinate System Manager?
Tx = 0.9102 m
Ty = -2.0141 m
Tz = -0.5602 m
Rx = 0.029039 arcsec
Ry = 0.010065 arcsec
Rz = 0.010101 arcsec
S = 0.0
***************************
From Joel Cusick
To Michael Dennis and Dave Doyle
Okay,
You ready! We are sitting on a well collected GPS dataset. The equipment is top-line (GeoXH,
H-Star, Dual freq antenna, held over control. control was an OPUS point generated in 2006, and
the NAD83 PACP00, EPOCH 2003 coordinates used as "Truth". Then I take the GPS data and
switch processing paths. Since were using CORS, we know that within Trimble software we can
hold either reference frame (ITRF00 or NAD83PACPoo). Then by carefully exporting doing
something, or nothing, we can directly compare CORS ref. frames and the relationship with the
Exporting.
In both cases, staying within the green 30cm circle was the goal. WE
clearly meet that by holding NAD83 reference frame from CORS and doing
nothing.
These results are a bit off from my exp. in AK, but either Hawaii really does move, or the GPS
engine in PFO is doing something I’m not used to.
(See attached file: KAHOGeoXHZephyrTestHold83.pdf)(See attached file:
KAHOGeoXHZephyrTestHoldITRF00.pdf)
Same GPS data taken into both, but I "held" the two reference frames for the CORS
(ITRF00(Epoch 1997.0) or NAD_1983_PACP00 Epoch 2003.0). and did the correct export to
place into GIS. The former, I exported inside Trimble Pathfinder office using NAD83 PACP00
- Params 0.9102,-2.0141,-0.5602,0.029039,0.010065,0.010101,0
the latter, I exported inside Trimble Pathfinder office using NAD83(CONUS)- Params 0,0,0
Big, Big difference - one that I did not expect. My hypothesis was these would be essentially the
same. I'm confident the Trimble
NAD83(PACP00) is using the right 7 parameters.
***************************
From Michael Dennis, Dave Doyle
To Joel Cusick
GPS Tests – Hawaii March 26, 28, 2009
Page 15 of 32
I'm not so sure the Trimble NAD83(PACP00) transformation parameters are
correct.
If you dig into the HTDP v3.0 Fortran source code, you can figure out what
Richard Snay uses for the ITRF00 to PACP00 transformation. It's not
completely straightforward, because it is computed in two steps, first from
ITRF00 to ITRF94, then from ITRF94 to PACP00. When I combine those
transformations, here is what I get for ITRF00 --PACP00 at 1997.0 (compare
to Trimble values):
HTDP
Tx = 0.91023 m
Ty = -2.10411 m
Tz = -0.56015 m
Rx = 0.027741 arcsec
Ry = 0.013468 arcsec
Rz = 0.002712 arcsec
S = 0.0
Trimble
0.9102 m
-2.0141 m
-0.5602 m
0.029039 arcsec
0.010065 arcsec
0.010101 arcsec
0.0
The transformations have the same translations and scale, but different
rotations. If you compute these transformations at your Hawaii test
location, the results differ by 24 cm (Trimble is 11 cm north and 21 cm west
of HTDP), which seems to be what your map shows (based on the bar scale). I
cross-checked my transformation calcs against HTDP online to confirm my
results.
Of course I could be mistaken. But at this point is appears the Trimble
PACP00 rotations are wrong.
Assuming I am correct, this harkens back to my persistent warnings about
excessive reliance on datum transformations. As I've said many times, it's
safer to work in the reference frame that you want your results in and not
do any transformation. This can't always be done, but many (most) times it
can.
Cheers,
Michael
***************************
From Joel Cusick
To Michael Dennis
If "Trimble's" PACP00 transformation parameters are wrong, then there are two other software’s
(ESRI's ArcGIS and ArcPad) that have inherited these parameters. ArcPad's
WGS_1984_To_NAD83_Harn uses "Trimble's" parameters. Refer to the email I… ESRI's Craig
Clouet <cclouet@esri.com who admits that NPS users should use ESRI's HARN parameters
(which are exactly the same as "Trimble's". So, now this is deeper than Trimble, but ArcPad and
ESRI's ArcGIS projection library.
Within the confines of Trimble's Pathfinder Office (which I know better than any other software),
the recent shifts are explained away by using HDTP values (Michael's numbers below with
different translations). Richard Snay's parameters from his article on the web - page 10, Table 4
are not correct then????
GPS Tests – Hawaii March 26, 28, 2009
Page 16 of 32
This has to be resolved, but its bigger than me now. I want my users in Hawaii, to essentially
have the freedom to use both reference frames from CORS. Michaels persistant warnings are,
as always, taken to heart, but were making this useable at the "zoologists" level. Here is why I
continue to stand that its important, to the best of Trimble’s software to go from ITRF00 to NAD83
using PACP00 at Export.
1) PFO defaults (without doing anything), to use the coordinates from the base provider - those
are the L1 phase center of any CORS in ITRF00, 1997.0
2) The differential wizard shows that you are indeed in ITRF00, 1997.0. A user can very easily
confirm this at CORS.html
3) Not all base stations store NAD83 - were safe with CORS and something strange about
SOPAC, but when using CORS, were good with base files.
Help.
***************************
From Michael Dennis
To Joel Cusick
Hi Joel,
I feel your pain.
I don't think there's anything wrong with Richard Snay's paper that you
referenced. But the parameters in Table 4 need to be considered in context.
These relate ITRF 00 to NAD 83(HARN) at epoch 1993.62. As stated in the
paper's conclusions, a point in Hawaii has the same HARN and PACP00
coordinates at -- and only at -- epoch 1993.62. The relative velocity
between these two frames in Hawaii is about 8 cm/yr. So by 1997.00 two
points with identical coordinates at 1993.62 will differ by about 27 cm -which is close to the 24 cm difference I came up with in my previous email.
In fact, if you multiply the rotational velocities in Equation 8 (p. 11) by
the delta time from 1993.62 to 1997.00 and add them to the rotations in
Table 4, you will get exactly the rotations I provided in my previous email.
It's worrisome to with use of this (apparently) erroneous datum transformation. The situation is
extraordinarily confusing and seems to have degenerated into a datum transformation free-for-all.
As Dave Doyle pointed out in his email today, the Trimble NAD 83(CORS96)
transformation parameters are correct, which can be verified on the NGS web
page link that Dave provided, and in the HTDP source code (minus of course
the 7 velocity parameters). These same parameters are in ESRI (and Topcon)
software -- but the trick is getting people to choose the right
transformation for their work!
You're right, this is a big issue, and one that is starting to come to light
as users generate and make use of ever more accurate data. I suspect other
even more egregious problems and errors will come to light.
But there may yet be hope. A few weeks ago there was a Geomatics Industry
Association of America (GIAA) Vendor Summit which was sponsored by both NGS
and ACSM (both Dave and I attended, among many others). I don't know if it
will makes you feel better, but one topic concerned standardization of datum
transformations. The problem encountered here highlights how important this
issue is, and it is an "action item" for the GIAA Technical Committee. 'm
GPS Tests – Hawaii March 26, 28, 2009
Page 17 of 32
pleased to say that the vendors present seemed quite receptive to the idea
(Trimble, ESRI, Topcon, Leica, Magellan, among others).
I ran out of time to return your phone call, but hopefully this email will
suffice.
Cheers,
Michael
***************************
From Sandy Margriter
To Joel Cusick
Hi all:
After I sent out the email to Ed Carlson I remembered that I should go back
and reread the article by Richard Snay (attached). On page 2 it states:
The unofficial name NAD 83 (HARN) has been introduced here to represent the
specific realization of NAD83, which was current when the positional
coordinates of these Pacific reference stations were first computed. The
results of those computations are used here to determine the seven
parameters for transforming ITRF00 positional coordinates at an epoch date
of 1993.62 to both NAD 83 (PACP00) and NAD 83 (MARP00) coordinates at this
same epoch date. Thus, at this epoch date, these two reference frames will
have positional coordinates that are consistent with NAD 83 (HARN)
positional coordinates.
So unless I'm misinterpreting something NAD83 (HARN) and NAD83(PACP00) are
the same thing (i.e. a point in either datum will have the same
coordinate). But to be on the safe side, we should wait and see what Ed
Carlson has to say.
***************************
From Joel
To Sandy
Sandy, Craig, Ed,
Guys… Meet Michael Dennis - I've had him to Alaska twice and his specialties are
all things GPS and datums in particular. You need solid answers.
Michael?
***************************
From Michael
To Joel
Hi Joel,
I'm certainly glad Ed Carlson has been included in this email thread. That
probably should have happened much earlier, since he's the Hawaii Geodetic
Advisor.
GPS Tests – Hawaii March 26, 28, 2009
Page 18 of 32
The point of confusion with the NAD 83 HARN/PACP00 transformation is the
velocity dependence. Yes, by definition, NAD 83 "HARN" and NAD 83(PACP00)
are identical -- but ONLY at time 1993.62 (August 14, 1993). The reality is
that in Hawaii the Pacific Plate is moving relative to the North American
Plate, at a velocity of about 8 cm/yr to the NW. This is stated clearly and
repeatedly in Richard Snay's paper -- including in the second and third
sentences in the quote cited below by Sandy. And it is reaffirmed in plain
language in the first paragraph of the paper's conclusions. It is also
explicitly stated mathematically by adding the rotational velocities in
Equation 8 (p. 11) to the 7 parameters in Table 4 (the translational and
scale velocities happen to be zero). Using the time difference from 1993.62
to 1997.00 will yield the 7 parameters at epoch 1997.0 for CORS. These same
7 parameters can also be calculated from Richard's HTDP v3.0 Fortran source
code, as I indicated in a previous email. And, of course, as a check you
can run HTDP and get it to do the transformation for you.
In other words, there are 14 parameters, not 7. The mistake comes in
believing that the 7 parameters alone completely define the transformation.
They do not.
The bottom line is this: If we agree that Richard Snay has correctly
parameterized the time-dependent NAD 83 relationship between the Pacific and
North American tectonic plates, then there is no question as to what
parameters should be used at a specific epoch. If you don't think Richard
is right, well, that's a different story and you'll have to take it up with
him.
I know, I know -- it's confusing. The problem gets even worse when you
bring WAAS into the mix, which is referenced to current ITRF 2000. What do
you do then, when your software can't handle velocities?
I don't mean to come off as irritable, but I feel like we've beaten this one
to death. The real trick -- as Joel well knows -- will be to get the
various vendors to adopt the "correct" transformation parameters. People
(including the vendors) know this is a problem. What we need now is an
agreed-upon standard for the parameters and naming conventions. As I also
said previously, this is an explicit objective of the GIAA Technical
Committee (all the vendors are members of GIAA, or at least most of them
are). Such standardization won't happen overnight, but I do believe it will
happen.
In the meantime, we all need to be very careful about how we manipulate our
data. The devil's in the details (such as tectonic velocities). As Joel
knows, I have been harping on the velocity thing for years.
I hope this helps, and settles the issue as to what parameters Richard Snay
actually specified in his now notorious paper.
Best of luck to all,
Michael
***************************
From Joel Cusick
To Lisa Marrack, Sandy Margriter
GPS Tests – Hawaii March 26, 28, 2009
Page 19 of 32
Oh Shift!!!
Latest:
Discussions: Were deep in the datum weeds with discussions (by email) with Trimble
heavyweights regarding the PACP00 parameters built into Pathfinder Office.
Take a look at this new PDF, and the result from replacing the existing NAD 1983 (PACP00) with
the modified parameters suggested by Michael Dennis.
See KAHOGeoXHZephyrTestHoldITRF00-butModifiedParams.pdf
Stand by before SOP's are built. I've asked Pacific GPS to run some tests in Honolulu. Anyone
that can lend a hand from the island would support our claim.
***************************
From Tim Smith
To Dr. Richard Snay
Dr. Snay,
>>
FYI. Thought you might like to get in on this thread and maybe make a
comment. Thanks.
>>
Happy Holidays,
Tim
***************************
From Dr. Richard Snay
To Joel Cusick / Tim Smith
Hi Tim et al.
>
NOAA's National Geodetic Survey introduced the NAD 83 (PACP00) reference
frame for locations on the Pacific tectonic plate for two reasons:
1) the previous reference frame (call it NAD 83 (HARN 93)) did not even
try to address crustal motion, and
2) a transformation between NAD 83 (HARN93) and any realization of the
International Terrestrial Reference System (ITRS) remains completely
undefined.
We need such a transformation because GPS measurements are directly
referred either to the latest realization of the ITRS and/or to the latest realization of WGS 84 (the
two of which are essentially the same reference frame).
>
Indeed, we could now redefine NAD 83 (HARN93) so that it equals NAD 83
(PACP00) for all time (not just for t = 1993.62), but to do this we
would need to adopt the transformation between ITRF2000 and NAD 83
(PACP00) as the transformation to be used between ITRF00 and NAD 83
(HARN93) for locations on the Pacific tectonic plate.
>
However, because there are some problems with the GPS measurements
observed in 1993 which were used to establish NAD 83 (HARN93), I
recommend that the new name, NAD 83 (PACP00), be used exclusively for
the current reference frame in Hawaii and other islands residing on the
Pacific tectonic plate.
GPS Tests – Hawaii March 26, 28, 2009
Page 20 of 32
> Richard Snay
***************************
From Joel Cusick
To Dr. Richard Snay
> Dear Dr. Snay,
>
> As always, you guys represent the pins in our maps. I simply would not have a job without
> CORS, and the NGS framework.
>
> While we have you then, could you please.. sic.look at the parameters from Michael Dennis.

Would you concur with the parameters?
***************************
From Dr. Richard Snay
To Joel Cusick
Joel,
Both transformations are correct:
Trimble's values are correct for transforming ITRF2000 coordinates
referred to 1993.62, and
Michael Dennis' values are correct for transforming ITRF2000 coordinates
referred to 1997.00.
That is, values for the transformation parameters are a function of the
time to which the ITRF2000 coordinates are referred.
Commonly, ITRF2000 coordinates are referred to the date when the GPS
observations are collected in the field. At least, this is what OPUS
does. To refer ITRF2000 coordinates to some other date, would require
you to know the ITRF2000 velocity at the location where the GPS
measurements were performed.
However, it is possible that Trimble's HSTAR service does not update the
coordinates of the CORS it is using to the date at which the
measurements were performed. HSTAR may be using the ITRF2000
coordinates for the CORS as published for 1997.00 without accounting for
the motion of these CORS from 1997.00 to the date of your observation.
If this is true, then the Trimble-provided ITRF2000 coordinates for your
observed points correspond approximately to their location at 1997.00.
Hence, it would be better to use the parameters that Michael Dennis has
suggested.
***************************
From Michael Dennis
To Dr. Richard Snay
Thanks for your input, Richard. I probably should have copied you early on
GPS Tests – Hawaii March 26, 28, 2009
Page 21 of 32
in this thread, but I didn't want to bother you with something that already
seemed clearly defined in your papers and HTDP. However, what I considered
"clear" was obviously not clear to others, so having your comments helps
greatly.
Thanks again!
Michael
***************************
To Trimble Support
From Joel Cusick – 12-22-08
Recent testing on Hawaii with H-Star gear on OPUS generated control have
revealed shifts when exporting using existing NAD 1983(PACP00) parameters.
Request that a new NAD83 Datum Transform for the Pacific Plate (Hawaii,
Guam, Samoa) be inserted into Pathfinder Office and TerraSync as soon as
possible.
Mr. Snay and Michael Dennis have both suggested a modified datum set of
parameters that... "sic... using HTDP.. computed in two steps, first from
ITRF00 to ITRF94, then from ITRF94 to PACP00. When I combine those
transformations, here is what I get for ITRF00 --> PACP00 at 1997.0"
>
HTDP
>
Trimble
>
Tx = 0.91023 m
0.9102 m
>
Ty = -2.10411 m
-2.0141 m
>
Tz = -0.56015 m
-0.5602 m
>
Rx = 0.027741 arcsec
0.029039 arcsec
>
Ry = 0.013468 arcsec
0.010065 arcsec
>
Rz = 0.002712 arcsec
0.010101 arcsec
>
S = 0.0
0.0
If these parameters are inserted into PFO, the user can obtain near exact
results than if a user set to "Use reference position from base files
option" and selected NAD 1983 (CONUS) on export. Though the benefits of
using Base file option is great for CORS, there are a number of NON CORS
base stations that will make the base file approach not-workable. In fact,
my tests have shown that, unlike SOPAC sites in Alaska, the SOPAC site I
tested does not store the NAD_1983(PACPoo), Epoch 2002.0 in its base file.
By providing this new Datum transform, Hawaii users and beyond have more
flexibility in holding reference position from Base Provider and lessening
confusion due to the ITRF00 (Epoch 1997.0) code throughout the differential
wizard. D
Request that a new NAD83 Datum Transform be inserted into Pathfinder Office
and TerraSync as soon as possible. Mr. Snay's and Michael Dennis's thread
are attached here. Also, files have been placed on FTP for your perusal.
These include SSF file, OPUS control sheet, PDF's generated from
postprocessing and movie files depicting the differences in ArcGIS (when
same parameters are used).
1) Rename existing NAD 1983 (PACP00). This request suggests leaving the
existing NAD 1983 (PACP00) datum transform, but renaming the existing NAD
GPS Tests – Hawaii March 26, 28, 2009
Page 22 of 32
1983 (PACP00) to NAD 1983 (PACP00 HARN 1993), or something similar. In this
case, a user could still utilize the 7 parameters to transform ITRF00
coordinates referred to 1993.62
2) Add a new datum transform using parameters below. Suggest naming NAD
1983 (PACP00 1997.0) or something similar.
3) Redistribute a patch for all PFO users.
4) Create a Support note showing how PFO users prior to 4.1 can enter said
parameters themselves.
5) Patch for TerraSync, allowing a person to select the incoming datum for
NDGPS realtime. Parameters modeled from above.
NPS FTP - Files include movies, raw data, OPUS solution and Maps.
To do this Click on link ftp://63.220.43.40/AKR/HawaiiDatumShifts/
a window will come up asking for username and password.
enter this:
Username (UPDATED): npsftpwin
Password (UPDATED and case-sensitive): FTP04npswin (Please note: it
is a zero, not an 'O'.)
***************************
From Sandy Margriter
To Joel Cusick
Joel,
What about the changes regarding using "base provider" vs. "base file" when differentially
correcting the data?
Thanks!
Sandy Margriter
***************************
From Joel Cusick
To Sandy Margriter
**************************************
On Base Provider Option vs Base File - Settings in Pathfinder Office
I'll start with my suggested answer - then follow up with reasons. I've added 4 PDF's - all the
ones we have distributed before, but in smaller file size. The latest
"KAHOGeoXHZephyrTestRight-Wrong.pdf"
is just created for this purpose. Remember oh so long ago (2 weeks) when we started on this
saga. The Red (Wrong way) and Green (Right Way). Now, since we have discovered
collectively a new datum transformation that is needed in PFO, were ready to answer.
Answer - I would use "Use Reference position from base provider" for all of Hawaii and Pacific
Park Units and enter the new Datum transform parameters. There are several ways to get to
essentially the same answer, but taking this route offers 3 things over "Use Reference position
from base files".
GPS Tests – Hawaii March 26, 28, 2009
Page 23 of 32
1) It's the default (and sticky) choice in Pathfinder Office. The risk of forgetting to select base
files, just once, will move your data 1+ meter away with just a click. See
"KAHOGeoXHZephyrTestRight-Wrong.pdf"
2) It's the easiest way to confirm the Base provider coordinates are right. A quick comparison of
the Trimble coordinates supplied during differential correction, and entering the site id on
www.ngs.noaa.gov/CORS, provide all users an opp. to "check in". This is our training standard
and ensures users always check to see if the station they are holding is correct. See your
training manual on steps on verifying coordinates. Its easy, and essential to ensure your doing
the right thing.
3) By using Base Provider, I don't have to change my powerpoints! Ha. No, in reality, this is the
training standard, and there is little change for you, as a Train the trainer, to simply tweak a few
slides and teach from. Instead of selecting NAD 1983(CONUS) CORS96, you use the NAD
1983(NEWPACP00) . If you use base files, then you'll also have to alter your Export settings.
This gets confusing (trust me on this), real fast.....
Simply, the risk is too great to use base files within the existing Trimble framework. Yes, you get
essentially the same answer, and you will, for the time being, have to get everyone to enter the
parameters themselves (see below), but when the bug fix comes out (maybe very soon - We
hope), you'll be aligned with CORS just fine using the correct PACP00 parameters.
Entering the New PACP00 Parameters - this will have to be done before your next field trip.
On this final note, were at a point now where if you were collecting data today for a project, I
would definitely get folks to enter into PFO, the new parameters and when PFO 4.1X comes out
with the new patch, there is little change you will have to do. Its easy to do. Us in Alaska and
lower 48 had to do this back in May 2005 when Trimble first rolled out CORS96.
1) We know the NAD93 PACP00 parameters given in PFO 4.1 now are wrong. We now know
the right ones. Here is the screen shot I would recommend gets inserted into a cheatsheet for all
users to enter into their PFO. Then, when you are in the Export Utility for Shapefiles, select
System = UTM Zone 5, and this DATUM choice NAD 1983NEW(PACP00) will be available. A
user picks it and you'll be RIGHT>
2) The cheatsheet, though written for CORS96 has all the exact steps.
http://trl.trimble.com/docushare/dsweb/Get/Document-170369/SprtNote_PFOGPSA_NAD83Datum.pdf Alter the values on bottom of page 6 , top of page 7 to these. Use this
screen shot for page 7. Ignore all the rest.
The coordinates to enter are here (for copy paste)
>
>
>
>
>
>
>
Tx = 0.91023 m
Ty = -2.10411 m
Tz = -0.56015 m
Rx = 0.027741 arcsec
Ry = 0.013468 arcsec
Rz = 0.002712 arcsec
S = 0.0
GPS Tests – Hawaii March 26, 28, 2009
Page 24 of 32
Every PFO user in Hawaii/Pacific Region should do this.
***************************
From Richard Snay
To All
Hi Everyone,
I feel that we have treated the symptom, but we have not cured the illness.
The transformation from ITRF2000 to NAD 83 (PACP00) is NOT a 7-parameter Helmert
transformation. It is a 14-parameter Helmert transformation in which the extra 7 parameters
address the motion of the Pacific tectonic plate relative to ITRF2000. Of these extra 7
parameters, only three are nonzero.
Our "fix" to PFO will work only as long as coordinates are referred to 1997.00 (= January 1, 1997)
as is the usual case for ITRF2000. However, the next realization of the International Terrestrial
Reference System (to be called ITRF2008) will most likely have its coordinates referred to some
other date. The international geodetic community hopes to release ITRF2008 sometime within
the next 12 months.
To cure the illness, we must encode 14-parameter transformations into our software and we must
become more aware of the date to which our coordinates are referred.
GPS Tests – Hawaii March 26, 28, 2009
Page 25 of 32
Richard Snay
***************************
From Michael Dennis
To Richard Snay
I agree wholeheartedly, Richard! I've been saying for years that the vendors should encode
defined 14-parameter transformations into their software (such as the relationships between
ITRF/WGS 84 and NAD 83). And I've also said that tying the transformations to ITRF 2000 at
time 1997.00 would cause problems when a new realization of the ITRS is released. Based on
your email, it appears that is imminent.
As far as I know, only one commercial package has encoded time dependent (14 parameter)
transformations, and it is not any of the big ones (ESRI, Trimble, Leica, or Topcon). However, it's
not a technical limitation, or a lack of awareness on the part of the vendors. The response I've
received from them is that doing so would be too confusing for most of their users, and there is
some truth to that. But I think nowadays that neglecting time dependence in datum relationships
is causing more problems than it solves.
The larger issue here is one of education. There is a role here for the vendors, for
knowledgeable members of the user community (including professional societies, such as
ACSM), and for government agencies such as NGS). Hopefully something the helps address this
problem will come from the recent GIAA Vendor Summit, which is supposed to represent the
intersecting interests of these groups.
Cheers (and Happy Holi-daze!),
Michael
GPS Tests – Hawaii March 26, 28, 2009
Page 26 of 32
Appendix:
Opus Sheet
FILE: 16901830.DAT 000507903
2005 NOTE: The IGS precise and IGS rapid orbits were not available
2005 at processing time. The IGS ultra-rapid orbit was/will be used to
2005 process the data.
2005
NGS OPUS SOLUTION REPORT
========================
USER: ts.gadget@gmail.com
RINEX FILE: 1690183a.06o
DATE: July 03, 2006
TIME: 18:10:55 UTC
SOFTWARE: page5 0601.10 master12.pl
START: 2006/07/02 00:01:00
EPHEMERIS: igu13820.eph [ultra-rapid]
STOP: 2006/07/02 02:09:00
NAFILE: brdc1830.06n
OBS USED: 4305 / 4469 : 96%
ANT NAME: TRM5800
NONE
# FIXED AMB: 27 / 31 : 87%
ARP HEIGHT: 2.0
OVERALL RMS: 0.021(m)
REF FRAME: NAD_83(PACP00)(EPOCH:2002.0000)
X:
Y:
Z:
-5489438.799(m) 0.089(m)
-2441587.995(m) 0.053(m)
2134254.984(m) 0.064(m)
ITRF00 (EPOCH:2006.4987)
-5489439.687(m) 0.089(m)
-2441585.766(m) 0.053(m)
2134255.864(m) 0.064(m)
LAT: 19 40 43.49698
0.029(m)
19 40 43.52496
0.029(m)
E LON: 203 58 42.60567
0.033(m)
203 58 42.52336
0.033(m)
W LON: 156 1 17.39433
0.033(m)
156 1 17.47664
0.033(m)
EL HGT:
31.480(m) 0.113(m)
31.687(m) 0.113(m)
ORTHO HGT:
12.883(m) 0.116(m) [Geoid99 NAVD88]
UTM COORDINATES
STATE PLANE COORDINATES
UTM (Zone 04) UTM (ZOne 05)
SPC (5101 HI 1)
Northing (Y) [meters] 2178667.595 2178747.217m
93664.126
Easting (X) [meters]
812303.525 183184.913m
445318.089
Convergence [degrees] 1.00381481
-0.17561691
Point Scale
1.00080574
1.00000361
Combined Factor
1.00080079
0.99999866
US NATIONAL GRID DESIGNATOR: 4QHG1230478668(NAD 83)
BASE STATIONS USED
PID
DESIGNATION
LATITUDE LONGITUDE DISTANCE(m)
AF9552 UPO1 UPOLU POINT 1 CORS ARP
N201445.166 W1555301.654 64417.1
DG9765 MLO1 MAUNA LOA OBSERVA CORS ARP N193209.282 W1553434.277 49448.4
DF6320 PAH1 PAHOA 1 CORS ARP
N193104.425 W1545742.645 112585.6
TU2619
NEAREST NGS PUBLISHED CONTROL POINT
KEAHUOLU PT NE RNG MARKER
N193958.329 W1560144.162
1599.4
This position and the above vector components were computed without any
knowledge by the National Geodetic Survey regarding the equipment or
field operating procedures used.
GPS Tests – Hawaii March 26, 28, 2009
Page 27 of 32
KAHOGeoXHZephyrTestHoldITRF00.pdf
GPS Tests – Hawaii March 26, 28, 2009
Page 28 of 32
KAHOGeoXHZephyrTestHold83.pdf
GPS Tests – Hawaii March 26, 28, 2009
Page 29 of 32
KAHOGeoXHZephyrTestHoldITRF00-butModifiedParams.pdf
GPS Tests – Hawaii March 26, 28, 2009
Page 30 of 32
KAHOGeoXHZephyrTestRight-Wrong.pdf
GPS Tests – Hawaii March 26, 28, 2009
Page 31 of 32
GPS Tests – Hawaii March 26, 28, 2009
Page 32 of 32