【发布时间】：2013-07-05 11:56:18
【问题描述】：
我查看了 this post 关于 geohashes 的信息。据作者介绍，计算散列的最后一步是交错 x 和 y 索引值。但这真的有必要吗？只要哈希表是根据更改后的索引规则构建的，是否有适当的理由不只是连接这些值？
【问题讨论】：
标签： algorithm geohashing
【发布时间】：2013-07-05 11:56:18
【问题描述】：
Geohashes 提供任意精度和 从代码末尾逐渐删除字符的可能性 减小它的大小（并逐渐失去精度）。
如果您只是简单地连接 x 和 y 坐标，那么用户在尝试通过小心地从 x 和 y 坐标中删除正确数量的字符来降低精度时必须更加小心。
【讨论】：
-
是的，你是对的 - 没有想到这一点，因为对于我正在构建的 geohash，没有必要降低精度。 - 谢谢。
除了任意精度之外，还有一个相关（并且更重要）的原因：具有公共前缀的 Geohashes 彼此接近。共同前缀越长，它们越接近。
54.321 -2.345 has geohash gcwm48u6
54.322 -2.346 has geohash gcwm4958
（请参阅http://geohash.org 试试这个）
此功能可以快速查找附近的点（尽管有一些 complications），并且仅在我们将两个维度交错以获得一种近似的 2D 邻近度指标时才有效。
随着维基百科条目继续到explain：
在数据库中使用时，geohashed 数据的结构有两个 好处。首先，由 geohash 索引的数据将包含所有点 给定连续切片中的矩形区域（切片数 取决于所需的精度和 geohash 的存在“故障 行”）。这在查询的数据库系统中特别有用 在单个索引上比多个索引更容易或更快 查询。其次，这种索引结构可以用于 快速而肮脏的邻近搜索 - 最近的点通常在 最近的地理哈希。
请注意，反过来并不总是正确的 - 如果两个点恰好位于细分的任一侧（例如赤道的任一侧），那么它们可能非常接近但没有共同的前缀。因此出现了我之前提到的并发症。
【讨论】：