views:

870

answers:

3

I've implemented this method in Javascript and I'm roughly 2.5% out and I'd like to understand why.

My input data is an array of points represented as latitude, longitude and the height above the WGS84 ellipsoid. These points are taken from data collected from a wrist-mounted GPS device during a marathon race.

My algorithm was to convert each point to cartesian geocentric co-ordinates and then compute the Euclidean distance (c.f Pythagoras). Cartesian geocentric is also known as Earth Centred Earth Fixed. i.e. it's an X, Y, Z co-ordinate system which rotates with the earth.

My test data was the data from a marathon and so the distance should be very close to 42.26km. However, the distance comes to about 43.4km. I've tried various approaches and nothing changes the result by more than a metre. e.g. I replaced the height data with data from the NASA SRTM mission, I've set the height to zero, etc.

Using Google, I found two points in the literature where lat, lon, height had been transformed and my transformation algorithm is matching.

What could explain this? Am I expecting too much from Javascript's double representation? (The X, Y, Z numbers are very big but the differences between two points is very small).

My alternative is to move to computing the geodesic across the WGS84 ellipsoid using Vincenty's algorithm (or similar) and then calculating the Euclidean distance with the two heights but this seems inaccurate.

Thanks in advance for your help!

A: 

Javascript is easily accurate enough in its calculations, so I don't think your problem is coming from there. Certainly not a 2.5% error or so.

You throw around words I've never even heard of, so I'll assume you're at least as knowledgeable on geodesic distance calculation as I am. I remember dabbling with this a long time ago and the way to do this required calculating hyperbolic sines and cosines to do the "weird" spherical geometry. If you just "do" Euclidian planar distance, your distances will be off once the Earth's curvature becomes significant.

So... are you doing hyp-sin's? Is your program doing exponentials and logarithms and stuff? If not, you may be applying the wrong formulae.

There... that's all I know about the topic. Good luck!

Carl Smotricz
@Carl: Actually it only uses sin, cos, pow and sqrt.The geocentric transformation is here: http://www.satsleuth.com/GPS_ECEF_Datum_transformation.htm
Sarge
Is it possible you're calculating the as-the-mole-burrows distance between those points rather than the as-the-worm-crawls distance? I'm going to go dig out my book of formulae and see how those compare to the ones you cite.
Carl Smotricz
OK, I'm out of my depth: I give up. Good luck!
Carl Smotricz
A: 

I've just worked out what seems to be the main cause of the problem. I had the latitude and longitude round the wrong way in my transformation function.

Trap for young players: Point data gives the longitude first, not the latitude.

I'm now getting 42,476.75 from my algorithm and 42,476.69 from the spheroid. Close enough for my purposes.

Thanks everybody!

Sarge
Sounds reasonable :-)
Arthur Reutenauer
it'd be helpful to others if you could post the relevant code of your solution :)
philfreo
I think this is from cartography - map projections are usually defined easting/northing, which is like the x,y convention we learn in grade school. Hence long/lat.
mtrw
A: 

You could use the Google Maps Api for a calculation like this. I did this once.

powtac
I haven't checked but the Google Maps API won't take elevation into account. Google Maps is 2D.
Sarge