文章版權由作者李曉暉和博客園共有，若轉載請於明顯處標明出處：http://www.cnblogs.com/naaoveGIS/
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.前端將全文檢索——文本或空間，以標准功能開發
-----歡迎轉載，但保留版權，請於明顯處標明出處：http://www.cnblogs.com/naaoveGIS/
如果您覺得本文確實幫助了您，可以微信掃一掃，進行小額的打賞和鼓勵，謝謝 ^_^
