摘要：數據將具有如下個特點將二維的經緯度轉換成字符串，比如下圖展示了北京個區域的字符串，分別是，等等，每一個字符串代表了某一矩形區域。例如，坐標對，位于北京安定門附近，后形成的值為。

作者簡介：戴嘉樂( Mr.Maple ) | 前百度高級研發工程師 | IPFS應用實踐者&布道師|
個人網站：https://www.daijiale.cn
聯系方式：微信號：daijiale6239。

打造地理位置信息與區塊鏈的關系對象模型，建立一套 人->位置->真實世界->傳遞信任->價值轉移->位置->人?的生態模型，實現用區塊鏈來索引真實世界的愿景。

通過GeoHash算法可以大幅度提高在龐大位置數據中的檢索效率，同時為應用提供便捷的緩存機制。

IPFS&Filecoin技術則可以保證在一個可信的區塊鏈網絡中去大規模傳遞與海量位置信息相關聯的海量文件、數據集合，并保證傳遞過程中數據的產權價值。

DDApp
DDApp ( Data Decentered Application )：是一個數據去中心化應用的概念，介于傳統應用和去中心化應用之間，解決了DApp不能依賴中心化的API的問題，又保證部分需要去中心化場景下的數據，在與應用交互之外，還可以獨立分布部署、P2P傳輸。

IPFS
IPFS全稱InterPlanetary File System，中文名：星際文件系統，是一個旨在創建持久且分布式存儲和共享文件的網絡傳輸協議。它是一種內容可尋址的對等超媒體分發協議可以讓網絡更快、更安全、更開放。它是一個面向全球的、是一個點對點的分布式版本文件系統，試圖將所有具有相同文件系統的計算設備連接在一起。

GeoHash
Geohash是由Gustavo Niemeyer發明的公共域地理編碼系統，它將一個地理位置編碼成一串字母和數字。它是一種層次化的空間數據結構，將空間細分為網格形狀的桶，是一種被稱為z -階空間填充曲線的應用，下圖中就是GeoHash算法中常用的Peano曲線，一種四叉樹線性編碼方式。

GeoHash數據將具有如下3個特點：

1 GeoHash將二維的經緯度轉換成字符串，比如下圖展示了北京9個區域的GeoHash字符串，分別是WX4ER，WX4G2、WX4G3等等，每一個字符串代表了某一矩形區域。也就是說，這個矩形區域內所有的點（經緯度坐標）都共享相同的GeoHash字符串，這樣既可以保護隱私（只表示大概區域位置而不是具體的點），又比較容易做緩存，比如左上角這個區域內的用戶不斷發送位置信息請求餐館數據，由于這些用戶的GeoHash字符串都是WX4ER，所以可以把WX4ER當作key，把該區域的餐館信息當作value來進行緩存，而如果不使用GeoHash的話，由于區域內的用戶傳來的經緯度是各不相同的，很難做緩存。

2）字符串越長，表示的范圍越精確。如圖所示，5位的編碼能表示10平方千米范圍的矩形區域，而6位編碼能表示更精細的區域（約0.34平方千米）。

3）字符串相似的表示距離相近（特殊情況后文闡述），這樣可以利用字符串的前綴匹配來查詢附近的POI信息。如下兩個圖所示，一個在城區，一個在郊區，城區的GeoHash字符串之間比較相似，郊區的字符串之間也比較相似，而城區和郊區的GeoHash字符串相似程度要低些。

例如，坐標對（116.414597,39.955441），位于北京安定門附近，GeoHash后形成的值為WX4G2。

我們已經知道現有的GeoHash算法使用的是Peano空間填充曲線，這種曲線會產生突變，造成了編碼雖然相似但距離可能相差很大的問題，因此在基于個人位置查詢附近Poi信息時，首先篩選GeoHash編碼相似的POI點，然后進行實際距離計算，來規避算法突變所造成的誤差。

當然Geohash只是空間索引的一種方式，特別適合POI點數據，而對線Link、面數據采用R樹索引更有優勢。

Geo Object Model

這是網友以 100萬 poi 數據查詢范圍 3km 內的點（最多取100條）的性能測試統計:

以下是各數據庫的對比情況：

綜合比較后，個人選擇了MySql 來進行后文Demo的支撐數據庫：

MySql在5.7.4以前版本的童鞋可以通過myISAM引擎提供的Geom內置函數來實現

MySql在5.7.4以后版本的童鞋可以舒服的繼續使用InnoDB引擎，官方對其添加了對空間索引的支持，感興趣的朋友也可以對比下性能。

PS：

數據庫沒有哪個一定好，只要適合場景即可。

在研究IPFS存儲性能的過程中，由于測試網絡節點問題，有很嚴重的數據傳輸瓶頸，且不穩定，短期內，很難將需要頻繁更新以及百萬級別數據的檢索邏輯事務放在IPFS這一層中來做。

在IPFS節點網絡性能目前并不樂觀的情況下，嘗試去尋找能實現具有商業級別能力IPFS應用的過渡方案。

-- 表的結構 `geo_object`--CREATE TABLE `geo_object` (`geo_id` bigint(20) NOT NULL ?AUTO_INCREMENT,`geo_loc` point NOT NULL,`geo_address` varchar(255) NOT NULL,`ipfs_hash` varchar(255) NOT NULL) ENGINE=MyISAM DEFAULT CHARSET=utf8 COMMENT="geo對象模型";-- Indexes for table `geo_object`ALTER TABLE `geo_object`ADD PRIMARY KEY (`geo_id`),ADD SPATIAL KEY `geo_loc` (`geo_loc`);

有了以上的概念和設計模型，接下來，給大家看一個簡單的Demo實現：

IPFS單節點的部署就不詳細介紹了，這邊可以參考文章 [利用IPFS構建自己的去中心化分布式Wiki系統]()?的實現過程.

官方提供了Curl的API方式，我們可以通過addIpfsDataByParam()方法實現RPC調用。

curl -F file=@myGeoFile "http://localhost:5001/api/v0/add?recursive=false&quiet=false&hash=sha2-256"

PS：這邊Demo采用的是本地單節點的數據上傳，為了保障服務的穩定性，建議使用ipfs-cluster的節點集群解決方案，具體方案可以參考IPFS資深大牛（飛向未來）的文章《IPFS家族二》。

響應體為 ‘multipart/form-data’格式，成功，會返回如下Body數據：

{"Name":"myGeoFile""Hash":"QmYftndCvcEiuSZRX7njywX2AGSeHY21Sa7VryCq1mK1Ew""Bytes":"2428803""Size": ""}

拿到Hash值后，再通過mixIpfsDataByParam()方法關聯到我們的Geo位置數據上。

選取第一個基準位置點（模擬用戶所在定位）:

維度lat：39.989049
經度lng：116.313658

INSERT INTO `geo_object`(`geo_loc`, `geo_address`, `ipfs_hash`) VALUES (GeomFromText("POINT(39.989049 116.313658)"),"3W咖啡館","QmYftndCvcEiuSZRX7njywX2A21Sa7VryCq1mK1Ew21")

選取第二個Geo位置點（模擬近點）:

維度lat：39.988878
經度lng：116.313352

INSERT INTO `geo_object`(`geo_loc`, `geo_address`, `ipfs_hash`) VALUES (GeomFromText("POINT(39.988878 116.313352)"),"中關村創業大街南廣場","WCJIEFSCvcE231233HY21Sa7Vr1Cq1mK1Ew")

選取第三個Geo位置點（模擬遠點）:

維度lat：40.005466
經度lng：116.315938

INSERT INTO `geo_object`(`geo_loc`, `geo_address`, `ipfs_hash`) VALUES (GeomFromText("POINT(40.005466 116.315938)"),"圓明園","KBYftndCvcEiuSZRX7njyw1332Y21Sa723mKASDED")

假設球面圍欄對角點坐標A1（x1，y1），B1（x2，y2）：

x1 = lat + distance / ( 111.1 / COS(RADIANS(lng))), ?
y1 = lng + distance / 111.1 ?
x1 = lat - distance / ( 111.1 / COS(RADIANS(lng))), ?
y1 = lng - distance / 111.1 ?
//構建一階空間填充曲線
LineString(A1,B1) ?

PS：

赤道上經度的每個度大約相當于111.1km，經度的每個度的距離從0km到111.1km；

RADIANS()為弧度計算內置函數；

LineString() 為構建一階空間填充曲線內置函數。

獲取1km以內的IPFS數據：

SELECT ?* ?FROM ? ?geo_object ?WHERE ? MBRContains ?
( ?
LineString ?
( ?
Point ?
( ?39.989049 + 1 / ( 111.1 / COS(RADIANS(116.313658))), ?116.313658 + 1 / 111.1 ?), ?
Point ?
( ?39.989049 - 1 / ( 111.1 / COS(RADIANS(116.313658))), ?116.313658 - 1 / 111.1 ?) ? 
), ?
geo_loc ?
) ?

如下圖所示，我們拿到了距離3W咖啡館1Km以內中關村大街南廣場附近相關聯的IPFS數據:

獲取10km以內的IPFS數據：

SELECT ?* ?FROM ? ?geo_object ?WHERE ? MBRContains ?
( ?
LineString ?
( ?
Point ?
( ?39.989049 + 10 / ( 111.1 / COS(RADIANS(116.313658))), ?116.313658 + 10 / 111.1 ?), ?
Point ?
( ?39.989049 - 10 / ( 111.1 / COS(RADIANS(116.313658))), ?116.313658 - 10 / 111.1 ?) ? 
), ?
geo_loc ?
) ?

如下圖所示，我們拿到了距離3W咖啡館10Km以內中關村大街南廣場附近相關聯的IPFS數據:

PS：
關于Demo這塊，后續會另外新開一篇實戰文章【應用】基于IPFS和GeoHash構建具有地理位置價值服務的DDApp（實戰篇）來做專門介紹，讓大家也能自己動手編寫一個功能相對完善（可視化界面）DDApp 。

Vevue：一個在選定的區域內街拍可獲得代幣獎勵的DApp，鼓勵用戶分享原創內容，激勵場景化廣告。

地理位置簽到：只有到達指定位置坐標點，才可取得可信簽到密碼憑證，進行核對，確認地理位置信任問題。(滴滴加班公司打車報銷場景)

到店紅包（糖果）：，吸引用戶到達指定實體店鋪位置，通過位置可信核對，分發代幣糖果憑證/快照，激勵用戶到店消費，體驗現場活動。

車主停車位產權保護：經過購買的專用停車位實為車主用戶的資產，應受到產權保護，且車位的轉移、交易需要在一套依賴地理位置的信任體系中進行。

景區、名勝古跡、歷史遺跡信息保護：滄海桑田，地轉星移，也許有一天名勝古跡不復存在，但它們的電子信息（地理位置、圖像、所屬國家、歷史文化、視頻、VR全景等信息）將永遠被保存在區塊鏈上，真實且不被篡改，源遠流長。

與位置AR游戲結合：之前很火的Pokémon Go如果再加上Filecoin的獎勵機制會是一種什么樣的場面？也可以參考MANA區塊鏈項目的價值。

物聯網結合：?充電樁，ETC這些具有支付屬性、位置屬性的智能設備創新等等。

初衷：期望能讓大家看到區塊鏈的實際應用場景，為區塊鏈和傳統技術的結合做更多預演、布道、分享，不去聽幣圈熙熙攘攘的聲音，用技術創造真實的價值，也期待更多和我一樣想法的朋友加入，帶一些正能量給這個圈子。

IPFS-Geo
意義：是一個具有地理位置特征的IPFS智能對象，其元數據具備Geo相關特性，支持千萬級別空間數據的快速索引，對象內還提供LBS相關功能的接口服務。

[ 【戴嘉樂】利用IPFS構建自己的去中心化分布式Wiki系統]()

圓方圓學院匯集大批區塊鏈名師，打造精品的區塊鏈技術課程。 在各大平臺都長期有優質免費公開課，歡迎報名收看。
公開課地址：https://ke.qq.com/course/345101? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?