Ground to Grid

Two Dimensions

because that is all there is in the grid coordinate system. That Z dimension is in a different system.

Paul in PA

Two Dimensions

Thank you, Paul. The "elevation factor" had me confused...Have a great day!

Paul got it. Think of it like this. When working in SPC with elevations, you're actually using two datums. The first being (for nearly everyone but Loyal :-)), NAD83 (CORS96) Epoch 2002.0 or the new realization of NAD83, and NAVD88 (or NGVD29 depending on the specs). Each one must stand on it's own. The elevation factor is just another component of the Combined Scale Factor (GF*EF=CSF)

Two Dimensions

The elevation factor is used to change the distance of a "horizontal" line at your working elevation to or frome the distance at the ellipse. the "z" factor above the ellipsoid is used to get the proportional difference based on a huge triangle. The angles of the 'triangle' don't change so that, based on similar triangles, the proportional difference in length from the "center" of the earth to the ellipsoid and from the "center" of the earth to the ground height above the ellipsoid is the same proportional value between the horizontal points difference.

(Okay, it is an assumed center of the earth which is close enough. It isn't exactly a triangle, becuase you first convert from "Grid" to "ellipsoid" with the grid-scale factor, making it a 'curved" line along the ellipsoid. But the similar triangle theory and the proportional difference is all I am pointing out.

Anyway, I am just trying to point out the use of the "elevation factor". I hope that made sense.

Ground to Grid distances

And remember the point, that's been made many times before, that, strictly speaking, you should only scale distances (not absolute coords) by a SF -- especially important if your ground coords look like (in same same ball park as) grid coords.

That stuff always confused the hell out of me when I first became an i-man. Not wanting to be just a button-pushing-field-monkey, on a bad weather day, I got my boss to sit down and 'splain it to me. I "got it" after about 30 minutes. For some reason I just couldn't get my brain around it at first. Then we got into a discussion about SPC and scale factors. There went another can of worms for my hungry brain.

Ironically a couple years later I wrote a program for none other than LarryP to process LiDAR data. It was all SPC - I think NAD83 - which I was familiar with. Larry asks could I also work out an option to convert all those SPC points to true lat-lons. Not having a clue about the math behind it I asked for some more technical detail. He sent me the North Carolina manual on their coordinate system (NC was our state) developed by the NCGS headed up by Gary Thompson. I found the math I needed. It took me a few hours to absorb it. I also found a minor typo error in the formulae. I forget what language I wrote the program in at the time (probably Visual Basic version 6) but it took about 2 days to get it right. I have since re-written that same thing in 2 other languages - JavaScirpt and C#.net. Thank God I was also a math major and not just computer science and physics.
Ok. I'm reminecsing (sp?) now. Sorry.

Ground to Grid distances

> And remember the point, that's been made many times before, that, strictly speaking, you should only scale distances (not absolute coords) by a SF -- especially important if your ground coords look like (in same same ball park as) grid coords.

Excellent point. We had this very discussion at work last week. Someone in our office was trying to use a Scale Factor to reduce their coords to Grid. No No...

Use a Combined Factor for coordinates only and use a Scale Factor for distances or the old "rubber stamp" function in CAD.

I personally never liked Combined SCALE Factor. I think it confuses the majority with Scale Factor. I've stuck with just Combined Factor and Scale Factor to differentiate.

Ground to Grid distances

Thanks to all for the posts. Back in the office.

Rob, I'm not sure I understand that fine point.

As an example, let's say I ran a GPS session at a point, and used OPUS to process the results, and was able to obtain the following results for the observed point. The grid coordinates in this case would be 873871.675 meters (Northing), and 45390.239 meters (Easting). In order to convert to U.S. Survey Feet, these values would be multiplied by 3.28083333333, resulting in 2867027.32 u.s. feet (Northing) and 148917.81 u.s. feet (Easting).

Just to make sure that I am completely understanding your point, if the goal was to project the grid coordinates to ground coordinates, the next step would be to multiply the grid coordinates by the reciprocal of the "Combined Factor" = 1/0.99993834 = 1.00006166. And, your point was to be sure NOT to use, conversely, the "Point Scale"?

And, that if the goal was to go the other way, i.e. from ground to grid, the method would be to multiply the x and y ground coordinates by the Combined Factor?

Would there be any technical reason why using the CAD command "SCALE" would not produce the desired effect, as long as the Combined Factor was used? I understand that the origin of the scaling would effect the location of the final coordinates, and if done incorrectly might require a translation. I also understand that using a uniform Combined Factor for the entire site will produce distortion. But, if the scaling (of multiple points) is done about the correct origin (0,0?), it seems to me that the distances between all the points would be correct.

Al

---------------------------------------------

REF FRAME: NAD_83(CORS96)(EPOCH:2002.0000) ITRF00 (EPOCH:2011.8153)

X: 1356510.538(m) 0.019(m) 1356509.754(m) 0.019(m)
Y: -4541424.895(m) 0.009(m) -4541423.471(m) 0.009(m)
Z: 4253971.197(m) 0.025(m) 4253971.126(m) 0.025(m)

LAT: 42 6 0.03609 0.024(m) 42 6 0.06891 0.024(m)
E LON: 286 37 50.64208 0.018(m) 286 37 50.62712 0.018(m)
W LON: 73 22 9.35792 0.018(m) 73 22 9.37288 0.018(m)
EL HGT: 176.901(m) 0.012(m) 175.674(m) 0.012(m)
ORTHO HGT: 206.928(m) 0.023(m) [NAVD88 (Computed using GEOID09)]

UTM COORDINATES STATE PLANE COORDINATES
UTM (Zone 18) SPC (2001 MA M)
Northing (Y) [meters] 4662167.012 873871.675
Easting (X) [meters] 634843.701 45390.239
Convergence [degrees] 1.09345199 -1.25563963
Point Scale 0.99982373 0.99996609
Combined Factor 0.99979599 0.99993834

Ground to Grid distances

Big Al,

I think the idea here is to use the grid coordinates in your data collector, and then use the scale factor to correct the distances that you shoot to be on the ground.

I sometimes have a hard time wrapping my head around this subject as well.

Thanks for bringing this up. I am watching this thread to learn something myself.

Good luck.

Jimmy

Ground to Grid...my 2 bits

GPS (Static or RTK) both “measure” ON THE GROUND and the returned vectors (dX,dY,dZ) are also “ON (or along) THE GROUND” (mark-mark-Static, L1pc-L1pc-RTK). At least as a general rule, that's how most software does it.

The Data Collector (and office software) ONLY move this [surface] data somewhere else (UP or DOWN to the grid), because you TELL it to.

In MOST cases, a well defined Low Distortion Projection (LDP) allows you to STAY ON (or very near) the ground, thus making this whole “grid-ground” thingy irrelevant (again, in most cases). You are still transforming the Surface distance UP or DOWN to a developed GRID surface, it's just NOT so dang FAR (up or down)!

If your project (or area of interest) has the following TOTAL relief (lowest elevation to highest elevation), then a properly defined LDP will return “grid-ground” COMBINED Factors of ABOUT:

200 vertical feet = +/-05ppm = 0.03 ft. per mile
400 vertical feet = +/-10ppm = 0.05 ft. per mile
600 vertical feet = +/-15ppm = 0.08 ft. per mile
800 vertical feet = +/-20ppm = 0.10 ft. per mile

That can give you a pretty good sized sandbox to play in (except of course in the Mountains, where it isn't so big), wherein the Grid-Ground issue, ISN'T an issue at all. Your mileage will of course vay.

🙂
Loyal

Ground to Grid...my 2 bits

I totally have to agree. Everything or most everthing we do is put on SPC. Sometime's I hate to do it. That being said all corners are labeled with SPC.

Ground to Grid...my 2 bits

A minor correction to BigE's post. The elevation factor is most correctly computed from the ellipsoid height which is defined in NAD 83, not the NAVD 88 orthometric height. While the difference is typically small, it is the correct why to perform the reduction.

Ground to Grid...my 2 bits

> That being said all corners are labeled with SPC.

There's a local county around here that has taken to wanting SPC coordinates on all land survey plats.

Of course, most areas around here use ground distances on the land survey plats. So we've seen all kinds of bizarre recorded plats, most of which are wrong, because the so-called "state plane coordinates" inverse the same as the ground distances. And this is at 4000+ feet of elevation, so that's obviously ridiculous. And of course, there's often no metadata provided on the plats, describing how they came up with their so-called "state plane coordinates". They merely put numbers on the plat and called them "state plane coordinates" so they could get through the approval process. And the reviewers merely looked for "state plane coordinates" on the prints, without really noticing the inconsistencies. The funniest part is that they also often want ties to the nearest section corner, so we see ties to something 3000 feet away, all with something called "state plane coordinates", and all of which inverse to ground distances. It's insane.

Naturally, the whole drive behind it is that the county has a relatively well-developed GIS department, so they want everything in SPC. So they require "state plane coordinates" on everything, without fully reconciling that with the fact that everything is platted with ground distances.

But then there's also one local municipality (in the same county) that was actually PLATTED in State Plane, with grid distances on the plats, and there's all kinds of SPC's all over them. But the town was platted in the 1960's. So naturally, they are NAD27 State Plane Coordinates, while everyone else is using NAD83 State Plane.

The whole thing ends up creating a huge comedy of errors. Every project seems to bring new wrinkles into the picture. Some of them are even funny, but most of them are just exasperating.