Jan 11

用gl的思维进行地图栅格数据绘制 - 补充问题

Lrdcq , 2019/01/11 02:06 , 程序 , 閱讀(659) , Via 本站原創
有几个以上讨论的拓展问题,在分享的时候大家都比较关心,补充一下:

地图栅格服务端

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

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

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

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

- 单个数据查询,可以查询到每个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个格子的数据点才能确定我这个像素需要绘制什么。

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

- 地图栅格服务端也需要作对应改造。
关键词:webgl
發表評論
暱稱   密碼   訪客無需密碼
網址   電郵