@ OleManRiver
I'm not sure about private messaging on this new website. Thanks for the info. I'm using this job as a model for similar jobs in the future.
I think the second example of grid vs ground should be 677.905' for the grid distance.
The ground to grid formula is Grid Scale x Height Scale x Ground Distance=Grid Distance; or Combined Scale x Ground Distance=Grid Distance.
In Florida near Sea Level it's quite possible that the Height Scale will vary between 1.00000something and 0.99999something. That depends on if the ellipsoid is below your feet or above your head. No doubt the height factor is only a tiny contribution to the final number.
You're working at about 120 PPM; the height factor is probably around 5-10PPM.
Your angular closure of 6" implies that the "error" is all distance as Norman has indicated.
Comparing apples to oranges is not good practice, you need to develop the terrestrial survey coordinates as grid or the GPS as ground before adjusting. However, that being said a compass rule adjustment using grid or ground distances will probably result in the same coordinates because it will automatically shrink the ground distances proportionally for each course. Still not a great idea.
Question about this:
GPS102-GPS101 Grid distance: 629.431′
GPS102-GPS101 Ground distance: 629.515′
GPS107-GPS108 Grid distance: 677.985′
GPS107-GPS108 Ground distance: 677.981′
To get these values, did you collect the GPS points and start with them in the collector based on just exactly what was collected via NRTK and have your data collector set for grid<->ground.
Then run your traverse by setting up on GPS102 with the total station while holding the NRTK GPS coordinates of 102, backsight GPS101 zero out and hold the NRTK GPS azimuth between the two points and shoot GPS101 as a stored point with the total station.
Traverse through and then occupy 107 holding the total station derived coordinates and shoot 108 with the total station and store another coordinate value based on traversing for 108?
Then inverse between GPS coordinates and inverse between total station collected coordinates to report the distances you provided.
Another whole lot of IFs -
If that was the process, I would expect that the difference in distance between GPS102-GPS101 is indicative of the error in the GPS observations at 101 and 102. It appears you lucked out and got better than should even be expected NRTK GPS positions for 107 and 108 but 101 and 102 are not as good. Can you go back and observe 101 and 102 with your NRTK again? I would be suspicious that 102 is as much as 0.08' out from the GPS coordinates you have now.
You may have been starting with as much as 0.08' of linear error due to a bad NRTK position on point 102. If that is the case, you might reduce your linear error to about 0.137' with a better position on 102 and the closure would be more in line with 1'/24,000'.
If any of the preceding assumptions about your process of working with the coordinates is correct, then that is a great example of the potential problems with holding the NRTK positions fixed for your solution. Any error in those positions becomes an error your are 'correcting' total station work to match - even if the total station work was very good. This would include error in positioning at 107 and 108 which seem to match the total station distance well, but may have provided compensating error to hit the 6" angular closure, which I was a little surprised to see as that is much better than I expected with holding a NRTK azimuth at each end and running a 5" total station 3300 feet.
Don't know if anyone has wrote this yet but adjusting two tenths out of a traverse based on RTK observed control is a fools game if that's what is occurring here. I had a party chief once who wanted to spend days chasing his tail around a project using RTK observations. He'd still be measuring if we let him. It's bass ackwards to use a higher precision measuring device or method to run traverse than was used to establish control.
@ Norm
I appreciate your input, but this is our standard way of doing things. My coworker and I are trying to institute new methods of doing things. How do you suggest we setup a traverse and what methods do you suggest? The project consists of locating property corners on both sides of a road and locating all above ground utilities, sidewalks, and pavement. Locate everything from right-of-way to right-of-way. Elevations will be used when appropriate. No natural ground shots, swales, or centerline of road.
If you PM me I can walk you through setting up to perform all the correct comps. First you need to get the data on the same system. That’s where scaling ground distance to grid first. Then you will know your true closure. Then the adjustment can be done. It’s not hard. You can google compass rule and get that part figured out for sure. Plenty of YouTube and text book documentation out there.
What you need is appropriate field and office software that work together seamlessly and a set of processes and procedures. While your current method can work its unfortunately very inefficient and potentially inaccurate. Too many non centralized components (GPS, conventional, scale factor) for my comfort zone.
We do this type of work on a daily basis and never have the issues you're describing. I'm not trying to criticize you as I understand you can only work with what you have to work with but whomever is in charge of the overall processes and procedures and hardware and software should seriously hear your issues and make changes that will allow for downstream efficiency and consistency.
"How do you suggest we setup a traverse and what methods do you suggest?"
I do this sort of thing almost daily using StarNet to simultaneously adjust the RTK vectors and the terrestrial traverses. Handles all the scaling and grid calcs. There are other Least Squares packages (including SurvNet, which is included in Carlson Survey) which can also do the job.
This is a very good point. StarNet survnet. Getting everything on the Same page. Like items. Rtk is less precise but if everything is weighted correctly and all items are on the same system grid or ground then you can achieve the best of both worlds. I still think this small traverse is a good one to compute long hand as that can get some very good understanding before pushing the buttons on software.
@ OleManRiver
How do you PM someone on this website? I need this weekend to sort out all of this information presented to me.
@ Jon Payne
To get these values, did you collect the GPS points and start with them in the collector based on just exactly what was collected via NRTK and have your data collector set for grid<->ground.
Yes, but the data collector was not set for grid<->ground. We never use grid<->ground.
Then run your traverse by setting up on GPS102 with the total station while holding the NRTK GPS coordinates of 102, backsight GPS101 zero out and hold the NRTK GPS azimuth between the two points and shoot GPS101 as a stored point with the total station.
Yes. Except I didn't shoot and store GPS101 using a different point number. Look at the first line of the raw data below.
Traverse through and then occupy 107 holding the total station derived coordinates and shoot 108 with the total station and store another coordinate value based on traversing for 108?
Yes. The other coordinate value for GPS108 is C108.
Then inverse between GPS coordinates and inverse between total station collected coordinates to report the distances you provided.
Yes.
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
GPS102(TRAV_PT) to GPS101(TRAV_PT):
HD: 629.431 Az: 181°39'17"
dN: -629.168 dE: -18.177
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
GPS107(TRAV_PT) to GPS108(TRAV_PT):
HD: 677.985 Az: 356°06'30"
dN: 676.422 dE: -46.014
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
C107(COGO) to C108(COGO):
HD: 677.981 Az: 356°06'24"
dN: 676.416 dE: -46.033
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Edited raw data:
BD,OPC102,FPC101,AR0.00000,ZE90.00010,SD629.5150,--5/8 IRC O_C_ TRAV PT
FD,OPC102,FPC103,AR269.49010,ZE90.00410,SD593.6000,--5/8 IRC O_C_ TRAV PT
FD,OPC103,FPC104,AR174.12360,ZE90.05050,SD590.5550,--5/8 IRC O_C_ TRAV PT
FD,OPC104,FPC105,AR194.31360,ZE89.50030,SD148.5250,--N+D JWG LB 1
FD,OPC105,FPC106,AR87.42270,ZE90.30340,SD150.2150,--5/8 IRC O_C_ TRAV PT
FD,OPC106,FPC107,AR171.43390,ZE89.50420,SD547.6150,--5/8 IRC O_C_ TRAV PT
FD,OPC107,FPC108,AR176.27480,ZE90.11240,SD677.9850,--5/8 IRC O_C_ TRAV PT
Pretty much how the others have responded. We spent more time then I'd like to admit on instituting methods to use RTK observations and repeated observations for control for total station work on projects with similar scope as yours. While it is possible most of the time by averaging there are outliers that will cause a person to question the results of the methods while making assumptions and choices that infringe on the borders of professionalism. The time we spent simply showed us that post processed static on project control is just as timely and cost effective and the residuals are more in line with what control survey expectations are. Then when disagreements in measurements pop up one isn't left asking is it the control or the traverse?
@ Jon Payne
If that was the process, I would expect that the difference in distance between GPS102-GPS101 is indicative of the error in the GPS observations at 101 and 102. It appears you lucked out and got better than should even be expected NRTK GPS positions for 107 and 108 but 101 and 102 are not as good. Can you go back and observe 101 and 102 with your NRTK again? I would be suspicious that 102 is as much as 0.08′ out from the GPS coordinates you have now.
GPS101 and GPS102 have open sky to the east but have some large oak trees to the west. Maybe that's why their positions aren't as good as GPS107 and GPS 108. We might be able to observe GPS101 and GPS102 again.
If any of the preceding assumptions about your process of working with the coordinates is correct, then that is a great example of the potential problems with holding the NRTK positions fixed for your solution. Any error in those positions becomes an error your are ‘correcting’ total station work to match – even if the total station work was very good. This would include error in positioning at 107 and 108 which seem to match the total station distance well, but may have provided compensating error to hit the 6″ angular closure, which I was a little surprised to see as that is much better than I expected with holding a NRTK azimuth at each end and running a 5″ total station 3300 feet.
I want to observe these points again using fast static.
Sorry just seeing this. Was out doing a favor for a friend on a rural site hardly no cell. I checked and saw we are connected so at the top right side of this forum is an icon for mail you can PM through that. I have not looked at the numbers here. But my gut said that once you scale the ground distance to grid your closure will be much better. Since it seems that most of the error is in this direction on your closure. Now it could go the opposite way as I don’t know if you are long or short distance wise and have no idea which cardinal direction this traverse is run in. Also you have a 90 degree turn if I remember correctly so with RTK or NRTK especially you have to look at the big picture to truly determine what’s going on. This is why many who truly understand RTK error and the precision of a total station understand that Least Squares is your best option in determining the closest truth to reality. So I also have no idea where you are in a Transverse Mercator or Lambert. As mentioned above. There is a scale factor for each point in a lambert this changes at the latitude. Then you have and elevation/ellipsoid factor this deals with a scale for your height. So depending on the height above or below the ellipsoid at or with any two points this will effect along with your scale or sometimes called grid factor. These terms you need to study on. Scale goes from ellipsoid to grid and grid to ellipsoid distance. Combined factor we have butchered the definition. If you see this on a NGS data sheet you will see the scale elevation and then combined factor and can check your math for any given point. The combined factor for a point is in the context of ground to grid. Not grid to ground. I have witnessed so many using this incorrecty as we all use the term grid to ground. If we want the grid to go to ground we need the inverse of this on a HP it’s 1/X. On a route survey as mentioned above having a pair at one end and a pair at the other end from NRTK or RTK is a crap shoot. On getting them to close. Especially when the procedure is to do a compass rule. I would prefer static or a fast static. Here on east coast RTK is King as they just want to be on datum and some still battle this issue on linear traverses as a lot still the majority of the time set 2 points with NRTK and run a loop. But they try that on a linear and crews get fussed at and budgets get blown re running a traverse that doesn’t close or they think it doesn’t close as a little error in one set of points to a closure on another end with another set of points.
Here is an example of a situation I was tasked with solving the problem. Which was not a problem. Two 4000 foot linear traverses that crossed each other. Both starting and ending on NRTK pairs in both directions. One closed within a minimum standard the other a little shy of the requirements. The common point in the middle yes you guessed it was not matching hardly at all from two independent compass rule adjustments. Traverse ran twice on both. Still couldn’t be solved. I simply looked at everything on the almighty google showed me areas on both lines where good open skies were. I Simply called crew had them locate those several points and the original points again so redundant measurements. They had also ran levels. I had them turn some rounds at the intersection points to close those crossing lines that were left independent except for one common point. I had also identified a blunder on one line for mean angle sets . Took the CORS station s that surrounded us that were in NGS and looked at the time tables along with the uncertainty and allowed that plus the base line lengths to allow a little float in the NRTK points. The weighting. Performed a least squares with all data. Except for the one blunder the traverse was good. Understanding uncertainty error in the tools and procedures used with any set of tools is most of the battle. Shape is another. Because of money budgets and directives from higher than my pay grade rtk was a tool we needed to use for control. I developed some procedures that was finally excepted that proved to eliminate the re running of traverses so often in the linear lines. But that had to be done using least squares. Least squares does not fix bad data. It just allows for the best possible fit of all tools used together with a confidence to meet a project requirements. You can have two points that you occupy on one end that were set with NRTK or RTK that you shoot the distance to your BS that are flat no error and also on other end but there azimuth could be off so a traverse closure could bust. From one end to another azimuth wise could blow the error budget. Angular wise.
