Reading RPLS is free for the whole profession. Members post, reply, and get the members-only rooms.
I started my own business 1.5 years ago after 30 years of working for others. As part of that, I purchased a GNSS base/rover system (Carlson Brx7) and I have really been putting it to great use. I recently even got brave enough to use it for boundary surveying (after reading many comments about how to properly do that on this website) and I have been very pleased with the results. With the redundancy I strictly adhere to, I am getting least-squares solutions with less than 0.05' to 0.07' error semi-ellipses. So thank you to everyone who encourages GNSS use for boundary surveying (when appropriate), and for the advice on how this work should correctly be performed to achieve repeatable results. I want to stress that the observations on the corners are only a part of the overall boundary survey; the boundary lines still need to be physically observed between the corners, and any evidence that may affect the results of the survey must be noted, measured and reported.
I completed a boundary survey in the past few weeks using GNSS with great results even though most of the corners were in wooded areas (although no foliage yet). Since part of my task was to divide the tract into two parcels, I needed to set a new corner marker along the line furthest from vehicle access, about a 1000-foot walk. Since I didn't have a conventional traverse to start from, it would have taken at least a few hours to traverse through the woods, check in to existing corner markers with known coordinates, then stake the new corner marker in the line.
So I opted for the GNSS base/rover to accomplish this task. Here is where I would like an honest evaluation of my thought process. I walked to the two corner markers at each end of the line I wanted to set the new corner marker in, and staked to them with resulting errors roughly around 0.02 feet or less from the original coordinates. This was based on using the setting in the data collector to scale from grid to ground, since my boundary survey (and corner coordinates) were ground, not grid. Satisfied that I had a reasonable fixed solution that checked, I proceeded to set the new marker. I could not think of a way to show repeatability with that except to reset the RTK engine and let it fix again, and check the result. Does that sound reasonable? What else should I have done?
My main question is, I created a ground coordinate for the new marker based on my survey scaled to ground. After thinking about it, I think my data collector would have scaled that thinking it was a grid coordinate, so it would have not staked the correct ground coordinate. Am I thinking correctly on that? Fortunately in this case I was very near the unity meridian so there was virtually no difference between ground and grid, so I didn't worry about it too much. But I want to get it right in the future.
Unless someone has a better method, I think in the future I will scale any critical staking points to grid, then use the setting in the data collector to scale them from grid to ground. It is either that, or turn off the "scale grid-to-ground" setting and let the DC think my ground coordinates are grid coordinates. Thoughts?
Bud
As far as checking a staked out item, yes, I think resetting the rover is about as good as you're gonna get. The best would be to go back the next day or go back multiple days and check but I think that's not realistic for most projects.
As far as scaling stuff in the middle of the project I'm not sure what kind of can of worms you would open doing that. My workflow is to tie everything in grid and then scale all of the data to ground and then calculate whatever points I need to set. Maybe someone who has done it the way you described can chime in.
I don't realize any benefit from working in grid. I always work in a ground coordinate system. Only on the odd occasion is anything converted to grid, typically at the request of the client to satisfy some regulatory agency. Why work in grid? What is the benefit?
I think in most cases for most stake-out, the grid factor isn't going to be a problem. For example, in laying out Construction Limits, who cares? But if I need to get a corner marker set exactly in a line between two existing irons, if the grid factor is significant the iron may not be placed as well as it could be, depending on what technique is used. I realize this is a bit of a nit-pick, because if I come across an iron in the middle of a 600 foot line when surveying existing markers, am I really going to be that concerned if it is a tenth off line? Probably not. But naturally the anal perfectionist in me doesn't want anyone else to discover that kind of "error" in a marker I set myself.
In most cases the grid factor is not going to make a significant difference when the distance from the scale point and the point to be staked are less than, say, 500 feet. But I just wanted to think this through for the occasional situation that might arise, where I need to stake a point 1000 feet from the scale point and the grid factor is significant.
@bstrand I also work at ground and not at grid. When I finish my adjustment for the GNSS data, I scale it to ground and then start mapping. But when I have an iron that I need to set after I'm finished mapping, the coordinate I pick off of the map will be a ground coordinate. If I stake that using the base/rover and use the scale-to-ground setting, I feel like that would not give me the correct result because it would apply the grid factor inverse to the vector. I feel like the correct procedure would be to either scale the point to be staked from ground to grid, then stake it using the field software's scale-to-ground setting, OR don't scale the point and stake it as if it were a point on grid in the field (i.e. leave the scale-to-ground setting off).
The simplest solution would be to just stake it with the scale-to-ground setting off, in my mind, rather than mess with the coordinates of the point (scale down to grid). But I have to remember what I've done so I can turn back on (or off, depending) the scale-to-ground setting for other work I may be doing.
Why work in grid? What is the benefit?
First off, if you have a low distortion projection working in grid is pretty seamless. No scaling BS is necessary.
As for your question, if your work is strictly boundaries for landowners, each one remote from all the others, then there isn't much to be gained from using grid. This, it seems to me, is a needlessly tough way to make a living. If you hope to work with developers you are going to want to deliver product in a coordinate system that is compatible with the GIS. Maybe that's not your cup of tea. If you want to develop a body of work within an area, a common coordinate system is going to come in handy.
@norman-oklahoma It has been 30 years and there hasn't been an instance of regret of working in ground coordinates. 30% of the work being done for developers. Any time State Plane coordinates were desired, it has always been much easier to convert to them instead of working in them. Do you actually do design work for developers in State Plane and deliver in State Plane? State Plane is a nice system for cataloging projects. Beyond that, they cause more trouble and confusion for those that don't quite understand the flaws of projections, especially engineers and sadly some surveyors.
Granted working on ground is also a projection but the distortion in a limited project area is meaningless. The same is not true for State Plane at an elevation above 5000'.
Basically it comes down to what is the error budget for the project. We generally see 200-400PPM using a state coordinate system. That is probably much larger than other areas experience, but at elevation there is always 200PPM baked into the calculations. Some areas get over 800PPM which means .8' every 1000' and that of course is intolerable. DOT wants 10ppm as a maximum so they restrict surface calculations to 10 miles in flat ground. They use the procedure of multiplying the state coordinate number by a project scale factor thus creating a surface coordinate and inversing gives a surface distance. If the state coordinate system is within the error budget then I would use it. There shouldn't be a reason to chase small PPM errors for most tasks. However, working with GPS means you should always know what that error is.
Do you actually do design work for developers in State Plane and deliver in State Plane?
No. I deliver in the Oregon Coordinate Reference System - a low distortion projection.
I keep everything in State Plane but I'm in a generally low and flat area. Statewide LiDAR is on SPCs, as our ortho panels and all tax maps. I've seen major and expensive blunders from folks scaling from State Plane to Ground but not abridging or altering the coordinates to make it clear that it's not on SPCs. What I'd gain from having slightly more accurate distances, I'd lose from having to T&R orthos and everything else or add more complexity with a second set of coordinates.
I'll hopefully live to see man walk on Mars and maybe humanity will begin there and on the moon. At some point in the not so distant future, land surveyors will need to consider the value of fixing parcels and features to Earth's center and not tectonic plates. When looking as far into the future as I do into the past, I see less value in ground measurements than in grid.
I would do the same if I lived where state plane was "close".
I almost never give out coordinates, except for DOT and some rare construction projects. All my boundaries are fixed to State Plane by my scale factor and ties to known points. But those known points get filed with Lat, Long numbers the epoch and a scale for the distances, but I don't show XY, That way anyone following can use them to get any coordinates they wish to place on them. Still, the most important thing for boundaries and construction is the monumentation.
Grid and ground produce great discussions. I have nothing to offer on how to survey, but I do have some insight into coordinate systems, so take this for what it’s worth to you.
State plane projections are nothing more than full-sized maps and they contain all of the distortions that maps contain. In NC, the state road map is the NC state plane reduced to a manageable size. The overall average scale is 1 inch to 11 miles, but that’s an average, not a constant.
Back to state plane proper, let’s do a sample calculation at altitude and then discuss it. We’ll use the runway at Telluride Regional Airport which has an elevation of something over 9,000 feet.
The primary data source is here: Validated UDDF Files . Search for Telluride and use the 2015 data. Look for Runway 9 and you’ll find lat and lon for its beginning along with elevation and ellipsoid height. Scroll down to runway 27, which is the end of Runway 9. Airport runways are numbered with the truncated heading for approach, so opposite ends differ by 18 (180 degrees). Both ends show the length of the runway to be 7111 feet.
Entering these lat/lon into NCAT will give state plane coordinates and scale and combined factors for the two ends of the runway.
Inversing between these two points gives the length of the runway to be 7107.6 feet and we see the difference between grid distance and ground distance, 3 to 4 feet in this case.
But why would anybody expect grid to match ground? Grid is a flat map, a flat model, of a curved surface, one that’s also lumpy. Matching just can’t happen in general.
State Plane systems include scale factors and elevation factors to adjust these flat distances to lumpy curved distances. The average of the combined factors at the ends of this line is 0.999517355 and when we divide 7107.6 by 0.999517355, we get 7111.03.
Runway lengths are slope distances so we have to adjust for the 31.4-foot difference in height at the runway ends. Doing that gives us 7111.1 feet. The published distance could be anywhere from 7110.5 to 7111.5, but it’s a very good bet that it’s actually very close to 7111.1
Now we could have divided both sets of coordinates by the average combined factor and gotten the exact same result. But if we used an average combined factor based on airport-wide scale and elevation factors, we would have a different result, one likely very close, but different, nonetheless.
With LDPs, each point still has a unique scale factor and a unique elevation factor. There is a difference between distances calculated from LDP coordinates left unadjusted and those calculated by adjusting by individual combined factors. The LDP is designed to make such differences remain within a defined tolerance deemed acceptable and that obviously works very well. It doesn’t have to be perfect, just close enough.
Modern surveying software in data collectors will calculate unique scale and elevation factors along with northings and eastings for each point when set up to do so. It will use those to individually adjust each distance from grid to ground with far more accuracy than an LDP or a single combined factor with no additional human effort.
I often wonder why we don’t just do that and eliminate all of the confusion.
On the other hand, folks who want a true ground-based system should love the PLSS. One of the problems that come with that, though, are the “jogs” in roadways, like the one described here: Finally, why do roads jog at some intersections? - Anderson, Eckstein & Westrick, Inc.
There just isn't a perfect way, or, at least, one remains to be discovered.
There was a push to make boundary lat, long based, more like the GLO.
It was mid to late 1990's and I used that program, but, like many other surveying processes it doesn't work. Not because it doesn't work well and is fairly simple with GPS, but because the program didn't become the standard.
Putting the results into Autocat would frustrate planners, designers, ect.
You can even neglect "true" north and use a grid bearing married with real ground distances but the same thing happens. They won't close in Autocat. This of course depends on sites with fairly large elevation changes or larger parcels. I can today of course do a plat with geodetic north bearings, ground horizontal distances, all of it but it won't meet "standards" because it won't "close". Can all users be re-trained to use that type of mapping? Doubtful!!!! But then I've always been a skeptic.
As an aside the new system may well become a s#itshow. A sliding coordinate system might become a very difficult system for many users.
Wasn't the problem CAD's insistence on mathematical perfection? We still have that conflict but use least squares to satisfy CAD and existing monuments, however mathematically flawed, to satisfy courts.
Isn't the issue now understanding the output we're getting?
The question of whether someone adjusted grid to ground once, twice, or not at all keeps coming up. It seems to this layman that letting the machines use grid as it was designed to be used might resolve that problem.
Yep, everything I GPS is in grid. All the GPS data is stored in a separate folder and then files are copied out and pasted into a different software in a totally different folder for further processing and adjustment. I always have the original grid data for reference including the raw file.
I have run across many discussion threads about grid vs. ground, and I didn't intend for this topic to turn into another one. Great input but not addressing my primary question.
In summary, I performed a boundary survey using GNSS, adjusted using least squares and achieving acceptable relative positional accuracy. After the boundary was complete, I needed to set a new corner marker in an existing 800 foot line, and the point needing to be set was 1000 feet from any vehicular access, meaning that it would be much less trouble to stake the corner marker using GNSS than to carry in the conventional equipment, verify the existing corner markers at each end of the line in question, and traverse to set the new corner. In the past I would have had a nearby (adjusted) traverse loop from which I could set the new marker. Essentially I am asking, if you need to stake out a critical point as accurately as you can using a GNSS system (base/rover), do you have a particular method to accurately place the point (in my case a new corner marker in an existing line), if the data is at ground, not grid?
Am I wrong in thinking that there are essentially two ways to attack this:
1. Scale the point to be staked to grid, and stake the point using a grid-to-ground correction in the field.
2. Use the ground coordinate for the point, but do NOT use grid-to-ground correction in the field (i.e. the data collector treats the coordinate as a grid coordinate).
These methods assume there is at least a small necessary correction to scale from grid to ground. If the grid factor is approaching unity and the distance from the scale point to the staked point is not too crazy then there is probably more error hammering the iron into the ground than there is with an ignored or improperly used grid factor. On the other hand, if the grid factor is somewhere in the range of 0.9998, then a 1000-foot distance from scale point to staked point will have a difference between grid distance and ground distance of 0.2 feet or so. If I'm trying to place an iron in an existing line, what do I do to compensate for this large difference, to ensure that the iron is truly in the existing line to the best of my ability?
I'm just throwing this out there as a discussion point. Unless someone screams otherwise, I will likely use one of the methods I mentioned above. As with other tasks where I have begun using GNSS in place of conventional equipment, I intend to experiment with this to determine that these methods will or will not produce repeatable results that are satisfactory. But if someone has already walked through this exercise, I'd appreciate the feedback.
Bud
Essentially I am asking, if you need to stake out a critical point as accurately as you can using a GNSS system (base/rover), do you have a particular method to accurately place the point (in my case a new corner marker in an existing line), if the data is at ground, not grid?
Yes. I work on ground. All of the coordinates I'm using for the job are ground coordinates. All of the property corners are ground positions. I can calc a coordinate for the point on line and stake it out and set it and it will be where I intended. I could also stake to a line and if I wanted to be 800.33 feet from one end of that line then I would set the point on line at station 800.33. There would be no confusion wondering if the coordinate of the point to be set is being scaled correctly. Everything is at ground. There is no confusion related to scaling from the grid or to the grid.
If using Trimble Access set No Projection No Datum for your RTK job. Input an approximate elevation for the area you will be working in and you now will be collecting data or staking points that reflect ground distances.
Trimble offers a line staking program, set the two endpoints assign one as 0+00 then station stake along that line. It takes 10 seconds to set up. It's irrelevant if it's on a State Coordinate System or a Surface Coordinate System. It seems you're hung up on the idea of "grid", all XY projections available with modern GPS systems are grid, there are an infinite number of XY grid projections for any lat. long. set of coordinates.
@mightymoe That's a great point. I use the Carlson SurvPC line-staking routine all the time, should have thought of that.
For the airport the error is 483PPM. This means an error in distances of .48' in 1000 feet. Another way to visualize it would be the surface you're surveying to is roughly 10,100 feet below the ground (these are head calcs). Think of it, you're actually shoving the coordinate pairs that deep, just so it's easy to punch a button on a box.
