The Ellipsoid Problem?

[+Renegade Knight]

WGS 84 gives Latitude and Longitude as if you were on the surface of the theoretical earth ellipsoid created at roughly mean sea level. This is by definition. The ellipsoid is a mathematical model of the earth at that elevation. LL are projected to the surface (where we geocache at) in a line originating from the center of the planet. Thus where I might stand at 4300 feet is connected by a line to the point on the ellipsoid below me at roughly 0 feet and on to the center of the earth.

 

That part is easy to understand. For the non surveyors if you draw this it’s easy to picture both the lines, and the issue that comes next. At 4300 feet the distance between two points of LL is longer than the distance between the same two points of LL on the ellipsoid. Therein is the potential problem.

 

To solve a triangulation based cache puzzle you convert to UTM do the math, and then convert back to a LL. If the UTM coordinates are on the ellipsoid rather than at the actual elevation the math is using the wrong information and can result in an error.

 

Is the UTM being used on the ellipsoid or is it at the surface? The two most likely UTM sources are as reported on the cache page, or as determined by your GPS. At what distances does this really matter? Close to mean sea level this probably doesn’t matter either, but at what elevation will it kick into play?

[+Mudfrog]

Would you repeat that!

[+Renegade Knight]

Would you repeat that!

Here is what looks like a more accurate (and complex) description of the issues.

 

I just wanted to know when it can throw off a puzzle cache that involves triangulation!

 

http://www.commlinx.com.au/Datum%20Transfo...escription.html

[+Renegade Knight]

Another one that looks like it discusses the potential problem.

 

http://w3sli.wcape.gov.za/Surveys/Mapping/wgs84.htm

[+El Diablo]

R.K, you're wrong as usual. I don't know how, because you are way above my head on this, but I'll do research and prove it... I think.

 

I said in another thread that you were smart....are you trying to prove that?

 

El Diablo

[+Renegade Knight]

...I said in another thread that you were smart....are you trying to prove that?

 

El Diablo

I'm trying to avoid actually figuring this all out by pawning off the work to someone who gets a kick out of it. Pawning off work is always smart. Unless you want to ever see a promotion...

[+Stunod]

Here's my WAG...the altitude difference is tiny compaired to the radius of the earth, therefore the horizontal difference is negligible.

[+El Diablo]

...I said in another thread that you were smart....are you trying to prove that?

 

El Diablo

I'm trying to avoid actually figuring this all out by pawning off the work to someone who gets a kick out of it. Pawning off work is always smart. Unless you want to ever see a promotion...

You scared me there for a minute. I actually thought you knew something I didn't.

 

Post on.

 

El Diablo

[+CYBret]

Batman's a scientist.

[+cachew nut]

I just wanted to know when it can throw off a puzzle cache that involves triangulation!

Never. But here is a real triangulation problem.

Edited July 31, 2004 by cachew nut

[+Renegade Knight]

Here's my WAG...the altitude difference is tiny compaired to the radius of the earth, therefore the horizontal difference is negligible.

When I did a quick calc. there was about 21,000,000 feet to the center of the earth making that 4300' pretty small.

 

However when a surveyor does the calc to go from the ellypsoid to State Plane coordinates the adjustment is also horizontal. NAD 27 can be 300' off WGS84 for the "same" coordiante.

 

It UTM has a similar conversion there could be a problem.

 

What brought all this up was a surveyor stopped in my office today and said they had converted LL to State Plan (ellipsoid to geoid) then used a quick conversaion in the program they were using to LL again. They they used the LL in a handheld GPS to find points they had set earlier and found they were 40' off instead of the 20' they were expecting. When they figured out the ellypsoid thing and adjusted they were within the 20'.

 

State Plan is a coordiante system like UTM but it's not UTM so maybe the issue isn't as bad like you suggest or maybe it's worse?

[+ke6n]

I just wanted to know when it can throw off a puzzle cache that involves triangulation!

Never. But here is a real triangulation problem.

Ich bin traurig, aber ich lese nicht oder spreche Deutschen.

[+LordSaw]

I just wanted to know when it can throw off a puzzle cache that involves triangulation!

 

Unless you're planning a multi stage puzzle cache on a mountain side, with very LONG legs between stages, I don't think the altitude differences between the stages will affect the problem. Your altitude of 4300 feet above sealevel is 0.0204 % of the radius of the earth. I really don't see this will affecting the problem enough to impact the significant figures on the GPSr.

 

Cache Well

[+Criminal]

Well, to me it sounds more like a dilemma than a problem.

[+ke6n]

I think it all depends on the puzzle. If the puzzle is something where you, the cache hider, already know the LL, then engineering the puzzle to produce the LL desired shouldn't make it a problem at all, right?

[+EraSeek]

Ok, most of this is over my head but I love to learn, so here goes:

 

Datums points are expressed in two ways, Horizontal, and in Verticle. Thus I assume maps take this into account. If I recall correctly, and I'll check, Benchmarks express how high above or below the ellipsoide or geoide it is. (sorry if I'm wrong in stating this before I check.)

 

For GPS units, read the last lines here:

"elevation models of the earth are published every few years.

These are tables of the elevation "above-the-WGS-84-ellipsoid" sea level

would be, if sea water could flow to anywhere on the earth. (It's

interesting that even at the coasts, this "elevation-model" table doesn't

exactly agree with actual mean sea level due to the prevaling winds piling

up (or lowering) the water.)

 

Elevation-model tables are stored in some GPS units (Garmin for one) in

order to display true elevation. The amount of the difference in your

elevation above the WGS-84 ellipsoid and your actual elevation at your

loaction is shown in the last item of NMEA sentence $GPGGA and is about

30m in Atlanta."

 

As to UTM, What I've read is that the datum "Touches" at the centeral meridian, and is projected traveling outward.

 

So I guess, with my limited knowledge here, I would say there shouldn't be a noticeable problem.

 

Teach us, all you surveyor people out there!

[+El Diablo]

Ok, most of this is over my head but I love to learn, so here goes:

 

Datums points are expressed in two ways, Horizontal, and in Verticle. Thus I assume maps take this into account. If I recall correctly, and I'll check, Benchmarks express how high above or below the ellipsoide or geoide it is. (sorry if I'm wrong in stating this before I check.)

 

For GPS units, read the last lines here:

"elevation models of the earth are published every few years.

These are tables of the elevation "above-the-WGS-84-ellipsoid" sea level

would be, if sea water could flow to anywhere on the earth. (It's

interesting that even at the coasts, this "elevation-model" table doesn't

exactly agree with actual mean sea level due to the prevaling winds piling

up (or lowering) the water.)

 

Elevation-model tables are stored in some GPS units (Garmin for one) in

order to display true elevation. The amount of the difference in your

elevation above the WGS-84 ellipsoid and your actual elevation at your

loaction is shown in the last item of NMEA sentence $GPGGA and is about

30m in Atlanta."

 

As to UTM, What I've read is that the datum "Touches" at the centeral meridian, and is projected traveling outward.

 

So I guess, with my limited knowledge here, I would say there shouldn't be a noticeable problem.

 

Teach us, all you surveyor people out there!

Good lord...it's catching.

 

El Diablo

[+EraSeek]

Ok, so here is an actuall page:

DESIGNATION - KAG

TR1140 PID - TR1140

TR1140 STATE/COUNTY- WA/SKAGIT

TR1140 USGS QUAD - UTSALADY (1968)

TR1140

TR1140 *CURRENT SURVEY CONTROL

TR1140 ___________________________________________________________________

TR1140* NAD 83(1991)- 48 21 36.90896(N) 122 29 54.43601(W) ADJUSTED

TR1140* NAVD 88 - 3. (meters) 10. (feet) SCALED

TR1140 ___________________________________________________________________

TR1140 LAPLACE CORR- -0.80 (seconds) DEFLEC99

TR1140 GEOID HEIGHT- -22.27 (meters) GEOID99

 

So My understanding is that maps take actual elevation into account and relate distances between 2 points fairly accurately. GPS's also use the modeling to discribe actual elevation and the distances between 2 points fairly accurately. The problem may come with UTM, where the central meridian is correct, BUT outwardly accuracy is lost.

 

How'd I do?

[+Robespierre]

It's 11:30, so I'm gonna sleep on it. Oh, and tomorrow, I'm going canoeing. Then there's church on Sunday...with any luck, someone else will solve it by then.

[Venona]

However when a surveyor does the calc to go from the ellypsoid to State Plane coordinates the adjustment is also horizontal. NAD 27 can be 300' off WGS84 for the "same" coordiante.

 

It UTM has a similar conversion there could be a problem.?

UTM is not datum. UTM is calculated using datum. UTM coordinates calculated using WGS-84 is just another way of expressing coordinates. So is no problem for puzzle caches.

[Mushtang]

Batman's a scientist.

IT'S NOT BATMAN!

[+Robespierre]

OK, gotta leave for canoeing, but I slept on it. Without getting out the calculator and checking the diameter of the earth, for now, we project that at 5,000 feet the difference will not be a serious problem.

[+Team Spike]

Well, not really an answer but a suggestion from a geocaching viewpoint when doing puzzle caches. So far I've only hidden one cache that required trig to solve and this is what I did.

 

1. I first found a cache location and got my measured coords of it.

 

2. I then created a puzzle and solved it myself (I assumed no information other than what I would give to people on the cache page).

 

3. I would only hide the cache if it could be solved so that you get out the exact coords I measured. Therefore the error when the puzzle is solved is exactly the same as my GPS measurement error. If it was not possible to get out the same coords then I wouldn't have hidden it.

 

Simple as that.

 

Regarding RK's problem - I think it all depends on what accuracy you need (is 40ft good enough or do you need 0.1cm accuracy?), how far away the other known points being used are are, and what elevation those points are at relative to the point you are trying to locate.

 

Groover

[MOCKBA]

At 4300 feet the distance between two points of LL is longer than the distance between the same two points of LL on the ellipsoid. Therein is the potential problem.

 

To solve a triangulation based cache puzzle you convert to UTM do the math, and then convert back to a LL. If the UTM coordinates are on the ellipsoid rather than at the actual elevation the math is using the wrong information and can result in an error.

 

Is the UTM being used on the ellipsoid or is it at the surface?

Nice question.

Sounds like you've been pondering this cache of mine, huh?

As far as I can tell, Universal Transverse Mercator is a map projection. I.e. the actual shape of the bumpy skin of our planet is projected onto a series of flat sheets of paper, which together form a "zone". Within the zone, you can attach one sheet to another, and the junction of the sheets will always have a perfect match of features on either side. To achieve this, all the bumpiness of the actual Earth surface is essentially squished.

The flat-sheet xy coords are the UTM values, but the z coord is expressed on the map not with respect to the "flat sheet", but with respect to the underlying NAD27 elipsoid.

You are correct that the distances between higher-elevation points would be typically slightly underestimated in an UTM representation (for a 10,000 ft elevation, the error will be on the order of 1/20th of 1%). But this fades in comparison to distortions in the center or the corners of a UTM zone (i.e. where the difference between elipsoid and flat sheet, which you can visualize as an "elevation" of the flat surface, is the greatest). Your best-fit flat surface would have negative elevations down in the center of a zone, but it would stick out quite a bit at certain position on the edges.

The regular UTM zones are 6 degrees "wide" and 8 degrees "tall", which means that you plane of projection may be tens of thousands feet above or below the elipsoid, with the relative distance distortions of up to a quarter of one percent. (Think 1-cos(4degrees)). So any effect of altitude generally fades in comparison to this.

Which still leaves UTM pretty good for artillerists (who originally commissioned the system), or for triangulation over a few miles of Earth surface. If you want to be extremely precise (e.g. measuring annual growth of the mountains), or if you want to cover greater distances (e.g. launching ballistic missiles), then the UTM is not sufficiently precise for you.

[Pipanella]

[+TEAM 360]

Hey, man, I thought all I had to do in this game was follow the arrow on the little screen...

 

You one of them government workers or something?

[+Robespierre]

You are correct that the distances between higher-elevation points would be typically slightly underestimated in an UTM representation (for a 10,000 ft elevation, the error will be on the order of 1/20th of 1%).

Man, I got back from canoeing a little bit late!