Activity Feed › Discussion Forums › Strictly Surveying › Trouble between GPS pairs – Help
Trouble between GPS pairs – Help
Posted by bryandean8611 on January 11, 2018 at 1:40 pmWe are having trouble tying in from GPS pair to GPS pair with our conventional total station.
Equipment:
Trimble R8 rover with a fixed, centralized Trimble R8 base station mounted on a building
Topcon 3005W, recently calibrated
TSC3 data collector
Background:
The base was set-up autonomously on a building and the rover was then connected to the base. Then, the rover was taken around the city and occupied about 20 city control monuments. A calibration was then applied and that is what we use for nearly all of our GPS work.
With that being said, the city control network was established in 1990-1991 in TN State Plane 4100, NAD 1983, NGVD 1929, Tennessee State Plane grid coordinates.
Problem:
Apparently, before I started here this has not been a problem, however, we have been having an awful time trying to tie into a GPS pair other than the one we started with.
In the past, our crew has set a GPS point or two ??on the way? while traversing through the jobsite as a check. Now, I??m wondering how well those really tied together?? but that was before my time. The way I was accustomed to setting up control for larger sites was to set a network of GPS pairs on a job site to minimize the length of the traverses and to make smaller loops for less chance of error. So, I have tried to incorporate that into our routine for larger projects here.
I understand that the calibration of the control network has stretched or shrunk the actual vectors in order to ??fit? into what we are telling it to fit in, which leads me to believe that there should be some kind of scale factor that I need to apply to my job settings for when we are using our total station. My understanding is also that the total station is measuring ground distances. I also understand that you can??t work in two separate worlds (Grid ?? Ground) and I am just looking for help to try to resolve our issue. If there is anyone out there that has faced a similar situation then please let me know.
Thanks.
MightyMoe replied 6 years, 4 months ago 16 Members · 30 Replies- 30 Replies
How big are the errors?
You say you recognize the grid-ground problem, but it isn’t clear you are applying the combined scale factor to your TS measurements.
You need to get that factor applied to all the surface distances. At least one of your instrument, data collector, or office software should be able to do that. (Don’t do it more than one place.)
The C S F is calculared from your location and elevation. Although your project is stuck in NGVD29 you could probably be close enough if you calculated C S F as if it was NAVD88. If you use CORPSCON6 to check the factor it is only correct for outputs in NAVD88.
I apologize if you already know all this. It wasn’t clear from your post.
.Again, without knowing the nature or size of the errors, it is difficult to help you.
If you are chasing 0.03 in the vertical, and just doing general topo, then that error was probably ignored by your predecessors.
If you are noting angular errors between points, then you have a world of problems that need to be addressed immediately.
The problem likely exists with “A calibration was then applied and that is what we use for nearly all of our GPS work.”
You don’t need a projection when using TN State Plane 4100, NAD 1983, Tennessee State Plane grid coordinates.
If you are performing a calibration on a project that should be on Stane Plane Coordinates, then you are no longer on State Plane Coordinates.
There are probably issues with the calibration. Was the original control conventionally located?
That being said the TS3 will handle the conversions as you survey, it will be as good as the calibration is. You shouldn’t need to adjust for ground/grid as you go. However, I don’t have that particular Topcon, I do know Trimble and Topcon instruments used to work together well.
I would take some time and analyze the control, “clean” GPS data vs. “fixed” control. You should be able to isolate areas of concern.
It sounds like they don’t want to twist or slide the original control, this is rational procedure but using a calibration is the easy way out to do this.
It should be possible to do a simple shift instead, a local city has done just that to get between the original NAD83(86) NGVD29 control their first GPS system is based on and the NAD83(2011) NAVD88 their new CORS station is based on. Trimble allows for Dx, Dy, Dz shifts. It’s a ”cleaner” solution and may well work for your situation instead of calibrating.
Do you really need 29 elevations? Hasn’t FEMA updated to 88 there yet?
A good example of why LDP’s are the best coordinate system solution. Nothing against the poster but pretty typical of the confusion I commonly see in working with grid coordinates.
The way I understand the reason that it is a calibration on the city’s control is so they don’t have to have a subscription to a virtual reference network, (TDOT) in our case. I don’t have a means of accessing a reference network like TDOT VRS, but I have worked with a base/rover set-up at my previous employer where we would set a base point with the VRS and then set our base on it and apply a SF from there, but our base is stationary and our “local” site is the city. When we would apply that SF, our TS would measure accordingly but I don’t know how I can make the two jive the way we have it set up.
Another thing is, how could I use a combined scale factor with a calibration?
As far as the errors go, we’ve seen from .5′ over about a quarter mile to around 3′ near a mile – I know that some error is inherent while using GPS control but this is far beyond tolerable. If we start on a pair and close back to the same pair, then the errors are tolerable, so we’ve pretty much eliminated it being a bad rodman or I-man.
I’m not sure why they used NGVD29 instead of NAVD88 but that should probably be looked into as well. It was done in 1990-1991. We do a conversion in the office for the datum shift.
That to me looks like a Grid to Ground error when I see 3′ in a mile.
I can chain better than 3′ in a mile, I don’t know anything about TN SPC but I’ve only seen 3′ in a mile in central Montana (600ppm).
Sounds like you have real problems.
When you say there is error inherent in GPS control,,,,,,,there really shouldn’t be much error at all, you should be chasing millimeters around horizontal, vertically I don’t know about your area, but .1′ to .15′ is common with newer geiod models.
- Posted by: bryandean8611
The way I understand the reason that it is a calibration on the city’s control is so they don’t have to have a subscription to a virtual reference network, (TDOT) in our case. I don’t have a means of accessing a reference network like TDOT VRS, but I have worked with a base/rover set-up at my previous employer where we would set a base point with the VRS and then set our base on it and apply a SF from there, but our base is stationary and our “local” site is the city. When we would apply that SF, our TS would measure accordingly but I don’t know how I can make the two jive the way we have it set up.
Another thing is, how could I use a combined scale factor with a calibration?
As far as the errors go, we’ve seen from .5′ over about a quarter mile to around 3′ near a mile – I know that some error is inherent while using GPS control but this is far beyond tolerable. If we start on a pair and close back to the same pair, then the errors are tolerable, so we’ve pretty much eliminated it being a bad rodman or I-man.
I’m not sure why they used NGVD29 instead of NAVD88 but that should probably be looked into as well. It was done in 1990-1991. We do a conversion in the office for the datum shift.
The reason given for calibrating is about the silliest thing I’ve heard but it does show that the inmates are controlling the asylum.
That said you have come to the right place for help. Let’s begin with the purpose for calibrating. Calibrating was invented because of a perceived need to be able to measure between geodetic control monuments with ground distances. You have proven how wrong this can go. Perhaps there is an embedded double whammy scaling error in it. Or it could be something else such as the control points held in the calibration don’t relate. There is a good opportunity here for some to learn and some to review. #1 if I were the person in charge the age of the base control (1990) would be my first concern and the first issue I would deal with. Not knowing any more about it than you have posted the first thing I would do is resurvey the city control network to make sure the coordinates are what they are reported to be. This can be done without a VRS. I would recommend doing four hour static sessions on 25% of the control points and use OPUS to process the data. If any problems show up in the 25% observed it would be an indication that the entire network needs to be re-observed. Once we know about base control we can go on from there. Deal?
PS- reviewing your equipment there may be an easier, faster way to check. Let your base collect static for 8 hours or more if you’d like and use OPUS to process it. Then seed those results into your base and observe 25% of the city control with RTK. Set up your rover file from the coordinate system library where you would choose TN State Plane 4100, NAD83. Observe the control 2 or three times at different times of day and average. These results will be a little less desirable than a static survey but we are looking for 3 feet in a mile here, right? DO NOT CALIBRATE this.
Clean GPS data is the way to go. If you have the old raw data, use that and check with new GPS occupations into a few control points every time you have a nearby job. If you don’t have the original raw data, start a new GPS network, even if you can only do a few points at a time. You need to see what residual errors your actual working with. Once you have done that and you still have a problem, then you know the problem is the combined ground to grid factor. You can probably take the average between what ever two points your current job is between.
Calibrations are to get the best match to old data but can make a mess if the residuals are not small. A control network should be adjusted but not calibrated, it defeats the whole purpose.
Linebender is right. Before you go calibrating to city control you need to prove up that control and find what’s acceptable and what’s not and the only way in my book to do that is to do your own survey over and through those control points. Static observations would be my go to for this using several averaged OPUS derived solutions on your base’s location for the seed coordinates. You could then do fast static and post process the rest of the observations, multiple RTK shots would be my second choice, VRS a distant third. The worst conceivable scenario I can think of is localizing to quality unknown control and then having to pull my hair out trying to figure out why nothing is fitting right. At least this way you should be able to isolate the problem control monuments and red flag them. Throw a bogus control monument into your localization and you’re pooched.
WillyThis is a very worthy discussion.
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 difference between grid and ground at NGS mark designated Kingsport at elev 1270 in downtown Kingsport is approx. 0.16′ per mile. That’s the error that should show up with a perfect total station traverse. You would apply a factor of 0.99997119 to total station ground distances to check into state plane control
The difference between grid and ground at NGS mark designated Wimbish at elev 1930 east of Kingsport is approx. 0.35′ per mile. That’s the error that should show up with a perfect total station traverse. You would apply a factor of 0.99993012 to total station ground distances to check into state plane control.
The difference between grid and ground at NGS mark designated ET 12 at elev 2400 on the hill south of Kingsport is approx. 0.55′ per mile. That’s the error that should show up with a perfect total station traverse. You would apply a factor of 0.99993012 to total station ground distances to check into state plane control.
The difference between grid and ground at NGS mark designated TS 2F at elev 1360 in the valley west of Kingsport is approx. 0.20′ per mile. That’s the error that should show up with a perfect total station traverse. You would apply a factor of 0.99995969 to total station ground distances to check into state plane control.
Analyzing this information if your state plane control coordinates are what they are reported to be if you are measuring with a total station in the valley your ground measurements will be about 0.2′ per mile long compared to grid control. In the hills about 0.45′ long per mile.
All this can be derived from NGS datasheets. If your surveys don’t agree with this the control is messed up or the calibration or both. You’re welcome.
Do you have a reason to use the city control? Unless you have a very good reason why not use real world coordinates?
- Posted by: bryandean8611
I’m not sure why they used NGVD29 instead of NAVD88 but that should probably be looked into as well. It was done in 1990-1991. We do a conversion in the office for the datum shift.
As I recall, NAVD 88 was officially adopted in (late)1991. Any work work done prior to that was NGVD29.
In addition, Experienced crews using rigorous NGS methodologies would only report NAVD 88 elevations to the nearest tenth of a foot.
Many entities over seeing small to medium geographical areas choose to stick with NGVD29. - Posted by: MightyMoe
I can chain better than 3′ in a mile, I don’t know anything about TN SPC but I’ve only seen 3′ in a mile in central Montana (600ppm).
Sounds like you have real problems.
When you say there is error inherent in GPS control,,,,,,,there really shouldn’t be much error at all, you should be chasing millimeters around horizontal, vertically I don’t know about your area, but .1′ to .15′ is common with newer geiod models.
I’m not saying there should be bogus errors in GPS, I’m just saying that a pair of GPS points are going to naturally have more error than that of two points set conventionally simply because of the way GPS coordinates are derived.
- Posted by: Lee D
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.
- Posted by: aliquot
Do you have a reason to use the city control? Unless you have a very good reason why not use real world coordinates?
Almost all of the city’s projects are tied to the city control system and have been since they introduced it. The calibration has been used with it since 2006. I don’t understand why the errors are just now showing up… or have they been in the past and never reported? I don’t know.
- Posted by: bryandean8611Posted by: Lee D
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.
Log in to reply.