一般我們在討論物流服務（例如宅配），或人流服務（計程車）的時候，有幾個面向需要考慮，這些也算是一個完整的物流服務的的拼圖，把這個拼圖拼完整，那物流服務的可靠性也會提高。
服務開始前：
使用者端：
服務進行中：
服務結束後：
上面提到的一些產品我們目前還沒有正式介紹過，但我覺得其中一個最有趣的就是 HERE Route Matching，因為這是一個很好玩的產品，其實這個產品也只做一件事情，就是接收使用者上傳的 GPS 軌跡檔，並且進行分析，回傳結果。
然而您可能會問，我要分析 GPS 軌跡做啥？其實蠻有趣的，GPS 因為上面有經緯度與時間，因此可以告訴我們很多事情：
以常見的物流業或租車業來說，可以用這個功能來分析司機的駕駛軌跡，知道駕駛有沒有超速或違規等情事，因為這些行為可能造成司機被罰款，違規次數多的話甚至吊扣駕照，對公司也是很大的損失，因此找出這些潛在的風險因子，也是成本管控的一部分。
而以保險公司來說，可以分析駕駛人經過的路段是否為高風險路段，例如經常落石的路段、連續彎路或易肇事路段，作為風險係數的計算依據，而精算出更佳的保費。
聽起來好像還蠻有趣的（？），那我們就先來試試看。
※ HERE Route Matching 官方網站：https://developer.here.com/documentation/route-match/
首先，要體驗 HERE Route Matching 功能，請先下載並安裝 Postman，這是一個測試網路 API 非常實用的軟體。之前的課程中使用的 API 都是屬於 GET 請求，因此用瀏覽器就可以完成，但我們現在需要進行的是 POST 請求，藉由 POST 請求來上傳我們的 GPS 軌跡到 HERE Route Matching 這個 API。
Postman 是免費的，而且跨平台，因此不管是 Windows 還是 Mac OS 甚至 Linux 都可以使用，而且現在甚至還有網頁版，您可以自行研究。
下載 Postman：https://www.postman.com/downloads/
打開網頁後請選擇「Download the App」，就會開始下載。下載後請依照一般的正常流程安裝即可。
安裝完打開 Postman，您會看到這個畫面，我個人是偏好暗色調，因此我會切換到黑暗模式，接著請按下「Create a request」來新增一個請求。
接著，請依照下圖進行：
https://m.fleet.ls.hereapi.com/2/matchroute.json?
輸入完成之後，就可以開始上傳 GPS 軌跡……等等，我沒有 GPS 軌跡怎麼辦？
HERE Route Matching 這個 API 接受四種 GPS 軌跡格式：
WW
latitude（緯度）以及 longitude（經度）以及其他非必要屬性例如 timestamp（時間戳記）、speed_mps（公尺 / 秒）、speed_mph（英哩 / 小時）、speed_kmh（公里 / 小時）、heading（方位角）。如果您的行車紀錄器是有 GPS 紀錄功能的，那應該有很大的機會是使用 NMEA 格式例如：
如果您是使用 Garmin 的行車記錄器，或是 Garmin 的運動攝影機，那應該會是使用 GPX 格式，例如：
這兩個格式是最不會出現任何問題的，因此您可以放心使用。至於 CSV 與 KML，就要麻煩您確認格式是否符合規定之後再使用了。
※ 關於軌跡格式的規格要求，請參見：https://developer.here.com/documentation/route-match/dev_guide/topics/file-formats.html
您可以使用自己的軌跡檔，如果沒有的話，我這邊提供一個現成的：https://bit.ly/3cw3bKU
開啟上面這個連結之後，會看到一大堆英文與數字構成的紀錄，紀錄當時的 GPS 信號狀態、定位精度等等。我們這邊主要會用到的只有「$GPRMC」這一種紀錄。
如果您有興趣的話可以研究一下 NMEA 格式的內容，沒興趣的話也沒關係，只是順道一提。
$GPRMC,004710.000,A,2501.9727,N,12132.2850,E,6.46,359.83,280519,,,A*6A
其中 2501.9727,N 與 12132.2850,E 就代表緯度跟經度，另外還有日期、時間、方位角跟速度的紀錄等等，就先略過不提。
接著我們把上面 NMEA 文字檔的全部內容都複製到剪貼簿（Ctrl + C）。接著回到 Postman 中，點選網址列下面的「Body」，然後選擇下方的「raw」，接著把剛剛複製的內容貼到下方的文字框中（Ctrl + V）。
然後，按下右上角的藍色「Send」，您剛剛貼上的軌跡檔就會被上傳到 HERE Route Matching 的後端進行分析，並回傳結果。
回傳的結果會顯示在下方，並且因為是 JSON 格式，Postman 也很貼心的把排版跟顏色都加上去了。
我們現在就來解讀一下結果，節錄部份內容如下。可以看到在這個 JSON 的結構，主要第一層有四個 key，分別是「RouteLinks」、「TracePoints」、「Warnings」、「MapVersion」：
RouteLinks：GPS 軌跡經過的道路線段（稱為 Link）資訊
TracePoints：GPS 軌跡點資訊
Warnings：警告事件
MapVersion：地圖版本，這邊預設為最新版（LATEST）
我們可以用「RouteLinks」中的「linkId」跟「TracePoints」中的「linkIdMatched」把兩邊的資料連在一起，類似 SQL 的 JOIN 指令，讓每個點位對應到相對的道路屬性，因此也賦予了原始 GPS 軌跡點更豐富的資訊。
我們可以用地圖來解說，概念會比較清晰一點。
以下面這張圖來說，就呈現了您剛剛上傳的這一個軌跡檔的起始點，編號為 0，接著依序下去到第 10 個點，可以明顯的看出這是在台北市承德路四段由北往南行駛的軌跡，右邊的點比較小，呈現的是原始 GPS 點位，而左邊的點比較大，呈現的是對應到道路上的軌跡。
這樣您應該就可以知道 HERE Route Matching 的作用是什麼：這個服務會接收您的 GPS 軌跡，並且比對 HERE 地圖資料庫的道路，藉由方向與位置來「猜測」您可能會駕駛在哪一條道路上面。
GPS 本身會偏移，一般來說，可能數公尺到數十公尺之間，在收訊良好狀況之下，我們會大概估計半徑五到十公尺為誤差半徑，至於雙頻的 GPS 或有輔助定位功能的 GPS（例如 AGPS / DGPS）可能可以到兩公尺至數十公分之內；如果是收訊不好的狀況，例如上方有遮蔽，或是周圍有高樓，而導致訊號被干擾、可視衛星不足或有訊號反射的狀況等等，都會影響到定位精度。
因此建議在使用 Route Matching 功能的時候，上傳的 GPS 軌跡不應該太短（建議應該至少也要幾十秒），因為如果 GPS 點位太少加上偏移量太大的時候，計算道路的正確率也會降低；因此，有足夠長度的 GPS 軌跡，可以讓 Route Matching 有足夠的資料來判斷經過的道路，進而提高正確度。
所以我們要提的是「Warnings」這個部份，如果 GPS 軌跡有違規的狀況，例如可能進入了不該進入的道路，違反了禁止轉彎的限制等等，都會在這個地方回傳；不僅於此，如果 GPS 軌跡在這邊有中斷、停止的狀況，也會在這邊呈現。因為 GPS 軌跡存在可能的誤差，因此這些事件只是呈現「可能」的狀況，不代表「一定」存在。
例如下面這個事件的內容是「Entering link 1063453689 at 25.04467,121.54123 into forbidden driving direction」，乍看之下我們可以解讀成「逆向行駛」，但是實際觀看 GPS 軌跡之後，發現這裡的路段天空被市民大道高架橋遮擋，GPS 訊號不良，導致漂移的狀況比較嚴重，而這個漂移剛好漂移到逆向的迴轉道上，因此觸發了一個逆向行駛的事件。
在實務上，我們應該把「Warnings」裡面的事件作為參考，而不是絕對的發生了違規或違法的狀況，實際的狀況可能要更深入的探討才能得到最終判斷，
但您可能會問了，剛剛那些屬性都是一些 經緯度、ID、方位角等等的屬性，感覺還是僅限於地圖上面使用，我要怎麼拿到更多實用的資訊呢？畢竟我知道這個 LINK 的長度，感覺對我來說好像沒什麼意思。
HERE Route Matching 的強大功能，除了用 GPS 點位找出經過的道路之外，還可以帶出這些道路的相關屬性。
HERE 有另外一個網路服務，叫做 HERE Advanced Data Sets，原理就是用網路 API 的方式，取得 HERE 地圖底層的詳細屬性，例如道路名稱、車道數、速限、平均速度、轉彎限制、地址、交通標誌、行進方向、坡度、高度、曲率等等。
但我們目前就先不介紹 HERE Advanced Data Sets 的用法，您可以自行研究。
※ HERE Advanced Data Sets：https://developer.here.com/documentation/platform-data/
HERE Advanced Data Sets 裡面的內容相當的豐富，甚至到了複雜的地步，HERE Route Matching 可以使用到裡面的一些圖層：
從上面的說明，您大概可以想像出 HERE Route Matching 取出的屬性有多麼豐富了，可以滿足非常多的用途。而我們這邊要使用的，只有「SPEED_LIMITS_FCn」這個部份而已。
您應該也會注意到，每一個圖層名稱後面都有「FCn」的後綴，這是因為 HERE 地圖把每一條道路依照功能性都分成五個等級，1 代表最高等級，通常是高快速道路，而 5 代表最低等級，通常是巷弄，而「FC」則是「Functional Class」（功能性等級）的縮寫。
意思就是說，其實您也可以只取得某個特定的 FC，例如「SPEED_LIMITS_FC1」就代表我只要取出 Functional Class 等於 1 的道路速限，如果此 GPS 軌跡經過的道路不是 Functional Class 等於 1 的話，就不會回傳。如果使用「FCn」的話，就代表可以回傳 Functional Class 等於 1 到 5 的都需要回傳，基本上就是所有的道路都包括在內。
因此「SPEED_LIMITS_FCn」就是「所有的道路，只要有速限的話……我全都要！」
接著我們回到 Postman，在「Params」裡面加入一個新的參數：
接著按下「Send」，我們來觀察回傳會有什麼變化。
跟之前的結果比起來，我們發現除了既有的屬性之外，多了一個「attributes」，裡面有一個 Key / Value 的組合， Key 是「SPEED_LIMITS_FCN」也就是我們要查詢的圖層，而 Value 是一個 Dictionary：
{
"FROM\_REF\_SPEED_LIMIT": "0", // 順向的道路速限
"TO\_REF\_SPEED_LIMIT": "50", // 逆向的道路速限
"SPEED\_LIMIT\_SOURCE": "1", // 速限的資料來源，1 代表速限標誌
"SPEED\_LIMIT\_UNIT": "K" // 速限單位，K 代表 KM（公里）
}
這邊您可能會覺得疑惑，什麼叫做「順向」、「逆向」？這邊要解釋一下，因為地圖的最基本元件就是「點」，點與點之間會連成「線」，而線跟線連接會組成「面」。例如下圖就解釋了如何使用 X 與 Y 座標呈現一個 2D 的點，接著用點連成線，再用線組成面。
而在 HERE 地圖中，所有的道路都屬於「線」，而一個線段一定會有兩端，HERE 的定義中，兩個點之間位在南邊的就叫做 Reference Node（參考點），而另一個點就叫做 Non-reference Node（非參考點）。
而有了參考點之後，就可以用參考點來表示道路的方向，例如：
以我們剛剛經過的這條道路，HERE 的 ID 為「786042585」，這個道路線段的南邊（後港街 181 巷）路口，就是 Reference Node（參考點）；而北邊（大南路）路口，就是 Non-reference Node（非參考點）。這邊要注意的是，雖然這個道路線段剛好呈現了一段完整的道路，但道路的線段可長可短，從數公尺到數公里都有可能，而一條道路通常會有相當多的線段（Link）組合而成。
承德路四段中央的分隔島把道路分成兩端，東側的是北上，而西側的是南下。LINK ID 為 786042585 的這段道路，是南下的道路，也就是 Non-reference Node 到 Reference Node，因此是屬於逆向；如果有一個道路線段呈現的是一條雙向的道路，那就會同時具有順向（Positive Direction）與逆向（Negative Direction）兩種方向。
但請注意，這條道路線段（Link）是單向的，不代表這條道路是單向的，因為就像圖中這條道路（承德路四段），是一條雙向的道路，但還是會因為道路的數化規則把東邊與西邊的道路分成兩條不同的線段，由一條順向與一條逆向的道路組成一個完整的雙向道路。
※ 數化（Digitization）：把現實的場景繪製成為數位地圖的點、線、面的過程。
以我們剛剛回傳的資料來說，其中的屬性 "linkIdMatched": -786042585，您可以注意到 ID 是負數，這裡就告訴您這個軌跡的方向是負向，因此您也會發現，因為這個道路線段（Link）只有一個方向，因此順向的道路速限 FROM_REF_SPEED_LIMIT 是 0，代表速限不存在；而逆向的道路速限 TO_REF_SPEED_LIMIT 是 50，代表 50 公里的速限。
我們現在拿到道路速限了，因此比較行駛的速度跟速限，就可以得知是否有超速的狀態了。從「TracePoints」中的「speedMps」值可以取出單位為「公尺 / 秒」的速度值，乘以 3.6 就可以換算成「公里 / 小時」。以第 0 個軌跡點 “speedMps”: 10.75 為例，換算成「公里 / 小時」的話就是 38.7 公里 / 小時，並沒有高於 50 公里 / 小時的速限，因此並未超速。
用相同的邏輯去比對 GPS 軌跡中的每一個點，就可以重現當時駕駛人的駕駛行為，並且找出超速的路段、時間，以下圖來說，就呈現了一個加速 -> 減速 -> 加速 -> 減速的過程。
當然，因為 HERE Route Matching 回傳的是 JSON 格式的文字檔，拿到這些文字之後，處理資料的邏輯就必須要由使用者自行撰寫，如果要討論到這部份，反而像是在教怎麼寫程式，因此這邊就不細談了。
以上就是 HERE Route Matching 的介紹。
快速建構地圖服務（一） - 認識 HERE Studio / Data Hub
快速建構地圖服務（二） - 認識 HERE Data Hub CLI / API
快速建構地圖服務（三） - 使用 QGIS 玩轉 HERE Data Hub
快速建構地圖服務（四） - 當 Leaflet JS 遇見 Data Hub
快速建構地圖服務（五） - 整合 HERE 地點搜尋 API
快速建構地圖服務（六）- HERE Waypoints Sequence 路徑最佳排序
快速建構地圖服務（七）- 認識 HERE Routing API - 路徑規劃
快速建構地圖服務（八）- 認識 Matrix Routing
快速建構地圖服務（九）- Isoline Routing
快速建構地圖服務（十）- HERE Tour Planning 物流路徑預排與成本精算
快速建構地圖服務（十一）- HERE Route Matching GPS 軌跡分析
快速建構地圖服務（十二）- HERE Custom Locations 地圖資料倉儲與查詢
快速建構地圖服務（十三）- HERE Geofencing 地理圍籬
快速建構地圖服務（十四）- HERE Custom Routes 自建路網 + Vector Tile 向量圖磚 + Map Image API 靜態地圖
快速建構地圖服務（十五）- HERE Positioning 網路定位服務
iThome鐵人賽
看影片追技術