Do you have the data that the calibration was based on? Site calibrations are easy to screw up, this is a perfect example of why I don't like them. But the way this one was performed, there should have been huge residuals on the control points if there is error of the magnitude you're describing.
Personally, I'd start over. I agree with Linebender - put a good, real-world coordinate on your base and then go re-survey your control points; Do this in the SPCS coordinate system with Geoid12B and no calibration or scale. Four Observed Control measurements, taken two hours apart and with the pole oriented to a different cardinal direction for each, will give you a very good coordinate with respect to the base.
The data the calibration was based on is the city's control monuments, which are grid coordinates. I have not been able to come up with anything that would show me the reports of residuals when the calibration was done. What our "calibration" has become is a set of parameters in the DC, as follows:
This is what I find when I go to properties of job and look at the coordinate system.
Projection - Lambert Conformal Conic 2 Parallel; False Northing: 0.000; False Easting: 1968500.000; Origin Lat: 34d 20' 00"N; Origin Long: 86d 00' 00"W; Parallel 1: 36d 25' 00"N; Parallel 2: 35d 15' 00"N; Semi-major axis: 20925604.474; Flattening: 298.2572215382; Grid shift: no;?ÿCoordinates: Grid;?ÿProject Height: 3937'
Datum Transformation - Three Parameter with 0.00' translation in X, Y, and Z; Semi-major axis=20925604.474; Flattening=298.2572215382
Horizontal Adjustment - Type: Plane; Origin East: 2988730.781; Origin North: 817203.516; Translation East: -0.604; Translation North: 0.192; Rotation: 0d 00' 00.371311"; Scale Factor: 0.99999851
Vertical Adjustment - Type: Geoid/Inclined Plane; Geoid Model: ETENN(Geoid03); Origin North: 816600.112; Origin East: 2985597.185; Slope North: -3.209ppm; Slope East: 1.752ppm; Constant adjustment: 0.405
This may not help at all but I wanted to let you know that these are the parameters that were come with as a result of the calibration, as far as I know and have been told.
?ÿ
?ÿ
?ÿ
So I may be wrong but it looks like the calibration projection parameters are TN 4100 state plane parameters. The parallels are the same latitude. The origin lat and long are the same. The metric easting of the origin is 600,000m converted to US ft.?ÿ I have a problem with the project height shift. It looks like 1200m was converted to US ft. to bring it to 3937'. I believe you are closer to 1200 than 3937.?ÿ So your working grid is apparently 3937 ft above state plane grid.?ÿ
From there it appears for all intents and purposes the scale factor is 1 from a designated state plane origin point with a small transformation and rotation.?ÿ?ÿ
The Geoid/Inclined Plane solution was popular in the 90's but has been shown to cause issues vertically. That plus the Geoid is old.?ÿ I see lot's of potential issues.?ÿ
Good luck is about all I can offer other than what has been posted previously.?ÿ
?ÿ
?ÿ
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.
?ÿ
?ÿ
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.
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.