Here is the math from Grid to Ground.
Grid Distance / CSF = Ground Distance
1689.2966 / 0.99996429 = 1689.3569
Kris Morgan, post: 387845, member: 29 wrote: No!!!!! If you want to output surface distances, do that at the convenience of your desktop. Do NOT molest your coordinates. Run uncorrected in the field if you like, then correct the raw data at the office and evaluate. There are no such things as ground coordinates. This will be bad ju-ju. Get on the grid, and stay on the grid. If you don't like the scales, build a LDP so you can work it. Otherwise, don't mix and match these. It will bite you in the butt eventually.
Really?
These ARE GROUND coordinates!
REF FRAME: NAD_83(2011)(EPOCH:2010.0000) IGS08 (EPOCH:2016.3604)
X: -1774098.626(m) 0.005(m) -1774099.496(m) 0.005(m)
Y: -4513980.402(m) 0.012(m) -4513979.116(m) 0.012(m)
Z: 4131481.893(m) 0.005(m) 4131481.807(m) 0.005(m)
LAT: 40 36 55.89760 0.005(m) 40 36 55.91402 0.005(m)
E LON: 248 32 38.49436 0.003(m) 248 32 38.43992 0.003(m)
W LON: 111 27 21.50564 0.003(m) 111 27 21.56008 0.003(m)
EL HGT: 2112.740(m) 0.013(m) 2112.017(m) 0.013(m)
ORTHO HGT: 2128.252(m) 0.027(m) [NAVD88 (Computed using GEOID12B)]
These are NOT!
UTM COORDINATES STATE PLANE COORDINATES
UTM (Zone 12) SPC (4302 UT C)
Northing (Y) [meters] 4496178.262 2253376.469
Easting (X) [meters] 461429.876 503725.562
Convergence [degrees] -0.29683345 0.02820225
Point Scale 0.99961831 0.99999161
Combined Factor 0.99928713 0.99966030
😎
Loyal
leegreen, post: 387935, member: 2332 wrote: The data you have shown from SurvCE is what what I expected. The "HDist" is your Grid distance, while the "Ground HDist" is what you'd get with the EDM. Most often the ground will be larger than the grid distances in your area do to elevation and location from the central merdian.
YES - When SurvCE writes an .rw5, it ALWAYS output ground distances, regardless of settings within the DC.
Answer is A - When Star Carlson/Star*net takes that .rw5 in, and you set the Project to use Grid (VT83 or whatever), does it:
a) Expect Grid coordinates?,
b) Expect Ground coordinates?, and, if the latter,
Does it convert them during the adjustment?
Lee:
My bad. I asked the wrong question.
Does Star*net expect grid DISTANCES? I don't really care about the coordinates coming IN to Star*net. The only important thing are the observations.
But coming in to Star Carlson, if SurvCE always outputs ground distances, then that must be what Star Carlson expects and turns into M records.
I'm beginning to think that understanding geoids, geodetics and the rest of the theory is easier than understanding what these programs are doing with the data.
StarNet will be looking for ground distances from your EDM or Steel Tape, as it is nearly impossible to measure along a grid distance, it is computed.
Remember your earth science class when you peeled an orange, then tried to lay it flat on the table. This is the simplest form of converting ground to grid. Mapping is done on a flat plane, yet the world is round. This why we calc from ground to grid. If your project is less than a mile, then no need for this at all.
Loyal, post: 387939, member: 228 wrote: Really?
These ARE GROUND coordinates!
REF FRAME: NAD_83(2011)(EPOCH:2010.0000) IGS08 (EPOCH:2016.3604)
X: -1774098.626(m) 0.005(m) -1774099.496(m) 0.005(m)
Y: -4513980.402(m) 0.012(m) -4513979.116(m) 0.012(m)
Z: 4131481.893(m) 0.005(m) 4131481.807(m) 0.005(m)
LAT: 40 36 55.89760 0.005(m) 40 36 55.91402 0.005(m)
E LON: 248 32 38.49436 0.003(m) 248 32 38.43992 0.003(m)
W LON: 111 27 21.50564 0.003(m) 111 27 21.56008 0.003(m)
EL HGT: 2112.740(m) 0.013(m) 2112.017(m) 0.013(m)
ORTHO HGT: 2128.252(m) 0.027(m) [NAVD88 (Computed using GEOID12B)]These are NOT!
UTM COORDINATES STATE PLANE COORDINATES
UTM (Zone 12) SPC (4302 UT C)
Northing (Y) [meters] 4496178.262 2253376.469
Easting (X) [meters] 461429.876 503725.562
Convergence [degrees] -0.29683345 0.02820225
Point Scale 0.99961831 0.99999161
Combined Factor 0.99928713 0.99966030😎
Loyal
Yeah, but most don't survey with LLH or ECEF. 🙂 Don't molest the grid coordinates. 🙂
leegreen, post: 387930, member: 2332 wrote: Adam is incorrect.
If you have grid coordinates, then with a scale factor of 1.0000 you get grid distances. You apply the combined scale factor to a distance, not to coordinates.
But if you take the project off grid, back to assumed coordinates, then use 1.0000 scale factor and all the distances will be referenced to ground. Most boundary surveys are performed at an assumed coordinate system with no scale factor, using only ground distances.
In Survce if one is doing gps work and sets the projection and sets the scale at one they will get SPC and grid distances, just like you say Lee. In Survce doing total station work with the projection system set and a scale of one the user will not Get SPC or grid distances they will get ground distances and ground coordinates.
Kris Morgan, post: 387967, member: 29 wrote: Yeah, but most don't survey with LLH or ECEF. 🙂 Don't molest the grid coordinates. 🙂
Well in the case of GPS (all flavors) we actually DO, there is just a lot going on behind the curtain.
Just like a Total Station (or Transit & Chain), we "measure" ON the Surface (ground), but calculate down (or up in some cases) to "the GRID" (whatever "grid" you may be using).
Loyal
you are on the grid when you survey on the ground
leegreen, post: 387930, member: 2332 wrote: Adam is incorrect.
If you have grid coordinates, then with a scale factor of 1.0000 you get grid distances. You apply the combined scale factor to a distance, not to coordinates.
But if you take the project off grid, back to assumed coordinates, then use 1.0000 scale factor and all the distances will be referenced to ground. Most boundary surveys are performed at an assumed coordinate system with no scale factor, using only ground distances.
Lee is right, I overlooked the fact that you exported grid coordinates from starnet. It all depends on knowing what you have when you import and export.
Kris Morgan, post: 387845, member: 29 wrote: No!!!!! If you want to output surface distances, do that at the convenience of your desktop. Do NOT molest your coordinates. Run uncorrected in the field if you like, then correct the raw data at the office and evaluate. There are no such things as ground coordinates. This will be bad ju-ju. Get on the grid, and stay on the grid. If you don't like the scales, build a LDP so you can work it. Otherwise, don't mix and match these. It will bite you in the butt eventually.
A year or so ago I swapped from trying to keep up with all the scaling and what coords are what to working completely in SPC in the field and office. Carlson scales my distances to ground for plats. Much simpler by far.
I realize I'm up to about 1328 questions by now, so thank you all for the help, but...to sum up:
If I understand both Lee's and Adam's concurrence correctly and if I am:
1. Using SurvCE ONLY with a total station;
2. Don't care about COGO on the DC
3. Have Starnet set to SPC (VT83), and output adjusted coordinates (not "ground" coordinates) back into the DC...
Then I can ignore the Scale factor in the Localization screen in SurvCE (I.e. leave it at 1.0000000), go back and forth like this until the cows come home, adding additional points to my network, adjusting, then outputting a new control file to SurvCE, and my survey will be:reflecting
grid bearings and coordinates and ground distances.
Is that correct?
Adam, post: 386852, member: 8900 wrote: Once you set the projection in Equipment/Localizion/system. Then tap TS and tap Auto scale to grid. This will compute grid coordinates in the collector. A side note SurvCE Raw data will be stored ground distances no matter what projection or scaling you use.
I still haven't figured out what to do with the scale factor in the TS screen.
Here's what the manual says:
"All distance measurements taken by a total station will be multiplied by the scale factor".
This seems to contradict what you say about "Raw data will be stored ground distances..."
Is that scale factor to be used only for viewing grid distances on the DC?
rfc, post: 388468, member: 8882 wrote: I still haven't figured out what to do with the scale factor in the TS screen.
Here's what the manual says:
"All distance measurements taken by a total station will be multiplied by the scale factor".
This seems to contradict what you say about "Raw data will be stored ground distances..."Is that scale factor to be used only for viewing grid distances on the DC?
"All distance measurements taken by a total station will be multiplied by the scale factor". (to compute coordinates based on distances using that scale)
This seems to contradict what you say about "Raw data will be stored ground distances..."(this is true)
RFC, the raw data stores the distances from the total station or tape. It rights the raw data then when a factor is applied it will list the factor in the raw file as a note. The coordinates created in SurvCE are based on that scale. You are right, the scale is basically for cogo and coordinates. The scale doesnt change the raw data. Set the scale to some big number, then record a shot and look at the raw file and then do a inverse.
Since I don't use the software discussed, I am not following the arguments very well. I worked with a Carlson full civil suite in recent years but not long enough to get familiar with it. I worked for a State agency briefly as a result of desperation brought on by the recession & a divorce but they demanded much & paid little so that experience was short lived. I generally turn to NGS & our State Geodetic Survey for guidance on geodetic matters. I met Mr. Carlson in person. He is a very knowledgeable gentleman & his software is equally powerful. I didn't work with it long enough to master it & I don't believe it suits my needs.
Excuse me for being simplistic as I am probably preaching to the choir but it seems an amazing number of people that think they are experts don't understand the difference between ground coordinates & grid coordinates. I don't hold myself out as an expert as I consider myself a student when it comes to geodetic surveying but I was referencing boundary surveys to geodetic control long before GPS as we know it today existed or any of the software that is in common use. What most folks in the surveying business, in my experience, think of as ground coordinates are measurements taken with a total station without regard to corrections for the curvature of the earth or the mapping angle. I believe NGS calls that a "rectilinear survey". A GPS receiver of course, is most often referenced to a grid but it can be latitude & longitude. To quote NGS, "--- they are not the same, you can't hammer fit GPS coordinates to a rectilinear survey". You can, of course, come up with a pretty decent approximation. A grid is an approximation to begin with. Most of my clients want to build something or plant something. They want to see their property line on the ground. The value of referencing survey control to a geodetic frame is obvious & apparent. Most of my work involves boundary surveying & so called, "forensic surveys". I usually show the rectilinear data on the plat but reference it to State Plane Coordinates. That keeps errors well within the precision required by State law for all but a few surveys. A rectilinear survey will fall apart sooner or later as the distances increase. Since vegetation (not to mention water) severely limits the number of good GPS sites where I generally work, I do as Mr. Jan Van Sickle suggests in his book, "GPS for Land Surveyors", & combine the two. NGS has a lot of free stuff on the net. I am also looking at open source software and a different operating system such as Linux. I am getting weary of trying to compute things on a system designed for social networking & games. As the old saw has it, "anything that does everything, doesn't do anything well!"
I am amazed that we still insist on arguing about our tools. It's as if we have box end, open end and offset crows foot camps and each thinks they are the chit.
The longer you survey, the greater the range of problems you are exposed to. That means you need a big tool box with a variety of options. The longer we keep the 'my way is better' mentality, the more fractured and debilitated the Profession becomes.
Most of the time I work in Grid files. Sometimes it's a custom or LDP. I even have one project on a (gasp) localization. They all work for the intended purpose...
thebionicman, post: 398648, member: 8136 wrote: I am amazed that we still insist on arguing about our tools. It's as if we have box end, open end and offset crows foot camps and each thinks they are the chit.
The longer you survey, the greater the range of problems you are exposed to. That means you need a big tool box with a variety of options. The longer we keep the 'my way is better' mentality, the more fractured and debilitated the Profession becomes.
Most of the time I work in Grid files. Sometimes it's a custom or LDP. I even have one project on a (gasp) localization. They all work for the intended purpose...
I am really not sure what you mean by your statement. If it is in part in regard to what I said, I am not criticizing anyone's choice of tools. I will admit that I've about had it with 'Microsoft'. I don't like monopolies. I am not a computer GURU or an expert on GPS. However, I programed my first computer in the 1960's in a engineering university before most of our computer Grus were born & before Microsoft was created as well as before the internet came along. That being said, Alexander the Great was 16 when he took over his father's army. What I do say is knowledge of what we are doing should never be replaced by software. I also like diversity of opinions. Without diversity of opinions to start us thinking about what we are doing wrong, we are not inclined to see our errors. The "Scientific American" magazine says that lack of diversity is the cause of much of the faulty, one sided views in today's politics & it is not limited to politics. One author speaks of those that have a degree but no education. I welcome the views of those that disagree. As for tools, that is at least in part determined by the job but beware of a fix that is not accompanied by a sound knowledge of the principles involved. I don't claim to be the professor, I am still, at least in part, a student.
GEOMETRIC, post: 398671, member: 8346 wrote: I am really not sure what you mean by your statement. If it is in part in regard to what I said, I am not criticizing anyone's choice of tools. I will admit that I've about had it with 'Microsoft'. I don't like monopolies. I am not a computer GURU or an expert on GPS. However, I programed my first computer in the 1960's in a engineering university before most of our computer Grus were born & before Microsoft was created as well as before the internet came along. That being said, Alexander the Great was 16 when he took over his father's army. What I do say is knowledge of what we are doing should never be replaced by software. I also like diversity of opinions. Without diversity of opinions to start us thinking about what we are doing wrong, we are not inclined to see our errors. The "Scientific American" magazine says that lack of diversity is the cause of much of the faulty, one sided views in today's politics & it is not limited to politics. One author speaks of those that have a degree but no education. I welcome the views of those that disagree. As for tools, that is at least in part determined by the job but beware of a fix that is not accompanied by a sound knowledge of the principles involved. I don't claim to be the professor, I am still, at least in part, a student.
My statement was in no way directed at you. Look over the thread (or any other on the subject) and you will see how emphatic people get that there is only one correct way to relate grid and ground. My point was that is rarely true..
Thank you for clearing that up. I get misunderstood a lot. I couldn't agree with you more. The head engineer at the State agency where I worked briefly (I'm self employed) tried to tell me my Trimble robot was out of calibration because the distance measured between the same two points using GPS (several thousand feet apart) varied about a foot or more. He had no clue about the grid factor. A trip to the calibration range put that notion to bed. Another fact that is often overlooked is that the distance between two points as measured with GPS & properly adjusted as applicable is as good as it gets. At least that is what the professors tell us. However, that does not guarantee the quality of the coordinates, which can still contain substantial error.
9
If your project is less than a mile, then no need for this at all.
Most of our projects are less than a mile in length. In a typical scenario we set two control points using RTK, occupy those control points and start locating property corners along a right-of-way. In most cases the total station distance differs by 0.10' between control points. Our control points are usually two hundred to five hundred feet apart. Since we're so flat here in central Florida, I assume that difference in distance is due to poor RTK positioning. Is that a logical assumption?
The biggest takeaway from this thread is that there are many ways to screw this up.
I don't like running with a scale factor other than 1 in my DC, so I do what Kris says not to do: export a ground-scale coordinate file from Star*Net and load those into the DC for staking. The actual coordinates don't matter to me unless I'm trying to set a particular SPC value -- which I don't believe I've ever had to do -- so I'm not concerned about anyone mistaking the ground coordinates for grid. To me they're all relative values, and scale factor doesn't figure into the mix.
BTW, I find grid-ground conversions so easy to mess up that I have the forumulas (grid=ground*CF, ground=grid/CF) posted in large type on a bulletin board above my desk. I refer to them often.
