有几个以上讨论的拓展问题，在分享的时候大家都比较关心，补充一下：

地图栅格服务端

如果我们要将这个方案产品化/全链条走通的话，势必涉及到服务端数据处理。以目前的方案，服务端的设计包括：

- 基于查询会话的接口返回：每一次地图数据查询为一次会话，会话开始时在服务端拉取这次查询的数据并进行处理。

- 需要首先将栅格划分的基础逻辑提供给客户端，这是渲染的基础信息。

- 数据处理为数据图片并提供给客户端查询。同时建议提供分片查询的能力以加快客户端查询速度优化用户体验。（本身地图应用就是一个分片查询的典型案例）

- 单个数据查询，可以查询到每个tile对应的原始json数据信息。提供get接口（点击查询）和websocket服务（鼠标移动查询）

- 当然，也需要提供会话结束的机制。

- 该方案以中间件的形式提供服务，不破坏原有业务服务流程。


散点数据的地图栅格化展示方案

如果我们数据真的只有散点，是不是可以通过类似的方案来提升展示效率呢？答案是肯定的。这类似于游戏中碰撞测试的栅格化优化方案（3D游戏的碰撞检测是如何实现的？ - 皮皮关的回答 - 知乎 https://www.zhihu.com/question/266499219/answer/313570770）

基本思路是：如果不存在栅格，假设我有m个像素点，n个数据点，那么我们用像素纬度方案渲染复杂度是O(m*n)，但是，如果我们能在地图上的数据划分一下栅格，并且能做到还比较均匀的话，假设栅格最大数据数量是z，那么这个方案的复杂度就是O(m*z)了，z肯定远远小于n，并且如何划分合理的话，z->1。

当然，以上是理论方案，由于绘制区域是大于栅格，因此如果设定每一个点的绘制区域是格子变长的x倍，那么每次检查的栅格就不是一个了而是x^2个，因此实际的代码时间复杂度是O(m*z*x^2)，我们需要设计栅格合理划分来确定z*x^2远小于n，这个方案才成立。

因此相对于原本的方案，这个方案的改动点是：

- 数据图像不仅储存栅格本身的信息，还储存数据点具体的经纬度（或者是渲染坐标）。这个涉及到一个进shader的图片储存方式的问题。可以通过索引图+数据图的方式。索引图和原本的栅格数据一致，每个像素储存的rg和ba分别是索引图的x和y，那么数据范围是65536x65536。那对应的数据图最多可以来2147483648个数据点，肯定够用。数据图像的储存方式是一个像素可以储存一个经度或纬度（rgb24位其实就足够了，多出来的还可以储存其他信息），两个像素组成一个完整的数据。那10w个数据需要20w个像素储存，其实也就200*1000的一张图片，很小啦（不过因为高密度数据，压缩率估计感人）。

- 像素查询栅格的时候，需要查询可能覆盖渲染的所有栅格，比如我们一个格子是2km宽，但是我们的标示图本身就是4km宽，那么我们至少上下左右要多查询4km，也就是说我们一共得查询10kmx10km共计25个格子的数据点才能确定我这个像素需要绘制什么。

- 这个方案用经纬度定位和像素坐标定位都行，看情况使用。

- 地图栅格服务端也需要作对应改造。