文章版权由做者李晓晖和博客园共有,若转载请于明显处标明出处:http://www.cnblogs.com/naaoveGIS/前端
在多个项目中涉及到互联网地图的内网显示,经过自制工具完成了互联网地图的瓦片下载。可是此种方法存在以下几个问题:算法
a.瓦片均是离散型图片,远程部署很是耗时。sql
b.瓦片下载中,涉及到将互联网瓦片下载至内存,而后创建对应文件夹,而后保存至本地的过程,效率不高。数据库
除了以上两个问题外,还有存储占用比较多等等缺点。是否有相似于ArcGIS的Bundle型瓦片组织格式来解决存储占用、远程部署等已有问题的解决方案?后端
a. 轻量级服务器
SQLite和C/S模式的数据库软件不一样,它是进程内的数据库引擎,所以不存在数据库的客户端和服务器。使用SQLite通常只须要带上它的一个动态库,就能够享受它的所有功能。微信
这样很是便于咱们将其做为一个文件来看待。多线程
b. 单一文件并发
所谓的“单一文件”,就是数据库中全部的信息(好比表、视图、触发器、等)都包含在一个文件内。而且这个文件能够copy到其它目录或其它机器上,也一样可使用。工具
经过这个单一文件性,咱们即可以将自己须要离散存储的文件进行统一管理了。
c. 跨平台/可移植性
除了主流操做系统,SQLite还支持了不少冷门的操做系统,好比Android、Windows Mobile、Symbin、Palm、VxWorks等的支持。
一次存储,多点使用。
d.内存数据库(in-memory database)
目前内存愈来愈廉价, SQLite的内存数据库特性就愈加显得好用。SQLite 的API不区分当前操做的数据库是在内存仍是在文件(对于存储介质是透明的)。因此若是你以为磁盘I/O有可能成为瓶颈的话,能够考虑切换 为内存方式。切换的时候,操做SQLite的代码基本不用大改,只要在开始时把文件Load到内存,结束时把内存的数据库Dump回文件就能够了。
在存储瓦片时,若是瓦片数据不算多,内存足够用,能够切换为内存方式,进一步提升瓦片读取效率。
a.并发访问的锁机制
SQLite在并发(包括多进程和多线程)读写方面的性能一直不太理想。数据库可能会被写操做独占,从而致使其它读写操做阻塞或出错。
b. SQL标准支持不全
在它的官方网站上,具体列举了不支持哪些SQL92标准。
MBTiles 是一种地图瓦片存储的数据规范,可大大提升海量地图瓦片的读取速度,比经过瓦片文件方式的读取要快不少,适用于Android、IPhone等智能手机的离线地图存储。
MBTiles经过视图,能够重复使用冗余瓦片数据,从而减小瓦片占用的空间,而不是一个单一的、文字表。好比:地图覆盖大面积的纯蓝色像海洋或空的土地,形成成千上万的重复、冗余的瓦片数据,例如,4/2/8的瓦片在太平洋中间,可能看起来就是一张蓝色图片虽然它多是一些处于第3级,但在16级可能存在数以百万计的蓝色图片,他们都彻底同样。
MBTiles通用方法是将瓦片表分红两张:一个用来存储原始图像和一个存储瓷砖坐标对应那些图片。具体设计以下:
a.设计map表
对瓦片行列号以及对应的瓦片ID进行存储。
b.设计images表
对瓦片进行存储。
c.设计视图tiles
基于map和images生成。
瓦片下载工具基于瓦片寻址算法开发,针对不一样互联网地图,瓦片的行列号算法等稍有不一样。尤为是针对百度地图,其瓦片算法会按照百度的瓦片分级偏移规则进行换算。这里不作累述。
设计思路为:
a.多线程瓦片下载,内存中开辟容器池。
b.当内存容器池满后,进行总体入库至sqlite。入库时进行上锁,规避Sqlite对多事务支持不理想问题。
后端按照链接池的思想,支持经过行列号在Sqlite中读取到瓦片。
a.提升瓦片下载存储速度。经测试,比本地图片存储方式效率至少提升一倍。主要因为,一是二进制存储,无转换过程。二是减小各层级文件夹创建耗时。
b.减小存储空间。MBTiles规范能够减小冗余瓦片。
c.便于数据转移。全部瓦片存储于一个文件夹中,便于数据转移部署。
d.提升海量地图瓦片的读取速度,比经过瓦片文件方式的读取要快不少。缘由为单个文件再也不涉及到目录寻址,而且也不须要将瓦片读取为二进制再传出。
因为sqlite自己对多事务支持不是很良好,大并发访问瓦片的情景还需测试。下一步准备使用Jmeter进行测试。
目前矢量切图工具,存储的也均是离散型的PBF。使用MBTiles进行存储,也能实现便于部署的目的。而且,一个图层使用一个视图,这种概念与ArcGIS中的图层入库也更为类似。
-----欢迎转载,但保留版权,请于明显处标明出处:http://www.cnblogs.com/naaoveGIS/
若是您以为本文确实帮助了您,能够微信扫一扫,进行小额的打赏和鼓励,谢谢 ^_^