thebionicman, post: 448362, member: 8136 wrote: Im hoping the added complexity will cause some to either read a book or quit...
LOL... I wouldn't hold my breath on that. It hasn't bothered them enough for the last two decades. I agree; its staggering how many licensees I have worked closely with that have zero grasp of where the N, E, and Elev coordinates they rely upon every day actually came from. "From the magic GPS" is good enough to satisfy their minds enough to give it the stamp. I guess ignorance truly is bliss.
They don't know, they don't care, and they don't care to know. You can't change or fix that.
Reminds me of when I asked a field guy whether the elevations on stakes in my neighborhood were NGVD29 or NAVD88 and he replied that they do everything in NAD83.
Bill93, post: 448450, member: 87 wrote: Reminds me of when I asked a field guy whether the elevations on stakes in my neighborhood were NGVD29 or NAVD88 and he replied that they do everything in NAD83.
Yep. I've seen plans that said "Vertical Datum: NAD 83". Umm, no.
This is why Substantial control points should be set on the job site
so if the control points shift over years due to continental drift the control points are still correct relative to
each other
Most important
1) a control drawing showing coords with the datum and year "epoch"
.
And just localize
Oh well
One one 200 mill and another 800 mill job no control drawing what a joke just a couple rusty 8" spikes in a mud puddles
!@$@*$)$@ construction clowns.
Pete
We got us a new vertical datum...found on a plan...
Loyal: funny that you would post that on Tuesday...I was in Rolla, MO at USGS that day and some NGS folks were there giving a presentation on NATRF2022 et al. Someone mentioned WGS84, reaction was visceral. The ensuing discussing revealed that PROBABLY the reason WGS84 frequently comes up is that software developers often would call for WGS84 in their software. I believe this goes back to the early days of GPS. When I first started doing GPS, NAD83 was not yet released. We only had NAD27. GPS was in WGS72. If one used NAD27 in processing, it would create a bias. Then, the Air Force switched over to WGS84 and supposedly made it equivalent to NAD83. Since NAD83 is really a North American datum (although it is technically valid worldwide), they needed something that they could put in the software as a requirement worldwide that would be synonymous with using the GPS "geocentric" datum rather than a local datum such as NAD27 or SAD69, etc. At that time there was no ITRF (at least not that I was aware of). Some local datums are 100's of meters off from WGS84 (which uses the GRS80 ellipsoid, same as NAD83, same as NATRF2022 will use).
Many people like to say there is no way to survey on WGS84 unless you are DoD. In my opinion, not true. While not exactly equal, recent realizations of WGS84 are set "equal" to ITRFxx at a certain epoch, and they are aligned at the sub centimeter level. I have worked on a lot of military bases, and there were times (mostly on Air Force bases) where we were required to use their "WGS84" monument on base. These were usually (at that time) precise point positions, probably accurate to about 30 to 50 cm. So it was actually a degradation in accuracy to use those.
I do get requests to provide WGS84. I then ask, which one? Usually it is the latest (currently WGS84 (G1762)=ITRF2008/IGb08). However, there is a certain type of photo control I do about two to four times a year that requires WGS84 (G1150) epoch 2012.667. That is what they want, that is what they get. Pretty easy to do, we simply use the CORS, then transform using HTDP to that datum/epoch (ITRF2000). I don't necessarily agree that they should be using that, but that is not my call. They originally wanted to use GEOID99, at least I talked them out of that. I actually have to produce NAD83 (2011) values first to use with GEOID12B to get NAVD88, then transform to WGS84 (G1150) epoch 2012.667.
The basic discussion that day was what is USGS going to do to convert to the new datums. Last time there was a major change (NAD27-->NAD83), they were almost entirely paper products. Now it is almost entirely digital.
One interesting thing I found out is that NGS does NOT want to call this a "readjustment". They are going to take all of the GPS data they have received (via bluebooking submittals by others and their own surveys) since 1997 and REPROCESS it all using updated orbits and ITRF coordinates. Typically, when they receive a bluebook submittal they do not reprocess/readjust. If it was done correctly, they accept the adjustment and put it in the database. I assume they know what they are getting into. I would expect there to be plenty of HI inconsistencies between the log sheets (which they are going to review, probably 100's of thousands) and the rinex files and the B file (which has occupation information such as HI's and antenna types). They used 1997 as a cutoff date because that is when CORS started becoming prevalent and good orbits became available. BUT, I am not sure how they will deal with occupations shorter than 2 hours (PAGES does not do well on shorter occupations). I know that I have submitted plenty of projects with shorter occupations. Of course, I have submitted projects with much longer occupations as well. The 1997 cutoff also means that there are a lot of projects (probably dozens) that i submitted that will NOT participate in the reprocessing.
