Activity Feed › Discussion Forums › Strictly Surveying › Trouble between GPS pairs – Help
That DC file shows a rotation of .37″, that kind of accuracy doesn’t happen by accident. The original control was probably an early GPS survey. I would occupy it and treat it as TN SPC and see how it works. You will probably find that it’s just fine as it is and maybe be able to figure out the project scale factor if one was used.
1990 era GPS will not of course tie into today’s CORS or OPUS, but that isn’t the point of using the city control.
I would also apply GEOID 12 to the 29 elevations to get the correct ellipsoid heights for this control. I would try to scrape the calibration if at all possible.
Is it possible that he occupied one or two points that are incorrect, and that is warping and throwing the whole ‘calibration’ off?
I’m with the other posters. Setup your base, OPUS that sucker, but then I would run around with RTK and recollect your control points on state plane. You are looking for a large error here, so you don’t need to spend a ton of occupation time, just collect them all, and then look at an overlay of the original CP coordinates. If you have 1 or 2 bad points, they should jump out at you.
- Posted by: MightyMoe
I would also apply GEOID 12 to the 29 elevations to get the correct ellipsoid heights for this control. I would try to scrape the calibration if at all possible.
Applying GEOIDxx to anything NGVD29 won’t get you a NAD83 Hae ever! Converting NGVD29 to NAVD88 with Vertcon and then applying GEOIDxx will get you close within the error of the geoid model being used + the error of Vertcon.
SHG
I just wanted to post and say thank you to everyone for the comments and help offered. All of this information is very useful and I plan to keep it in mind as we move forward.
My guess is from the parameters that the DC file must have been started using the TN 4100 projection from the library and the infamous HERE 1 pt calibration added at a point with a keyed in elev of 1200 in m rather than ft. The Translation East: -0.604; Translation North: 0.192; in m has the look of a lot of autonomous 1 point calibrations that I have seen.
If indeed the city control monuments are true state plane grid and were not located using this calibration to begin with you would have issues checking into them using this calibration – particularly the further you are from the origin point.
You have a perfect opportunity to develop an LDP going forward to avoid all these problems. Then what you measure with a total station would be what you measure with GPS. No scaling – no mess. We bit the bullet and did that a few years ago and nothing but positive comments about it from the surveying community around here who have adopted it.
No of course it wouldn’t give out the NAD83 ellipsoid height. As I said it will give you “correct” height that will work with this control, not that will work with an OPUS #, which this control isn’t.
I just checked a station in middle TN, the NAVD88 elevation is 674.38′ the NGVD29 elevation is 674.31′. Looking at another in the area I see 712.06′ and 711.99′ so I’m assuming it’s similar where the OP is.
Setting on those marks and applying Geoid12 to them will result in an ellipsoid height .07′ lower for 29, but it will allow you to survey and stay on 29 better than a calibration.
The Geoid12 #’s were telling for mark #1 the geoid height is 27.94m and at #2 it’s 28.04m, .32′ in a short distance, so there is quite a geoid slope to deal with there.
Ellipsoid heights are slippery things, here is one local datasheet with it’s heights:
NAD83 (1994) 1173.304m (2001) 1173.260m (2007)1173.219m (2010)1173.185m that’s quite a spread.
the Geoid12 height of 13.36 applied to 2010 results in an elevation of 1186.545m, the NAVD88 elevation is 1186.527m (first order bench mark) or about .06′ lower than the latest ellipsoid height/Geoid combo.
Point being that getting the “perfect” ellipsoid height isn’t all that useful for this control, you could do it and apply offsets which might be fine but the first thing to do is to find out if the 1990 control will work internally by setting on it, accepting it and surveying between the points. If it works then use it as is.
I plotted the point of origin for the horizontal adjustment. Looks reasonable.
Position Type State Plane - Tennessee Degrees Lat Long 36.5285671?ø, -082.5271126?ø Degrees Minutes 36?ø31.71403′, -082?ø31.62676′ Degrees Minutes Seconds 36?ø31’42.8416″, -082?ø31’37.6055″ State Plane X Y (Meters) 4100 910966.964mE 249084.128mN X Y (US Survey Feet) 4100 2988730.781ftUSE 817203.511ftUSN X Y (International Feet) 4100 2988736.759ftE 817205.145ftN UTM 17S 363284mE 4043661mN UTM centimeter 17S 363284.51mE 4043661.48mN MGRS 17SLA6328443661 Grid North -0.9?ø Interestingly at 1817 Hermitage Drive within a foot or two of the approx lat and long in road view we find a painted arrow?
@bryandean8611
All of you guys are way ahead of me. I have been out of it for nearly a decade.
As has been said, I too believe fresh measurements are in order. Incorporate it into your ongoing projects, little by little as time and budgets permit.For perspective it would be interesting to know what hardware and software was being used then.
In that era I too was trying to densify a high quality network for total station work “on the grid”. This was with Locus single frequency receivers and the bundled software. We had lots of issues, mostly learning curve, but also some random errors… even when the software said we were good. Luckily I had starnet and was able to see how whacked it was so we never published and used ground methods for our actual work.
We did not know better, technology improved greatly in the next 5 or 10 years.- Posted by: MightyMoe
No of course it wouldn’t give out the NAD83 ellipsoid height. As I said it will give you “correct” height that will work with this control, not that will work with an OPUS #, which this control isn’t.
I just checked a station in middle TN, the NAVD88 elevation is 674.38′ the NGVD29 elevation is 674.31′. Looking at another in the area I see 712.06′ and 711.99′ so I’m assuming it’s similar where the OP is.
Setting on those marks and applying Geoid12 to them will result in an ellipsoid height .07′ lower for 29, but it will allow you to survey and stay on 29 better than a calibration.
The Geoid12 #’s were telling for mark #1 the geoid height is 27.94m and at #2 it’s 28.04m, .32′ in a short distance, so there is quite a geoid slope to deal with there.
Ellipsoid heights are slippery things, here is one local datasheet with it’s heights:
NAD83 (1994) 1173.304m (2001) 1173.260m (2007)1173.219m (2010)1173.185m that’s quite a spread.
the Geoid12 height of 13.36 applied to 2010 results in an elevation of 1186.545m, the NAVD88 elevation is 1186.527m (first order bench mark) or about .06′ lower than the latest ellipsoid height/Geoid combo.
Point being that getting the “perfect” ellipsoid height isn’t all that useful for this control, you could do it and apply offsets which might be fine but the first thing to do is to find out if the 1990 control will work internally by setting on it, accepting it and surveying between the points. If it works then use it as is.
OK, you are more clear in the follow up response, there has been LOTS of control reports published with “ellipsoid heights” that are nothing more than the ortho heights with the geoid model backed out, when using NAD83/NGVD29 which was common here in Oregon and is still used some places, the ellipsoid heights were about 3-4 feet different from truth and are worthless. I have also followed behind others on Dod installations where they provided “WGS84” elevations by simply applying EGMxx to NAD83 ellipsoid heights and guess what, verticals had about a meter of error. My comment before the follow-up was to let folks know that ellipsoid heights can be important and in fact in 2022 will be ALL you measure and then applying the new gravity geoid model to get derived ortho heights.
I do a little different procedure than most when it comes to heights, I actually publish real LLH and then apply the proper geoid model and then adjust the results to local BM’s if I think that is warranted. If going to NGVD29, I apply geoid model to Hae, convert that to NAVD88 with Vertcon and then make any adjustment needed. These methods keep real LLH and local ortho heights separate, I realize that isn’t as easy as pushing a button and getting a site calibration, BUT it also rarely ends up with a screwed up mess and has the advantage of being able to do something later with the data if need be where it isn’t all warped and tilted and scaled.
SHG
It’s going to be interesting, from my above example there are 4 different ellipsoid heights over 24 years that vary by 12cm on a HARN point that’s a first order bench mark. Over the last 30 years there is only one elevation for that point and no combination of ellipsoid height and Geoid model has ever resulted in that elevation.
The community has of course fixed the elevation as the basis and not the ever changing GPS data, to use the elevation it’s best to apply the latest Geoid model to the elevation and not the other way around. The last time I sat on it, I took the dat file and sent the same file to OPUS twice, the two returned calculations produced two different elevations. They used different CORS for the calculations, basically it wasn’t a useful exercise for elevation control, it’s interesting academically, but not for real world surveying.
The OP has the same issue, he is using 29 elevations that are very close to 88 elevations and the community wants to keep holding them. This is probably mandated by years of accumulated data and FEMA control. Moving the data XYZ would result in a shift of all those projects, drawings, ect. Doing that should be done very carefully with all stake holders involved.
Log in to reply.