GIS大資料儲存預研
1. 背景
在實際專案執行中，時常會出現希望搜尋周邊所有資料的需求。但是以常規的儲存方案，每種資源均為一個圖層或一個表，比如人員軌跡表、車輛軌跡表、各類空間圖層表等。在進行全文空間收索時，基於傳統空間關係庫或後臺圖層服務的遍歷查詢則過於耗時。這裡，我們研究基於ElasticSearch來進行所有資料的整合，以及全文查詢服務的提供，並且分別從查詢效率、查詢精度、查詢型別、儲存空間四個維度來進行方案的驗證。
2.實驗資料準備
試驗資料包含5個行政面圖層、3個線圖層（一、二、三級道路中心線）以及75個點圖層。一共83個圖層。
3.儲存設計和對比
a.一個shp對應一個索引。索引中記錄shp圖層的屬性資訊和幾何資訊。
b.增加wkt欄位以儲存原始座標。由於ES的空間查詢僅支援wgs84座標，在匯入資料時我們將即利用wkt欄位保留原始座標,而es的location欄位則儲存轉換後的wgs84座標資料結構設計:
以下為點、線、面的儲存結構：
點
線
面
83張圖層的佔用儲存空間變化：
|
表名 |
Shp大小 |
儲存佔用空間 |
|
燈 |
9.91mb |
3.3mb |
行道樹 |
25.3mb |
8.3mb |
|
X1井蓋 |
23.6mb |
7.7mb |
|
X2井蓋 |
24.1kb |
10kb |
|
X3井蓋 |
729 kb |
458.8kb |
|
… |
… |
… |
|
合計 |
198mb |
72.5mb |
4.查詢驗證（型別、效率、精度）
4.1查詢型別—面查點
以網格面fid為122的面進行查詢。
http請求
GET /_all/_search
{
"query":{
"bool": {
"filter": {
"geo_shape": {
"location": {
"shape": wkt,
"relation": "within"
}
}
}
}
}
}
效率：
查詢到137個結果，耗時517毫秒
精度：
4.2查詢型別—面查線
以街道面fid為2的面進行查詢三種道路中心線。
http請求
GET /一級道路中心線,二級道路中心線,三級道路中心線/_search
{
"query":{
"bool": {
"filter": {
"geo_shape": {
"location": {
"shape": wkt,
"relation": "within"
}
}
}
}
}
}
效率：
35條結果，耗時151毫秒
精度：
4.3查詢型別—面查面
同樣以街道面fid為2的面進行查詢社群面
http請求
GET /社群面/_search
{
"query":{
"bool": {
"filter": {
"geo_shape": {
"location": {
"shape": wkt,
"relation": "within"
}
}
}
}
}
}
效率：
7條結果，耗時1406毫秒
精度：
4.4查詢型別—點查面
查詢井蓋fid為10929的點落在哪一塊網格、社群、街道內。
http請求
GET /index/_search
{
"query":{
"bool": {
"filter": {
"geo_shape": {
"location": {
"shape": wkt
}
}
}
}
}
}
效率和精度：
查詢結果是正確的，耗時都在5毫秒以內。
5.總結
利用ES來進行空間大資料的儲存和運用無論從精度、效率、儲存利用空間上均是非常合適的選擇。但是從專案實施的角度，仍然有以下內容需要完成：
a.elasticsearch的指令碼化搭建。
b.入庫工具開發
c.後臺服務介面封裝，對輸入引數（座標等）以及輸出結果（座標等）根據對應環境轉換
d.前端將全文檢索——文字或空間，以標準功能開發
如果您覺得本文確實幫助了您，可以微信掃一掃，進行小額的打賞和鼓勵，謝謝 ^_^
