Google Maps编码折线算法格式背后的设计决策是什么？

Question

多个Google地图产品都具有折线的概念，就基础数据而言，它基本上只是一系列lat / lng点，例如可能会在地图上绘制的线条中显示。 Google Map开发人员库使用编码折线格式，该格式生成表示构成折线的点的ASCII字符串。然后，通常使用Google库的内置函数或由实现解码算法的第三方编写的函数对此编码格式进行解码。

Encoded Polyline Algorithm Format文档中描述了编码折线点的算法。 不描述的是以这种方式实现算法的基本原理，以及每个步骤的重要性。我有兴趣知道以这种方式实现算法背后的思路/目的是否在任何地方公开描述。两个示例问题：

• 某些步骤是否会对压缩产生可量化的影响？这种影响如何随点之间的差异而变化？
• 使用ASCII 63的值求和是某种兼容性黑客吗？

但总的来说，一个描述与算法一起解释为什么算法的实现方式。

Answer 1

来自James Snook的

更新：This blog post也有'有效的ascii'范围参数，并且逻辑上读取我想知道的其他步骤。例如。在存储之前左移，这使得负位成为第一位。

我发现了一些解释，不确定一切是否100％正确。

• 一个double值存储在多个5位块中，0x20（二进制'0010 0000'）用作下一个5位条目属于当前double的指示。
• 0x1f（二进制'0001 1111'）用作位掩码以丢弃其他位
• 我希望使用5位，因为lat或lons的delta在此范围内。因此，对于大量示例（但尚未验证），每个double值平均只需要5位。
• 现在，压缩是通过假设附近的双值非常接近并且创建差值接近0来完成的，因此结果适合几个字节。然后以动态方式存储此结果：存储5位，如果值较长，则标记为0x20并存储接下来的5位，依此类推。所以我猜你可以调整压缩，如果你尝试6或4位，但我猜5是一个几乎合理的选择。
• 现在关于魔术63，这是0x3f和二进制0011 1111.我不知道为什么他们添加它。我认为添加63会给出一些“更好”的asci字符（例如允许在XML或URL中），因为我们跳过例如62 >但是63 ?真的更好吗？至少第一个ascii字符不可显示，必须避免。请注意，如果一个人使用64，那么就会命中ascii char 127，最大值为31（31 + 64 + 32），并且这个char没有在html4中定义。或者是因为签名字符从-128到127并且我们需要将负数存储为正数，从而添加最大可能的负数？
• 仅供我使用：here是使用Apache License
的官方Java实施的链接