Uber H3:為什麼六邊形地理索引比方格更適合供需熱區、派單與流動分析
Geospatial Index × Data Engineering × Marketplace Optimization
Uber H3:把 GPS 點變成可計算的六邊形區域,才是位置資料工程的關鍵
H3 不是單純把地圖畫成比較漂亮的六邊形,而是一套全球、階層式、多解析度的地理索引系統。它把零散 GPS 經緯度轉成可聚合、可鄰近搜尋、可表示移動方向的 Cell / Edge,讓供需熱區、派單、物流、城市分析與 GIS 視覺化能在資料表與模型裡被穩定處理。
核心洞察:很多位置資料問題,真正難的不是「點在哪裡」,而是「哪個區域正在發生什麼事」。H3 的價值就是把無限連續的 GPS 點,轉成有限、可索引、可統計、可跨尺度比較的空間單位。
Geohash / 方格的限制
方形或矩形網格雖然容易編碼,但鄰居關係不均勻:水平/垂直鄰居與對角鄰居距離不同,鄰近搜尋與需求擴散分析容易出現方向偏差。對只是顯示地圖可能還好,對派單、熱區、供需平衡就會變成模型噪音。
六邊形的工程優勢
六邊形每個 Cell 固定有 6 個邊相鄰鄰居,中心到鄰居距離更一致,也更接近圓形半徑搜尋。Uber 官方文章指出,這能簡化 gradient smoothing、近鄰分析與以半徑近似的市場分析。
H3 的真正重點
H3 不只是六邊形網格,而是 Hexagonal + Hierarchical + Global index:同一個位置可以用不同 resolution 表示,從城市尺度一路細到街區/建物附近尺度。
H3 如何把地球切成可用的資料結構
| 設計層 | H3 做法 | 為什麼重要 |
|---|---|---|
| 全球投影 | 以二十面體 Icosahedron 為基礎,使用以各面為中心的 gnomonic projection | 避免把球面硬塞進單一平面造成過大變形 |
| 基本單位 | 以 Hexagon Cell 為主,另有少量 Pentagons 處理球面覆蓋限制 | 六邊形無法完美覆蓋球面,五邊形是必要例外 |
| 基礎 Cell | Uber 官方文中說明 H3 在地球上鋪設 122 個 base cells,並包含 12 個 pentagons | 建立全球離散格網的起點 |
| 多解析度 | Resolution 0–15,共 16 層;每一層 finer resolution 約為上一層 1/7 面積 | 同一套索引可支援城市、商圈、街區等不同尺度 |
| 鄰近搜尋 | k-ring / grid distance 可查中心 Cell 外一圈、兩圈、k 圈鄰居 | 適合附近司機、熱區外擴、配送服務範圍等問題 |
| 流動表示 | Directed Edge 可表示從某個 Cell 移動到相鄰 Cell | 讓 H3 不只描述地點,也能描述車流、人流、物流與需求轉移 |
實務資料管線怎麼用 H3
- 1. GPS → H3 Cell:把每筆事件的 latitude / longitude 轉成固定 resolution 的 H3 index。
- 2. 事件聚合:用 H3 Cell 當 group by 欄位,統計訂單數、叫車需求、供給、等待時間、配送延遲、事故/通報密度等。
- 3. 鄰近查詢:用 k-ring / grid distance 找周邊 Cell,分析熱區外溢、附近司機、商圈互相影響。
- 4. 跨尺度 roll-up:把高 resolution 的 Cell 聚合回較粗 resolution,看城市、行政區、商圈、街區尺度下的同一套指標。
- 5. 視覺化與模型特徵:把 H3 index 當成地理特徵、熱區圖層或機器學習模型中的空間欄位。
import h3
lat = 25.033964
lng = 121.564468
cell = h3.latlng_to_cell(lat, lng, 9)
print(cell) # 例如:894bb12620fffff
解析度選擇不是越細越好:resolution 太粗會把不同商圈混在一起;太細則資料稀疏、隱私風險提高、計算成本增加。實務上應依問題選尺度:城市供需、行政區管理、商圈熱區、街區派單,會需要不同 resolution 或多層 resolution 同時存在。
對產品與資料團隊的可複用啟發
叫車 / 外送 / 物流
把需求、供給、等待時間、配送路徑與動態定價放進一致 Cell,可讓調度、熱區偵測與供需預測更可控。
零售 / 展店 / 商圈分析
用 Cell 聚合人流、消費、訂單與競品密度,比用行政區或郵遞區號更細緻,也比較不受行政邊界任意改動影響。
城市治理 / IoT / 安防
交通流量、告警、通報、感測器事件可先轉成 H3,讓跨資料源的空間 join 更簡單。
AI / Agent 地理工具
對 agent 而言,H3 是把自然語言中的「附近」「熱區」「往外擴一圈」「某區域流向另一區域」轉成可查詢結構的好中介層。
使用 caveat
- H3 不等於真實行政邊界:若業務規則綁定里、區、郵遞區號或店家服務範圍,仍需 polygon / boundary join。
- 六邊形也不是完美球面:H3 透過二十面體與少量 pentagons 近似全球覆蓋,跨 pentagon 或面邊界時要注意 edge cases。
- 聚合會改變結論:不同 resolution 可能導致熱區、平均值、異常偵測結果不同;要把尺度當成模型假設明確記錄。
- 隱私風險:高 resolution 位置資料可能接近個人行蹤,需要脫敏、最小化保存、權限控管與聚合門檻。
- 生態系:官方核心庫是 C,GitHub repo 以 Apache-2.0 授權;Java、JavaScript、Python 等 binding 可用,但 API 名稱會隨版本更新,實作前要看當前文件。
一句話總結:H3 的產品價值不是「六邊形比較好看」,而是把位置事件轉成一套可 group by、可鄰近搜尋、可跨尺度 roll-up、可描述移動方向的資料結構。這正是大量 GPS / 物流 / 外送 / 城市事件資料從地圖展示走向決策系統的關鍵。
Threads 來源:moper.data:H3:Uber 為什麼用六邊形切分地球?
Uber 官方文章:H3: Uber’s Hexagonal Hierarchical Spatial Index(2018-06-27, Isaac Brodsky)
官方專案:uber/h3 GitHub(Apache-2.0;GitHub API 查詢時約 6.3k stars;default branch: master)