A few years ago when WAAS was coming out I pointed out that with WAAS using WGS84=ITRF00 as a datum rather than NAD83 there would be continuing confusion as to the datum being used for point positioning.

This indeed seems to be the case. What is the situation? Does all point positioning software clearly indicate what it is providing? Does some software give the option for the user to specify the datum of the output coordinates?

Is there software that outputs code range coordinates in WGS84=ITRF00 and labels them WGS84 and carrier phase results in NAD83 and labels them as WGS84?

...What I do know is that I send files to my favorite branch of the US Government, NGS OPUS. They send me files with NAD83 Lat and Lon, NAD83 SPC in meters and now in US feet. I plug the NAD83 Lat and Lon in my software and the other numbers agree. I put the printouts in my file and I sleep well at night.

Those that want to use WAAS and ITRF data can and have calculated local correction factors. They to sleep well also.

We do differential positioning mostly in surveying, so in general the details of the datum stay in the washing machine.

Paul in PA
Modified By Lawrence Paul Lopresti on 4/19/2006 at 4:46 PM

With regard to the Mobile Mapper or Mobile Mapper Pro....not the Mobile Mapper CE as I haven't tried it, the software onboard the Mobile Mapper will allow you to create a custom projection such as your local State Plane coordinate system to display the "converted" Lat/Lon to SPC. Now, as JD has pointed out several times, the Mobile Mapper in using its WAAS correction is related to as you say ITRF00.
Now, apparently "the trick" is to "tweek" the false northings and eastings of the projection to account for the "shift" from ITRF00 and NAD83...so that in "real time" the Mobile Mapper (again, NOT the "real time submeter Mobile Mapper CE)is displaying SPC that are "closer" to the real deal.

Now, I say "closer" because even though I do think it is an elimination of a systematic error to "tweek" the false northings and eastings, in the end I think it is a flagrant violation of the rules of significant figures.

Real time WAAS positions are accurate to what, 2 or 3 meters? So if you "account for the shift", your real time accuracy ellipse just moved by the amount of the shift on your display, but still, it is only accurate to 2 or 3 meters. Correct?

Now, as Phil mentioned below, there are ways to "take advantage" of data collection meant to be used with the higher end survey grade L1L2 equipment through the use of having a simple GPS receiver that is capable of exporting the NMEA string in real time to hardware/software that includes a "localization" routine for the RTK end of the software.

But even then, I still think 2-3 meters is the best you are going to do.

Dangerous Dave

yes, you did "point that out" to us all a few years ago in a uniquely titled thread :-)


as for handling the ITRF WAAS offset, we figured out a work around a few years back with our Reliance back-pack unit. We "tweaked" the false Northing and false Easting in our data collector so that it would force the displayed coordinates to more closely represent our true positions in real time. The stored data, on the other hand will be standard raw data, causing the same offset problem to be encountered in the office. It is a royal pain to be required to make these silly pseudo corrections to get NAD83 data. I realize that WAAS is designed for much more than our NAD83 needs and should not be blamed for the problems. It would seem like a simple fix for the wonderful manufacturers of gps equipment, PARTICULARLY GIS TYPE UNITS USED IN THE U.S.A. (NAD83 LAND), could accomodate such a simple fix.

We deal with this problem more often than ever now with the ProMark3. It has even better capability to position a point (under proper sv and sky conditions) than our Reliance unit with dgps correction subscription. With this added precision/accuracy, the 2' by 2' offset can be readily noticable.

You had originally titled your thread "Ashtech Solutions is Wrong", which turned quite a few heads (mine for sure). Even though I thought the title was a bit unfair under the circumstances, the context was, and is, 100% true. But I would bet there is no solution for this problem offered by Trimble, Topcon, Sokkia, Leica, et al, either.

If someone has addressed this issue and offered a real solution, I would really be interested.

jd

since this thread is "moving", I don't want to try and edit my previous post, so here's an addition.

Lately, when preparing georeferenced shape files from good coordinates, we have started just shifting the entire drawing in autocad before creating the shape file. This puts the search points more in line with the real time ITRF positions reported by WAAS. We use this for monument search often, but have to remember that the coordinates we have in the point attributes are "bogus".

screwy mess

jd

I agree with you that the fault lies with the software produced by the instrument manufacturers. There is no reason at all there cannot be a software option that allows the user to specify that he/she wants NAD83 coordinates.

By the way, thanks for your answer a few days ago about the accuracy of the OPUS result on POST.

Arcpad 7 does address this issue. you can choose the gps datum as irtf00 and it accounts for the shift. It is very buggy, however. There is supposed to be a patch released soon to address these issues.

I'm going to edit my spc projection tonight in FastSurvey to reflect the shift, which is 2.30' N and 2.07' E in my area. It's built by carlson, looks and feels like SurvCe. The geoid difference is -5.58'. I'm gonna handle it a little different by taking it off of the rod height. I appear to be getting accuracies tight enough that it will make a difference. More observations and experiments will tell.

I also found out today that I can't afford FastSurvey just for recon and rough mapping with the MM CE. If I had a Zmax or something, it would be different. I already have SurvCE on an explorer II and I can't use two data collectors at the same time. I am looking forward to the build of GisCE that will run on the MMCE. I'm also looking for the next exterminated version of Arcpad 7, although not with as much enthusiasim(?), er, excitement.
terry

I'm having a difficult time with this. If my irtf latitude is north of the nad83 latitude by 0.698 meters, wouldn't I subtract from the false northing by 0.698m? And, the itrf longitude is 0.632m West of the nad83 lon, wouldn't I add the 0.632m to the false easting? Also, the itrf elipsoid height is 1.7m lower than the nad83 elipsiod height, wouldn't I subtract the 1.7m from my rod height to get the correct elevation?

Sheesh, this is supposed to be simple. I may need some math help from a 3rd grader. I think this is right, but I would like to have an "amen" or a "OHNO" please. It's been a long day...

I'm not convinced yet that the FastSurvey software isn't handling this transformation, but I don't know who to ask about this, either. I was getting pretty much sub meter before I started monkeying with the transformation numbers.

thanks,
terry

I have not yet surrendered this hill. Sometimes I whine. Sometimes I preach. You never can tell. Someday things may change.

But in the scheme of all things... I will never understand why the FAA bought into the notion that the WAAS had to be referenced to ITRF00 when modern mapping in the USA should all referenced to a modern variation of NAD83.

I understand all about international treaties and such. The reality is, when you are trying to set 200 souls down soft and gentle on a runway, that a two meter datum shift is not likely to amount to a hill of beans. Let them navigate on NAD83(CORS96) and just tell them it is WGS84.

Doing that would let them land the plane and let the rest of us make maps with fewer cases of heartburn.

But there are many items on the list of things that are not controlled by me.

Pick a point and do an OPUS observation. Whatever OPUS says the transformation is from ITRF to NAD83 is good enough for me.

From my last OPUS:
_____NAD83_______ITRF
LAT: 39 57 6.77980 39 57 6.81012
W LON: 75 1 18.94489 75 1 18.95754
EL HGT: -14.572(m) -15.847(m)

I agree with your directions, get some sleep.

Paul in PA
Modified By Lawrence Paul Lopresti on 4/20/2006 at 12:07 AM