使用地心坐标系计算纬度、经度和高度的距离
我已经在 Javascript 中实现了这个方法，大约完成了 2.5%，我想了解为什么。
我的输入数据是一个点数组，表示为纬度、经度和 WGS84 椭球上方的高度。这些点取自马拉松比赛期间腕式 GPS 设备收集的数据。
我的算法是将每个点转换为笛卡尔地心坐标，然后计算欧几里德距离（参见毕达哥拉斯）。笛卡尔地心也称为地心固定。即它是一个随地球旋转的 X、Y、Z 坐标系。
我的测试数据是马拉松的数据，所以距离应该非常接近42.26公里。然而，距离约为43.4公里。我尝试了各种方法，但结果改变的程度没有超过一米。例如，我用 NASA SRTM 任务的数据替换了高度数据，我将高度设置为零等。
使用 Google，我在文献中找到了两个点，其中纬度、经度、高度已被转换，并且我的转换算法是匹配的。
有什么可以解释这一点呢？我是否对 Javascript 的双重表示期待太多？ （X、Y、Z 数字很大，但两点之间的差异很小）。
我的替代方案是使用 Vincenty 算法（或类似算法）计算 WGS84 椭球上的测地线，然后使用两个高度计算欧几里得距离，但这似乎不准确。
预先感谢您的帮助！
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!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我刚刚找出了问题的主要原因。我的变换函数中的纬度和经度是错误的。
年轻球员的陷阱：点数据首先给出经度，而不是纬度。
我现在从算法中获得 42,476.75，从球体中获得 42,476.69。足够接近我的目的了。
谢谢大家！
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!
Javascript 在计算中很容易足够准确，所以我不认为你的问题来自那里。当然不是 2.5% 左右的误差。
你抛出了我从未听说过的单词，所以我假设你至少和我一样了解测地距离计算。我记得很久以前就涉足过这个问题，而实现这一点的方法需要计算双曲正弦和余弦来完成“奇怪的”球面几何。如果您只是“执行”欧几里得平面距离，那么一旦地球曲率变得很大，您的距离就会偏离。
那么...你在做hyp-sin吗？你的程序正在做指数和对数之类的事情吗？如果不是，您可能应用了错误的公式。
这就是我所知道的关于这个话题的全部内容。祝你好运！
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!
您可以使用 Google Maps Api 进行这样的计算。我这样做过一次。
You could use the Google Maps Api for a calculation like this. I did this once.