At the risk of muddying the waters even more, I offer the following comments:
1. From the original post, it seems that OPUS was looking for a decimal value and did not find it. I belive that point has been resolved satisfactorily.
2. Someone mentioned that GPS computes X/Y/Zs in the ITRF. I question that statement. Unless things have changed recently, the standard reduction of observed values is to compute either X/Y/Xs or deltaX, deltaY, deltaZs in WGS84. Now, it is true that ITRF is so close to WGS84 that the statement about computing in ITRF is (for all practical purposes) quite true. I'll agree it is picky semantics but a professional "does it right."
3. If we start on reliable NAD83 X/Y/Z values for the HARN stations, OPUS, or CORS stations, then the deltaX, deltaY deltaZ values obtained from the GPS system can be used on the NAD83. Caution - don't ever attempt to intermix NAD83 values and WGS84 values on the same survey. Use one or the other. (Experienced users who know what they are doing might say it is possible. The simple answer is "don't.")
4. I believe that a surveyor needs to know specifically and exactly what the software does with and to the data. There is a difference between ellipsoid height and elevation. That difference is called geoid height - almost everyone knows that. But, I get confused in reading this thread because it seems elevation and ellipsoid height are being confused at times. Here is where we need to be certain what the software is doing. Computations can be done using either ellipsoid heights or elevations (many software packages use elevation for the third dimension)if done consistently and with the full knowledge of the persons running the computer.
5. The difference between the normal and the vertical is called deflection of the vertical. Normally that difference is quite small - less that 10 seconds of arc. It the antenna height you input a distance along the normal or along the vertical? In all honesty, it probably does not matter. After all, the cosine of 15 seconds (to be generous) is 0.999999997 to 9 significant figures. How often do we know the antenna height more than 4 (or even 5) significant figures. So, your software could be written assuming the antenna height to be measured along the normal but we actually measure it along the vertical - no harm done over "short" distances such as antenna heights.
6. Are we comfortable with the statement that an adjustment needs elevation? If the adjustment being performed is done for the purpose of a horizontal survey, then the elevations could be way off without detrimentally affecting horizontal position. However, before stating that Burkholder says not to include elevations in an adjustment, rest assured I am in favor of always performing a rigorous least squares adjustment on 3-D data and pulling out the horizontal answers at the end (if the survey is a horizontal survey).
7. True, the antenna height input is needed to put the computations "on the monument." But, it is the user's responsibility to know what those X/Y/Zs represent. Elevations are obtained from the ellipsoid height only after applying the geoid height for that station: elevation = ellipsoid height - geoid height (but note, in the lower 48, the value of geoid height is always negative so that numerically, elevation is always greater than ellipsoid height).
8. Suggestions:
A. Always perform least squares adjustment in terms of true geocentric X/Y/Z coordinates and coordinate differences. If that is what your software does, you need to know it. If your software does something else, you need to know that as well and to evaluate your software purchases accordingly.
B. If you want elevations as part of the answers obtained from your GPS survey, my recommendation is to perform the 3-D least squares adjustment in term of true X/Y/Zs and to apply geoid modeling to get elevations. But, the caveat here is that one should always use geoid height differences (not geoid heights) when determining elevations - see example below.
C. Three examples are offered for readers convenience and consideration:
1. Example of static network least squares adjustment of true 3-D components - http://www.globalcogo.com/nmsunet1.pdf
2. Example of obtaining reliable elevation using GPS at NMSU - http://www.globalcogo.com/ReilElev.pdf
3. Example of 2-D plat based upon 3-D GPS survey - http://www.globalcogo.com/3DGPS.pdf
4. One-page summary of establishing elevations with GPS - http://www.globalcogo.com/gps-elev.pdf
GPS is a wonderful tools and has made life "better" for many of us. Mis-use of the tool can also be detrimental in many ways. If in doubt - ask. We are all in this together.
Earl F. Burkholder, PS, PE, F.ASCE
Global COGO, Inc.
Las Cruces, NM 88003
www.globalcogo.com
Thanks for jumping in Mr. Burkholder.
You stated above:
2.Someone mentioned that GPS computes X/Y/Zs in the ITRF. I question that statement. Unless things have changed recently, the standard reduction of observed values is to compute either X/Y/Xs or deltaX, deltaY, deltaZs in WGS84. Now, it is true that ITRF is so close to WGS84 that the statement about computing in ITRF is (for all practical purposes) quite true. I'll agree it is picky semantics but a professional "does it right."
Oky doky, here's “my” 2-bits on that subject:
It is my understanding, that reference frame of the deltaX, deltaY, deltaZ returned in a GPS baseline solution, is entirely dependent on the reference frame of the ephemeris used.
So, IF you are processing using the broadcast ephemeris, then you have dX, dY, dZ, expressed in WGS84 (G1150). IF on the other hand, you are using the IGS Ultra-Rapid, Rapid, or Final (precise) ephemeris (as OPUS does), then the dX, dY, dZ values are expressed in IGS08.
Now it follows that combining WGS84 or IGS08 vectors with NAD83 X/Y/Z values will impart a certain amount of error in the final solution, due to the scale and rotation differences between the datums (frames). This is a small distortion (trivial for say RTK usually), but NON-trivial for longer baselines.
This is why OPUS does the solution in IGS08 at the mid-epoch of the observation (say 2012.xxxx), and doesn't make the transformation to NAD83(2011) Epoch 2010.0000 until the very last. At this point, HTDP is used to make the velocity based “move” from 2012.xxxx to 2010.0000, and the 14 parameter transformation from IGS08 to NAD83(2011).
Basically IGS08 XYZ @ 2012.xxxx (@ the CORS) + dX/dY/dZ (IGS08) = IGS08 X/Y/Z 2012.xxxx @ the remote, which is then transformed to NAD83(2011) 2010.0000 via HTDP.
At least that's how I understand the process.
Loyal
Loyal,
Thank you for clarifying. I am more comfortable with what one does after obtaining the delta X/Y/Z's than in the fine points of getting the delta X/Y/Zs. If I understand your point correctly, the user's choice of ephemeris dictates the datum on which delta X/Y/Z are computed. I stand corrected.
You are spot on Dr. Loyal. A very nice explanation. This issue with WGS 84 comes up all the time. There are really only two ways you can truly be in the WGS 84 frame: 1) You perform autonomous positions (no connections to any ground control) in which case your positional uncertainty is roughly in the 5-8 m range (95% confidence). 2) You are tied to actual WGS 84 provided by the U.S. Defense Department -- good luck. The National Geospatial-Intelligence Agency (NGA), formerly the National Imagery and Mapping Agency (NIMA), formerly the Defense Mapping Agency (DMA) do not provide any of their control (either passive or active) freely available to the public.
Over the years these agencies have modified the frame to be more consistent with various iterations of ITRF. There have been 5 realizations of WGS 84, the most current realization of is called WGS 84 (G1674), which almost no one outside of NGA has heard of yet, is consistent with ITRF08. IMHO one of the most critical elements of the reference frame relationship, the epoch to which the coordinates should be referenced, is not well defined by NGA. In these days of cm level positioning this is critical. No one from NGA has ever cited the rational for this to me, but my best guess is that for DoD purposes the difference in position of a couple of cm over a few years doesn't mean much to them.
To this day the only "official" transformation between WGS 84 and NAD 83 is in the NGA manual TR8350.2 (page B.6-6)TR8350.2 and the dX, dY, dZ values are all 0. According to one source I have at NGA this is supposed to be updated later this year or early next. It will be interesting to see how they represent these relationships.
WGS84
Thanks for the update on WGS84 Dave!
I knew that the NGA was planning on updating WGS84 to "align" with ITRF/IGS 2008, but last time I checked their website (a week or so ago), there no mention of it.
WGS84(G1674) huh....Oky Doky.
Loyal
WGS84_LINK
http://earth-info.nga.mil/GandG/sathtml/gpsdoc2012_02a.html
Pretty easy to find when you KNOW EXACTLY WHAT to Google...
🙂
Loyal
Least Squares Adjustment Of XYZ Points
Lots of info and explanations in this thread. Thanks guys.