关于百度地图点聚合的问题

  浑浑噩噩的很长时间了，感觉这样下去不是办法，所以想给自己找点事来做。但又不知道做什么，所以，先从在csdn写点什么开始吧，权当写给以后的自己看。

  之前有个个项目，需要在地图上打点，数量大概三五万吧，常规逻来做地图肯定就卡死了。所以需要做点聚合功能，人懒，也不想去找别人现成的东西。好在同事之前做过，所以问了大概思路然后就自己开始搞了。

  具体思路很简单。 两种情况。

  1、当地图放大到一定比例的时候，如1：500米比例尺，这个时候能看到的范围很小，只需要判断需要打的点位置是不是在屏幕范围内（具体百度API提供了方法不再做赘述），不在屏幕范围的舍弃，剩下的点不会太多。

  2、返过来，当地图缩小到一定比例的时候，我们能看到很大的范围，有可能所有点都在屏幕范围内能显示完，这个时候也需要先做第一步，筛选出屏幕范围内的点（点数量很多的情况下还是很有必要，因为不确定当前比例尺下在或者不在屏幕范围内的点到底有多少），然后将地图等分成很多个部分（或者说网格划分），可以创建点的数组point[row][col]，计算筛选出来的点，在屏幕上属于哪个区域，可以赋值point[i][j]，数据保存的就是聚合后的点，最后遍历这个二维数组，就可以画出聚合后的点。当然，最后别忘了非空判断，有的区域可能没有点覆盖。

在实际使用中，发现在做筛选点是不是在屏幕范围内的时候很耗时，发现是百度地图在做地理坐标和屏幕坐标转换时比较耗时，一万个点就点转一万次。所以这里我们用逆向思维改一下。计算当前地图屏幕左下角和右上角两个点的经纬度，然后判断各个点的经纬度是不是在这两个点形成的矩形范围内（这里我们姑且当成是理想状态的水平面而不是球面）。实际发现，效率提升了很多。

  自我总结：有时候逆向思维能带来意向不到的效果。在这个案例中还有不完善的地方，例如在拖动地图的时候，聚合的结果会发生改变，虽然不影响效率，但总觉得有点不完美，可以尝试根据比例尺大小来动态调整筛选距离大小，然后计算集合中各点的距离来做筛选，这样结果就只和比例尺大小有关，而和地图屏幕位置无关了。