Algorithm 谷歌地图编码多段线算法格式背后的设计决策是什么？

一些Google Maps产品都有多段线的概念，就底层数据而言，多段线基本上只是一系列的lat/lng点，例如，可以在地图上绘制的一条线中显示出来。Google Map developer库使用编码的多段线格式，该格式生成一个ASCII字符串，表示组成多段线的点。然后，通常使用Google库的内置函数或实现解码算法的第三方编写的函数对这种编码格式进行解码

文档中描述了多段线点的编码算法。没有描述的是以这种方式实现算法的原理，以及每个步骤的重要性。我很想知道这种方法实现算法背后的思想/目的是否在任何地方公开描述过。两个示例问题：

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

但总的来说，与算法一起使用的一个描述解释了为什么算法是以这种方式实现的。

更新：来自James Snook的还有“有效ascii”范围参数，并且逻辑上阅读了我想知道的其他步骤。例如，存储前的左移位，将负位作为第一位

我发现了一些解释，不确定是否一切都是100%正确的

• 一个双精度值存储在多个5位块中，0x20（二进制“0010 0000”）用于指示下一个5位条目属于当前双精度值
• 0x1f（二进制“0001 1111”）用作位掩码以丢弃其他位
• 我希望使用5位，因为lat或LON的增量在此范围内。因此，在许多示例中，每个双精度值平均只占用5位（但尚未验证）
• 现在，压缩是通过假设附近的双精度值非常接近，并且产生的差值接近于0来完成的，因此结果适合于几个字节。然后，该结果以动态方式存储：存储5位，如果值较长，则用0x20标记并存储下一个5位，依此类推。所以我想你可以调整压缩，如果你尝试6或4位，但我想5是一个几乎合理的选择
• 现在关于magic 63，这是0x3f和二进制0011111。我不知道他们为什么加上它。我认为添加63将提供一些“更好”的asci字符（例如XML或URL中允许的字符），例如跳过62，它是
  ，但63是

  ？

  真的更好吗？至少第一个ascii字符是不可显示的，必须避免。请注意，如果使用64，那么将命中ascii字符127，最大值为31（31+64+32），并且该字符在html4中没有定义。或者是因为一个有符号的字符从-128变为127，我们需要将负数存储为正数，从而添加最大可能的负数
• 仅限我：是一个指向具有Apache许可证的正式Java实现的链接

---

马克·麦克卢尔（Mark McClure）曾经进行过很好的讨论。该服务器现在似乎已关闭，我们也会感兴趣。我发现这些代码注释很有用：使用64位编码的原因是能够以纯文本形式发送值。显然，除了63之外，还有许多其他值可以实现这一点。然而，就非常低的工作量而言，63似乎是一个相当好的附加值。它避免使用引号和分号。人们可能会怀疑，避免使用“？”是最理想的。在ascii表中，很难为64个字符选择更好的范围。这表明，对于许多64位编码，通常会选择更复杂的映射。你能更新一下吗？