在谷歌地图上加载100-200K标记

Vol*_*der 17 maps google-maps google-maps-markers markerclusterer

目前我正在使用Google Maps v.3 API在地图上绘制标记.我总共有大约500个标记.

出于显示目的,我在浏览器的客户端使用此工具使用markerCluster和组标记.

但是,我计划扩大位置数量,并假设它可以快速增长到100K甚至200K.

我做了一些压力测试,并意识到当前的解决方案基本上杀死了浏览器和大约10-20K标记.

所以我的问题是什么是绘制许多标记的最佳方法(不是必要的谷歌地图)?

我读过类似问题的帖子,例如:

在Google地图中显示许多标记

谷歌地图上太多针脚的最佳解决方案

基本上人们建议使用一些clusterer用于显示目的,我已经使用过.

或者使用融合表来检索数据,这不是一个选项,因为数据必须保留在我的服务器上.此外,我假设显示功能受到融合表的限制.

我正在考虑实现以下场景:

  • 在每个页面上缩放/加载 - 发送带有显示视图边界的ajax请求,在所有边上添加约30%并检索仅在此地理区域中的标记.如果用户缩小,则会添加30%,以便我可以快速显示其他标记,然后在背景中进一步后退(其他地方)

  • 当标记的数量超过50时 - 我计划将聚类应用于显示目的.但由于javascript中的markerCluster非常慢,即不是markerCluster而是谷歌本身,因为它仍然应用所有标记的位置,我打算通过在大约15*15网格中分割显示的地图的边界来在服务器端进行聚类然后将标记放入特定的单元格中,然后基本上将内部标记的数量发送给客户端集群(例如,用于热图).然后将群集显示为标记.

你能不能给一些有相似之处的人提供一些见解.一般来说它是否有意义.或者这是一个愚蠢的方法,因为ajax请求将在每个地图缩放和移位时发送到服务器,并基本上使冗余请求超载服务器?

我想要实现的是在大型标记数据集上的良好用户体验(在不到2秒的时间内加载).

Ric*_*son 11

你的方法很扎实.如果可能的话,您将需要预先计算群集并在服务器端缓存它们,其更新策略由基础数据集更改的频率决定.

Google地图有大约20个缩放级别,具体取决于您在地球上的位置.根据您的数据的聚集程度,如果您总共有200,000个标记,并且愿意在给定时间在地图上显示大约500个,计算所有群集位置和原始标记,您将最终只存储2n = 400,000个位置服务器结合所有缩放级别.

可能的群集更新策略:

  • 添加每个新标记的更新.如果您需要高度的数据及时性,那么对于读取量很少而且读取很少的应用程序是可能的.
  • 按计划更新
  • 启动更新if((自上次聚类传递以来有任何新标记&&缓存早于X)||自上次聚类传递以来,有多个Y个新标记)

将这些标记存储在本地支持地理数据的数据库中可能是有益的.这允许类似SQL的语句查询位置.

客户端,我会考虑在任何一方获得50%的保证金,而不是30%.谷歌放大2的幂.这将允许您显示一个完整的缩放级别.

接下来,如果此应用程序将被大量使用并且优化是值得的,我会在客户端放大时记录服务器端.尝试分析您的使用情况,以便您可以确定用户是否经常放大和缩小.使用实数(例如"70%的用户在检索初始结果后放大,20%缩小"),您可以确定是否值得为用户预加载下一层缩放数据,以获得UI响应.

  • 好的。这是您写的一篇非常详尽的文章,其中包含有关 Redis 方法的大量详细信息。感谢分享。 (2认同)