文章版權由做者李曉暉和博客園共有,若轉載請於明顯處標明出處: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/
若是您以爲本文確實幫助了您,能夠微信掃一掃,進行小額的打賞和鼓勵,謝謝 ^_^