存储纬度和经度的合适/最佳类型
在像C、C++或D这样的系统级编程语言中，存储经度和纬度的最佳类型/编码是什么？
我看到的选项是：
在32位或64位整数范围到度数范围的int deg = (360/2^32)*val
- degrees，
- 映射中，以度、radians
- degrees或弧度形式存储的
- IEEE-754 FP :以位字段形式存储在int
- 某种结构中的分钟、秒和小数秒。
简单解决方案(FP)的主要缺点是它的分辨率高度不均匀(在英国的某个地方，它可以测量微米，在日本，它不能)。这也有FP比较之类的所有问题。其他选项在数据生命周期的不同部分需要额外的工作。(生成、演示、计算等)
一个有趣的选项是浮动精度类型，随着纬度的增加，它会获得更多的位，而经度会变得更少(随着它们越来越接近两极)。
相关问题并没有完全涵盖这个问题：
- What is the ideal data type to use when storing latitude / longitudes in a MySQL
- Working with latitude/longitude values in Java
顺便说一句: 32位在赤道上的E/W分辨率约为0.3英寸。这接近于高级GPS设置可以工作的规模(IIRC，在某些模式下，它们可以降到大约0.5英寸)。
OTOH如果32位均匀地分布在地球表面上，你可以在一边索引大约344m的正方形，5Bytes给出21m，6B->1.3m和8B->5 5mm。
我现在还没有具体的用途，但我以前曾使用过这种东西，并希望在某个时候再次使用。
回答 14
Stack Overflow用户
发布于 2008-12-21 23:13:54
最简单的方法就是将其存储为以度为单位的浮点数/双精度数。N和E是正的，S和W是负的。只要记住分钟和秒都是60分和秒(所以31 45'N是31.75)。通过查看它们很容易理解它们的值，并且在必要的情况下，转换为弧度是微不足道的。
纬度和经度的计算，例如两个坐标之间的Great Circle距离，在很大程度上依赖于三角函数，而三角函数通常使用双精度。任何其他格式都将至少依赖于正弦、余弦、atan2和平方根的另一种实现。任意精度的数字(例如Java中的BigDecimal )对此不起作用。像int这样的2^32均匀分布的东西也会有类似的问题。
在几个评论中已经提到了一致性的观点。在这一点上，我将简单地指出，地球在经度方面并不是一致的。北极圈的一角秒经度比赤道的距离短。双精度浮点数在地球上的任何地方都提供低于毫米的精度。这还不够吗？若否，原因为何？
同样值得注意的是，您希望如何处理这些信息，因为您需要的计算类型将对您使用的存储格式产生影响。
Stack Overflow用户
发布于 2008-12-21 23:15:25
经度和纬度通常不会比32位浮点数的精度更高。所以如果你关心存储空间，你可以使用浮点数。但一般来说，将数字作为双精度数使用会更方便。
弧度对于理论数学更方便。(例如，仅当使用弧度时，正弦的导数才是余弦。)但学位通常更熟悉，也更容易被人们理解，所以你可能会坚持使用学位。
Stack Overflow用户
发布于 2012-01-30 11:39:46
根据维基百科在Decimal Degrees上的这篇文章，精度为8的十进制表示应该足够了。
0 decimal places, 1.0 = 111 km
...
7 decimal places, 0.0000001 = 1.11 cm
8 decimal places, 0.00000001 = 1.11 mmhttps://stackoverflow.com/questions/385132
复制相似问题