隨著城市規模的不斷擴大和便民業務的發展，行車導航、共享汽車和物流派送等應用已經深入人們日常生活之中。這些應用都不可避免地需要使用GPS、北斗等定位系統，進而產生了大量的軌跡資料。然而，普通民用GPS定位系統上傳的位置資料會由於許多緣故發生與物體的實際地理位置不同的現象，產生了米級別的誤差，一般在10米以內。此外，在資料傳輸、儲存和耗電的條件限制下，導致軌跡點取樣頻率不宜過高。因此，以上因素導致採集到的移動物件位置與其實際所在道路之間有一定距離偏差。為了使接收到的位置資料可以真實反映移動物件的執行軌跡，需要進行軌跡的各種預處理工作，其中地圖匹配是一項十分重要的工作。

一、地圖匹配地圖匹配是將存在誤差或漂移的GPS觀測點匹配至路網上的演算法，它常用於還原觀測點的真實位置和移動物體的運動軌跡。如圖1，地圖匹配演算法將採集到點1、2、3對映到路段上。地圖匹配可分為離線和實時兩種處理方式：離線方式接收過去一段時間觀測到的批量軌跡資料，並計算輸出全量軌跡的最優匹配結果。其優勢在於準確度高。然而，它的處理過程十分耗時，因此，面對監測和追蹤等需要實時返回計算結果的場景難免力有不逮；實時地圖匹配則可以很好地彌補離線處理時延大的缺陷。目前，基於HMM的實時地圖匹配演算法[2]被廣泛使用於很多業務場景中,如公交車實時位置播報、快遞員配送位置跟蹤。以危化品運輸車輛的監管為例，危化品運輸車若偏離原報備路線，通過實時的地圖匹配可以在第一時間獲取其異常行為及最新位置，實現了對危化品車輛行駛路線的實時監測。barefoot [1]是一個開源專案，它基於實時地圖匹配演算法提供了實時地圖匹配服務。本文接下來主要從演算法思想和實現思路兩方面介紹開源專案barefoot中的實時地圖匹配服務。

圖1 地圖匹配示意圖二、演算法思想Barefoot 是一個開源的Java專案，它提供了離線/實時地圖匹配及空間分析等服務，其中實時地圖匹配的實現思路以Goh[2] 提出的演算法作為參考。如圖2所示，Barefoot提供的實時地圖匹配演示圖。

圖2 實時地圖匹配演示圖Goh[2]提出的演算法基於隱馬爾可夫模型(HMM)，並採用可變滑動視窗進行回溯計算，實現了高精度低延時的實時地圖匹配。其主要流程大體分成三步， 1）尋找候選路網點，2）計算髮射和轉移概率，3）獲取計算結果。1）尋找候選路網點尋找候選路網點是指，針對每一個軌跡點z_t，找到距離z_t指定距離(預設為50m)的路段，計算每條路段上距離z_t最近的位置，即為候選路網點。候選路網點通常為軌跡點z_t在對應路段的垂直投影點或路段的端點。2）計算髮射和轉移概率獲取到軌跡點z_t對應的候選路網點集合S_t後，以z_t到每一個候選

QQ號碼賣號平臺地圖路網點的距離和GPS定位誤差為引數，計算候選路網點的發射概率P(z_t |s_t)；再針對上一時刻的候選路網點集合S_(t-1)與本次集合S_t中的每一組候選點，以兩個候選點之間最短路徑的長度作為主要引數計算這兩點之間的轉移概率。3）獲取計算結果概率計算完成後，通過線上Viterbi演算法檢驗是否存在結果點，並返回到達該點的最優路徑。

圖3 HMM演算法在HMM基礎之上，barefoot擴充套件了兩種概率模型：過濾概率和序列概率。其中，過濾概率P(s_t |z_0…z_t)用以計算在已觀測到軌跡點序列z_0…z_t的條件下，最可能符合真實情況的路網點s_t；序列概率P(s_0…s_t |z_0…z_t)則在已觀測到軌跡點序列z_0…z_t的條件下，計算在路網上到達點s_t 最可能的路徑。需要注意的是，在轉移概率和序列概率的計算過程中，需要使用歷史軌跡點對應的候選路網點集合作為引數。因此，barefoot採用了可變滑動視窗來儲存歷史狀態。可變滑動視窗指的是視窗中可容納的路網點集合數固定，而總路網點數量取決於每個路網點集中的點數，是可變的值。當接收到一個新軌跡點時，可變滑動視窗向前擴充套件一位，同時根據配置中的視窗上限引數來判斷是否需要清除當前視窗中的歷史路網點集。Barefoot 提供了狀態更新TTL、路網點集合數量上限k和時間段上限τ 三個視窗配置引數用於配置路網點集合數。三、實現思路

Barefoot通過啟動tracker server接收軌跡點，併發布計算結果。tracker server根據配置檔案中的引數初始化指定容積的執行緒池，併為每一個傳送資料的客戶端分配一個處理執行緒T。T會持續接收客戶端傳送的軌跡資料，並將計算結果傳送回客戶端。當客戶端長時間沒有向tracker server傳送訊息時，對應的連線將被中斷。在以上流程中，耗時較長的計算部分由處理執行緒T決定是否進行非同步計算。為實現以上計算步驟中的空間範圍查詢和最短路徑規劃，barefoot需要在記憶體中維護路網結構。它使用的方法是通過查詢讀取資料庫中的路網表，並根據道路線的屬性值構建路網有向圖和帶有道路線空間範圍的四叉樹索引來實現最短路徑規劃。在空間查詢獲取候選路網點時，使用索引獲取空間範圍內的道路線id，並在道路線上通過插值計算出與軌跡點距離最近的候選路網點的座標。

圖4 候選點針對每個軌跡點，barefoot將其對應的候選路網點集合儲存至時間窗內。時間窗使用優先佇列(PriorityBlockingQueue)實現，在提供超時清理和新增入隊功能的基礎上，起到保證執行緒安全的作用。時間窗內的候選路網點集合通過連結串列相連，方便獲取到每個路網點在上一狀態中的關聯點，以及本集合中最可能為真的目標路網點(如圖4中加粗的點)。本次候選路網點集合更新的同時，歷史點集合中既不是目標點又與後繼路網點無關聯的點將被移除。四、測試結果Barefoot 使用合理的索引和路網結構，在Goh[2] 的實時地圖匹配演算法的基礎上擴充套件了概率模型，實現了針對軌跡點實時地圖匹配的毫秒級響應。經測試，針對單個軌跡點的地圖匹配，Barefoot的計算耗時在50~200ms之間(詳見圖5)。

圖5 計算時間針對當前民用GPS的普遍取樣頻率低的現實情況，它也可以做到地圖匹配結果的實時返回。但是，barefoot的實現方式也使它具有一定的侷限性。Barefoot 採用固定數量的socket連線方式提供服務。因此，當連線的客戶端超出一定數量時，服務端的響應速度會受到影響；同時Barefoot沒有開放Kafka、Storm等實時平臺的接入方式，這使得其使用方式並不靈活。在地圖匹配計算方面，由於受到軌跡資料資訊量不足的限制，在計算轉移概率時，對路徑cost的計算不是以軌跡點速度為引數，而是採用固定引數進行模擬計算。導致在一些情況下可能會對計算結果產生影響。除此以外，目前barefoot只支援OSM路網資料，不支援更加靈活的路網模型，且每次啟動都將路網資料匯入JVM中，這種方式限制了其擴充套件性和遷移性。諸如此類問題，都是在實現或者應用時可以改進的方向。例如，可以通過redis等分散式快取技術優化路網構建的方法，使其更加適用於分散式場景；還可以針對特定路網資料的資訊量對概率計算公式進行改進，通過這些方式使其更適用於特定的業務場景。目前，JUST時空資料平臺[3]吸收了Barefoot優秀的設計思路，針對Barefoot的不足，正在實現一套集實時資料接入、實時地圖匹配、實時地圖展示等高可擴充套件的完整解決方案。