Here's the given: ran an open (link) traverse about 2500 feet in length with a total station. I came off two GPS points and closed on the final two GPS points. I had a field misclosure of 0.350 feet. Took the data back to the office, downloaded the field data, applied a scale factor in the software, and the final closure was 0.007 feet, when everything is reduced to the grid. Problem: when working with anything related to a boundary, the distances must be ground. Possible solutions: in this case, hold the final two GPS points with the final ground coordinates, since I know the traverse is good on the grid. I really don't want to survey this project with a total station using a scale factor, since I would be working on the grid. I usually do everything on the ground. But if a consultant gets a hold of my data, and uses his RTK or virtual system, he needs the scale factor.
What do you all do in a similar situation?
What do you all do in a similar situation?
If it's a boundary I'd put it on ground coordinates unless the contract specifies otherwise. I'd leave enough monuments behind to allow facile retracement, and let any downstream consultants decide how they need to proceed.
whh114, post: 356856, member: 6199 wrote: Here's the given: ran an open (link) traverse about 2500 feet in length with a total station. I came off two GPS points and closed on the final two GPS points. I had a field misclosure of 0.350 feet. Took the data back to the office, downloaded the field data, applied a scale factor in the software, and the final closure was 0.007 feet, when everything is reduced to the grid. Problem: when working with anything related to a boundary, the distances must be ground. Possible solutions: in this case, hold the final two GPS points with the final ground coordinates, since I know the traverse is good on the grid. I really don't want to survey this project with a total station using a scale factor, since I would be working on the grid. I usually do everything on the ground. But if a consultant gets a hold of my data, and uses his RTK or virtual system, he needs the scale factor.
What do you all do in a similar situation?
You did not say what your factor is that you used, I am assuming it is something like 0.99986. What I have done is to divide the grid coordinates (all points including the GPS points) by the combined grid factor to bring the points up to ground. You can then load these into your data collector and use for your boundary work, any point can be reduced back to grid by applying the combined grid factor to the ground coordinates. Using this method, the ground coordinates are nowhere near the grid coordinates (in my area it is approximately 300 feet different). It is easy enough to reduce all points to grid before you give them to a consultant or just give them the information to do it. I have see the ground coordinates reduced by say 100,000 so they don't appear to be grid coordinates.
Friends don't let friends scale grid coordinates without truncating.
John Putnam, post: 356861, member: 1188 wrote: Friends don't let friends scale grid coordinates without truncating.
I see no problem with holding one point as true SPC and scaling from this point without adding an offset as long as you clearly state on the plat what you did.
I'll ask my USUAL (semi-rhetorical) question...
If "the grid" (which I assume is SPC or UTM) doesn't work for you, then WHY did you enter "it" into your project and create this issue in the first place?
The ONLY reason I can envision (based on your post), would be IF the BOUNDARY in question, is based on SPC/UTM Bearings (in the entitlement documents).
:-S
Loyal
What's wrong with working in SPC on a job that's 2500' long? Why go to scale 1.0? Everyone around here works in scale 1.0 and reports SPC that are close enough. I'm the weird one attempting to properly work in SPC and just report what I did. It is nice when I can take my VRS out and check control within a few hundredths.
exbert, post: 356880, member: 6143 wrote: What's wrong with working in SPC on a job that's 2500' long? Why go to scale 1.0? Everyone around here works in scale 1.0 and reports SPC that are close enough. I'm the weird one attempting to properly work in SPC and just report what I did. It is nice when I can take my VRS out and check control within a few hundredths.
Well obviously whh114 ain't in one of those areas where SPC "fits" the ground so closely!
If your VRS ONLY WORKS in SPC (for you), then you aren't using it to its full capabilities (or don't understand its operation).
o.O
Loyal
What does that even mean? I'm not disagreeing with you. I'm just trying to get an education. How do I get my VRS to work properly with ground traverse? I have tons of respect for you in this arena.
Don't get me wrong exbert, I'm NOT saying that SPC/UTM coordinates don't have their place (they DO).
Nor was I trying to pick on you either.
My point is simply that too many folks assume that GPS = SPC, and use the term "THE Grid" as if there were only ONE GRID!
I have a client (a Survey Firm) that uses the Utah VRS (TURNGPS it think it's called), and it works very well IF you can get cellphone coverage (which is a bit of a crapshoot). We worked together on a large(ish) retracement a couple of years ago (about 18 Sections with elevations ranging from about 6500 to just over 10,000 feet).
We had been using BASE-ROVER RTK and Static Control expressed in a LDP suited to the project. When they got their VRS "rover" we simply entered the Low Distortion Projection parameters into their data collector, and away we went. Everything that we checked into fit well within the expected variances (RTK/Static/VRS), and everybody was happy (except when we got into Cell dead spots, and had no base to listen to).
I used a [custom] Single Parallel just last year to duplicate a SPC Grid Bearing/Ground Distance project for another client. Simply punch in the projection definition (parameters), check a few points to verify the system, and go to work.
I think it's great that some folks work in areas where the SPC "grid" fits the ground reasonably well, but there aren't of those areas in my neck of the woods. Virtually ALL of our boundaries were Originally defined as "True Bearing, Ground Distance," so it makes sense to stick with that system. Obviously ANY projected grid system can't do that perfectly, but you can keep the convergence angle and SCALE under [reasonable] control on most projects.
I HAVE filed a few "Record of Surveys" over the years that ACTUALLY were expressed in "True Bearing/Ground Distance," but that creates its own problems for many folks ("they" don't close in the cogo programs).
There is no Silver Bullet, and one size NEVER fits all!
🙁
Loyal
I have tried to figure out the very best flow chart for this.
For now, my Javad units do this:
I go to field, on new job.
Take an autonomous lat lon, and use it for the day. I then select a point on the job, and arbitrarily assign it 50000 50000.
Then, I tell the LS to give me either an average scale for a number of points, or a point of average elev. And central to the job.
I am now on close spc, for my underlying coords. And, I am on ground, local, for the coords I export into the laptop. They are usually on state plane grid brngs. Although, I can use any brg system I like. Page 0 is spc. Page 1 is my local ground system @ 104 ppm. (whatever scale factor I choose).
Now, I upload to laptop, calc my survey, send New coords into the LS, on page 1. I now set corners, pack up, and go home. After GPS midnight, I plug the LS into the internet, via a LAN wire. Usually, within 3 to 4 minutes, I get my dpos back. (dpos is the Javad version of Opus).
It now prompts me, adjust coods Y/N?
Tell it yes, and all the underlying coords shift, and the relationship to the local coords, changes, but the local coords remain the same.
Now, I can go to page 0, and everything, both design, and field observations are all on pure spc. I can go to page 1, and everything is back on local.I can now set page 2, to be on another SPC. And page 3 can be still on ANOTHER local system. Go work on that, all is available, and addressed as though the whole job is on that system.
Now, go back, and page 0 is still on the original SPC system.
I can move my base station wherever I want, and address any page, of the previous work.
I'm still figuring out ways to use it, and thinking about how to make it work for me, but there is a lot here.
Nate The Surveyor, post: 356891, member: 291 wrote: I have tried to figure out the very best flow chart for this.
For now, my Javad units do this:
I go to field, on new job.
Take an autonomous lat lon, and use it for the day. I then select a point on the job, and arbitrarily assign it 50000 50000.
Then, I tell the LS to give me either an average scale for a number of points, or a point of average elev. And central to the job.
I am now on close spc, for my underlying coords. And, I am on ground, local, for the coords I export into the laptop. They are usually on state plane grid brngs. Although, I can use any brg system I like. Page 0 is spc. Page 1 is my local ground system @ 104 ppm. (whatever scale factor I choose).
Now, I upload to laptop, calc my survey, send New coords into the LS, on page 1. I now set corners, pack up, and go home. After GPS midnight, I plug the LS into the internet, via a LAN wire. Usually, within 3 to 4 minutes, I get my dpos back. (dpos is the Javad version of Opus).
It now prompts me, adjust coods Y/N?
Tell it yes, and all the underlying coords shift, and the relationship to the local coords, changes, but the local coords remain the same.
Now, I can go to page 0, and everything, both design, and field observations are all on pure spc. I can go to page 1, and everything is back on local.I can now set page 2, to be on another SPC. And page 3 can be still on ANOTHER local system. Go work on that, all is available, and addressed as though the whole job is on that system.
Now, go back, and page 0 is still on the original SPC system.
I can move my base station wherever I want, and address any page, of the previous work.
I'm still figuring out ways to use it, and thinking about how to make it work for me, but there is a lot here.
You are doing what most have done for quite a while Nate.
Starting a survey autonomous then later shifting to "correct" NAD83 positions.
The one thing that gives me pause is that your field NEZ's don't move with the change in NAD83.
Your Page one NEZ have to be created by some kind of projection that Javad is doing.
That being said they should shift with the new NAD83 positions after your dpos calculation.
Instead it sounds like JAVAD holds the coordinates and shifts the projection somehow.
I would want to know how Javad is projecting the local coordiante and why it isn't shifting, also I would want to know if it is backwards doing a calibration to hold those autonomous numbers. XY is one thing, but I would sure want my Z to shift and be tied to a GEOID, even for boundary.
Maybe I misreading it, maybe your local NEZ's do shift.
I would also like to determine my local parameters for page one before heading to the field, print out the metadata for it and put it into the file then it's loaded into the dc when you set the base up and it doesn't change ever through the project.
MightyMoe, post: 356924, member: 700 wrote: You are doing what most have done for quite a while Nate.
Starting a survey autonomous then later shifting to "correct" NAD83 positions.The one thing that gives me pause is that your field NEZ's don't move with the change in NAD83.
Your Page one NEZ have to be created by some kind of projection that Javad is doing.
That being said they should shift with the new NAD83 positions after your dpos calculation.
Instead it sounds like JAVAD holds the coordinates and shifts the projection somehow.I would want to know how Javad is projecting the local coordiante and why it isn't shifting, also I would want to know if it is backwards doing a calibration to hold those autonomous numbers. XY is one thing, but I would sure want my Z to shift and be tied to a GEOID, even for boundary.
Maybe I misreading it, maybe your local NEZ's do shift.
I would also like to determine my local parameters for page one before heading to the field, print out the metadata for it and put it into the file then it's loaded into the dc when you set the base up and it doesn't change ever through the project.
The underlying geodetic positions of the localized points are created when localized to the page1 points, then when processed thru DPOS, the underlying geodetic positions of the local points shift, but the Local coords do not change, so point 50000 50000 is still 50000 50000 after processing.
Adam, post: 356927, member: 8900 wrote: The underlying geodetic positions of the localized points are created when localized to the page1 points, then when processed thru DPOS, the underlying geodetic positions of the local points shift, but the Local coords do not change, so point 50000 50000 is still 50000 50000 after processing.
This means the XY is projected to the auto number.
Then the geodetic number is shifted but the XY stays the same with a new lat and long and of course some kinda new projection,,,,,,,,,,,,,,and Z stays the same?
WOW!!!
I would really not like any of that.............
I would HAVE to know how that all happened, I sure wouldn't just let it do it.
Moe, Shawn can explain the details better than I. The NAD SPC values will shift if it is a true state plane system or close to a SPC sytem. The unknown coordinate system (local points like a deed or old traverse) these coordinates dont change.
I am Curious Moe, why would you want local point 50000 and 50000 to shift a few feet after the processing?
Here's a link Moe, pages 222-227 and 242 - 259, There is a new manual coming out soon so it is a little dated.
http://www.javad.com/downloads/javadgnss/manuals/hardware/Triumph-LS-Users-Guide.pdf
exbert, post: 356885, member: 6143 wrote: What does that even mean? I'm not disagreeing with you. I'm just trying to get an education. How do I get my VRS to work properly with ground traverse? I have tons of respect for you in this arena.
I in the past have set and held one point as True SPC's and set this point as the scale point, calculate the combined factor and go to work. Setting up the total station up on the points, the backsights check wonderfully, I can go anywhere on a 100 or 200 acre project and check right on with the total station with no problems. I think working completely on SPC works best for large projects consuming a lot of area and long distances. I have been trying to determine which suits my workflow, crew, and what the client needs. But there seems to be a smoothness and consistency of working on True SPC'S all the time.
Adam, post: 356932, member: 8900 wrote: Moe, Shawn can explain the details better than I. The NAD SPC values will shift if it is a true state plane system or close to a SPC sytem. The unknown coordinate system (local points like a deed or old traverse) these coordinates dont change.
I am Curious Moe, why would you want local point 50000 and 50000 to shift a few feet after the processing?
The reason is because I want to know WHAT my coordinates are.
I don't care if they are 5000, 5000 on a point or 500000, 500000, it doesn't really matter.
What is important is that I know how they are generated, and I want to be in control of it.
When you leave the office you know where you are going, you know the lat and long, you know the elevation.
So take a minute and imput into your office computer the parameters of the job, pick a lat and long near, look at the elevations and design an LPD for the project with a scale factor that gets you to the surface. Now you have metadata for the project, sitck it in the file, you now know just what your local coordinates are doing, put that into the dc, use them for the page one.
These coordinates will shift as will the elevations when OPUS or CORS are applied to the values, but the question to ask is why is THAT a problem?
Why do the values 50000, 50000 on some random control point tump everything else, including a well designed LDP?
You are saying you aren't sure what JAVAD is doing to the numbers, that is not a good position to be in, heck even if Freeman Dyson is available to calculate mine, I wouldn't want him to.
The next job is a mile to the east, you imput this projection into the data collector for it and you have automatically connected local systems, you don't have to go to SPC coordinates and back them in to connect them.
But using the system described you will create two local coordinates, near to each other, both with the holy grail number of 50000, 50000 on two random control points, and both systems without metadata.
A rigorous example of a classic State Plane solution for a link traverse can be found here.
http://www.xyht.com/professional-surveyor-archives/3088/
While it doesn't address the original question of what to report, it does address some of the later comments.
An LDP approach to the same problem, using the same data, can be found here.
http://www.xyht.com/surveying/pennsylvania-traverse-low-distortion-projection/
Both solutions are geodetically sound and neither uses arbitrary coordinate systems with undefined parameters nor unknown limits to their useful range nor angular measurement questions. It's hard to imagine an equipment manufacturer that would not support both methods mathematically in a clean workflow format.
Dr. Ghilani, in a later article on LDPs, discourages designing an LDP for a specific project. But, given the number of ad hoc coordinate systems created and used every day, it would seem to me that replacing them with geodetically correct systems would be a superior way to go.
Coordinate systems are purely mathematical concepts and constructs. It's amazing how robust arbitrary ones can be, but basing them on sound principles pays big dividends in accuracy and repeatability.
Moe, you are correct to wonder. What I said above is true. It's the Javad LS wonder.
Maybe sometime I come demo it for you.
The LS changes the underlying quasi spc, to true spc. And changes the relationship to those local coords, so they remain the same.
It's cool.
And it will give you solid GPS positions, in places that no other unit can.
N
