使用Google Maps API v3的编码折线有什么好处吗？

Question

使用Google Maps API v3的编码折线有什么好处吗？

3

如果您正在处理数百个折线，使用https://developers.google.com/maps/documentation/utilities/polylinealgorithm?hl=sv-SE对折线进行编码是否会带来很大的性能优势？

似乎这主要用于API v2和v3，可以自己很好地处理大量折线？

我似乎找不到任何基准比较。

- Canadaka

1

我非常惊讶这个问题被关闭，而实际的事实数字证明了它的好处。 - Erik Philips

2个回答

0

不确定是否有任何正式的基准。但是与实际的纬度/经度数据相比，编码的折线变得更小。我在某些情况下使用它，特别是在使用Ajax更新地图时。

- Salman

所以人们可能会认为编码的折线会更小，但是我的测试页面上有大约30个折线，结果很有趣。页面的未压缩大小较小，但是我的服务器对响应进行gzip压缩，尽管未压缩大小较大，但gzip版本的大小实际上更小。[编码的折线] 大小：157KB 压缩后：32KB[折线] 大小：208KB 压缩后：31KB - Canadaka

当您编码一个巨大的数字，比如三百万个坐标时会发生什么？ - Salman

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Erik Philips · Accepted Answer

使用google.maps.geometry.encoding.decodePath()解码编码路径并将多边形/多边形添加到Google地图时，可以获得显著的收益。我有一些具有超过千个点的路径，使用简单的解码代替循环遍历每个点并创建要添加到多边形中的LatLng，可以更快地加载可视化效果。

此外，正如Salman指出的那样，通过减少通过Ajax传递路径的网络流量，可以实现显著的增益。以谷歌的示例为例。

Characters
0        1         2         3         4         5         6         7
1234567890123456789012345678901234567890123456789012345678901234567890
38.5,-120.2|40.7,-120.95|43.252,-126.453  // Polyline Decoded: 40 chars
_p~iF~ps|U_ulLnnqC_mqNvxq`@               // Polyline Encoded: 27 chars

我们只用了三个点，就将点的大小缩小了33%。