Spatial - Ed.com

Spatial-Ed's observations and analysis of impacts to desert for Burning Man 2012

Burning Thoughts 2012

Preliminary Burning Man 2012 EA from BLM - click here

Pathfinder Office users in Hawaii, correct NAD83 PacP00 (Epoch 2003) parameters click here for details

Home Datums Cheat sheets Lesson learned the New WGS84_to_NAD83( PacP00) on the Big Island of Hawaii
Lesson learned the New WGS84_to_NAD83( PacP00) on the Big Island of Hawaii PDF Print E-mail
Dear Hawaii/Pacific GPS users,

This issue applies to those using Trimble Pathfinder Office software
(versions 3.3 forward) using the Export Utility and exporting to "NAD83"
using the datum transformation called NAD 1983 (PACP00 EPOCH 2003.0). One
of the parameters is wrong, translating into an approximate 10cm shift
relative to the correct parameters. For data collected using H--Star or
carrier phase measurements a 10 cm shift relative to OPUS control is not
acceptable. The name of the shifter is also wrong and should state EPOCH
2002.0, not EPOCH 2003.0.

I do not have Trimble Geomatics Office (TGO), but since both TGO and PFO
use the same CSD, this same issue should be apparent in TGO.

This all points to the complexity and confusion that surrounds the datum
issue and how we should never trust the black box. I am as much to blame
for the typo of EPOCH 2003.0 for the shifter name. Up here in Alaska, our
EPOCH is 2003.0, while all other CORS stations are in the 2002.0 EPOCH.
That mistake was mine in translating the parameters to Trimble support
personnel - for that I apologize.

There are three immediate fixes to this problem.

1)Don't use the PFO default "Use reference position from base provider".
Instead, for all CORS postprocessing when holding ITRF00 (1997.0) epoch,
use "Use reference position from base file" option (4th step in the
Differential Correction Wizard). This translates your COR file to the NAD
1983 (PACP00) 2002.reference frame. Then, upon Export to a "NAD83"
coordinate system, use NAD83 (CONUS). This makes no sense in the verbose
usage of CONUS, but in this case, NAD83 (CONUS) is a Molendesky 3 parameter
shifter with 0,0,0 as the three translation parameters. Hence, your data
is not shifted. Finally, in selection of the PRJ, you can use a UTM Zone
or State Plane Zone NAD83 prj, which will merely tag your data as "NAD83".
It would be incumbent on the user to define in metadata that your data is
really NAD83 (PACP00) EPOCH 2002.0.

2) Create a new Datum transform.
An Interim fix to this issue can be done easily, but requires each installation of PFO be modified. It is our hope
that Trimble will fix the issue in next release of PFO. Until that time, I
would suggest the following fix below. By doing this, you can also verify
the old and new shifter parameters yourself.

3) Continue to use NDGPS CORS beacon for submeter mapping.
Tests I have conducted in KAHO, using realtime NDGPS beacons have revealed submeter to
subfoot solutions. Hawaii is smothered with signal, so a ProXR, GeoBeacon
or any other realtime NDGPS beacon receiver would be extremely beneficial.
In these cases, with 100% realtime coverage, you would do the same type of
export in Step 1 and select NAD83 (CONUS) as your shapefile export since
your data is already in the National Reference Frame selected to use by
NGS.

Steps to Enter the new parameters in CSD
Open PFO and the Coordinate System Utility (Utilities / Other). Select the
Datum Transformation tab and find the NAD 1983 (PACP00 EPOCH 2003.0).
Right mouse on the datum shifter and select Duplicate.
Name the new shifter NAD 1983 (PACP00 EPOCH 2002.0).
Next, select the Seven Parameter icon on right side of pane.
Right mouse, select edit.
Alter the Translation Y parameter to -2.0141
Press OK.
Save the CSD File by selecting File Save from the main menu.
Close The coordinate system manager.
Close PFO
Reopen PFO. The datum transform will be available.

The 7 parameters are copied here for ease:
Translation (m) =0.91023
Translation y (m) = =-2.0141
Translation z (m)= =-0.56015
Rotation X (secs) = 0.027741
Rotation Y (secs) = 0.013468
Rotation Z (secs) = 0.002712
Scale Factor (ppm) = 0


NOTE to ArcPad users.
I will defer to the Arcpad experts on the islands,
but I would have to guess that the default shifters in Arcpad 7,8 and 10
should be checked and if wrong, altered in the transforms.dbf to match .
This would apply to those using GPS Correct workflows.

Happy Holidays,

******************************************************
Joel Cusick
National Park Service/Alaska Regional Office
240 West. 5th Avenue, Anchorage, AK - 99501
(907) 644-3549 This e-mail address is being protected from spambots. You need JavaScript enabled to view it.
+61°13.0213', -149°53.1763', (NAD83 CORS96)
6VUN4499490383 USNG
******************************************************
----- Forwarded by Joel Cusick/AKSO/NPS on 12/29/2010 12:14 PM -----

Joel
Cusick/AKSO/NPS
To
12/29/2010 12:14 This e-mail address is being protected from spambots. You need JavaScript enabled to view it.
PM cc

Subject
Datum param. Ty = -2.10411 m for
pacp00(2003.0) is incorrect









Dear Trimble,
sorry to bear bad news (again), but according to Michael Dennis (now with
NGS Silver Spring MD) the parameters in the most current CSD for Trimble
Pathfinder Office is incorrect in the Translation (Y) component. The
correct value is -2.0141

I will not clutter this email up, and only forward onto you Michael's
comment and my datum shift map. This applies to PFO v. 5, CSD version
2.90; Database version 0.08; Upgrade level 57.(See attached file:
ShiftDiff-PACP00-EPOCH2003.0.pdf)

As revealed in this attached map that I constructed today, the shift is
translating 10cm (0.1m) of error in those solutions that are holding the
"Use Reference Position from Base Provider) and exporting to the existing
NAD 1983 PACP00 (EPOCH 2003.). When I created a duplicate datum transform,
switching only the Translation Y parameter, the mistake is revealed on the
ground.

You can verify this two ways.
1) The Translation Y value for NAD 1983 (PACP00) is correct in the
Coordinate System Database (CSD). The three X,Y and Z translations should
not waver for PACP00. Hence, you can observe the mistake when comparing
the two PACP00 shifters. NOTE: This email has nothing to do with the
older, deprecated use of NAD83 (PACP00) in CSD.
2) A mistake was made during previous correspondences between you, myself
and NGS. NOTE that Michael Dennis admits error of typo below. Please
contact Michael Dennis directly with questions.

Thanks must go to Laura M. Levy http://www.spatial-ed.com and Danielle in
finding this discrepancy.

Many of you have been involved in this matter of datum shifts in Pacific.
I want to thank all of you.

******************************************************
Joel Cusick
National Park Service/Alaska Regional Office
240 West. 5th Avenue, Anchorage, AK - 99501
(907) 644-3549 This e-mail address is being protected from spambots. You need JavaScript enabled to view it.
+61°13.0213', -149°53.1763', (NAD83 CORS96)
6VUN4499490383 USNG
******************************************************


CLICK HERE TO VIEW PDF MAPS for TESTING RESULTS -
 

Registration



JOIN US TODAY !