GPX 與 polyline：軌跡資料哪個更適合健行

polyline 究竟是什麼

大多數人碰到的 polyline，是 Google 的 Encoded Polyline Algorithm Format，也是大多數需要在回應裡把路線形狀傳回來的地圖與路線規劃 API 用的同一套方案。它接收一串經緯度座標，把每個座標四捨五入到小數點後五位，只保存跟上一個點的差值而不是座標本身，再用一套類似 base64 的字元集把結果壓進一小段 ASCII 字元裡。一條按原始座標存放可能要好幾 KB 的路線，編碼成 polyline 後可能只剩幾百個字元。

這段字串本來就不是設計來單獨打開、閱讀或保存的。它存在的意義是在一次 JSON 回應或 URL 參數裡跑一趟，被畫地圖的那一端解碼回座標清單，地圖畫出來之後就沒用了，可以丟掉。它是路上的一個形狀，不是一份記錄。

GPX 裝得下、polyline 卻沒地方放的東西

GPX 的軌跡點除了位置之外，還帶著時間戳與海拔，有些裝置還會在 extensions 裡塞進 GPS 精度之類的額外欄位。這些東西 polyline 一樣都裝不下，因為這個格式從一開始就只回答一個問題——這條線經過哪裡，其他一概不管。把時間戳從一次健行裡拿掉，就沒辦法算出走了多久、哪個時刻的配速是多少、哪一段是移動時間、哪一段是停下來。把海拔拿掉，就沒有了爬升曲線，沒有上升也沒有下降。polyline 回答的只是「去了哪裡」，「什麼時候」與「爬了多高」它一句都沒提。

精度也被一併捨掉了

標準 polyline 編碼裡內建的五位小數四捨五入，本身就是一個小小的、故意做出的取捨——在赤道附近大約相當於一公尺的精度，換來的是它服務的那些 API 回應主要是為了在螢幕上畫一條線，而不是為了精確測量一條路線。這筆交易在 polyline 實際被用到的場景裡是划算的。但一旦目的從「把路線畫出來」變成「把路線量出來」，這筆交易就不再成立——而這正是一條地圖上的線，變成一次想要真實距離與海拔數字的健行時，發生的轉變。

擺在一起比較

• 結構：GPX 是完整的文件，每個點各自帶著時間戳與海拔；polyline 是一整段沒有時間戳、也沒有海拔的編碼字串。
• 來源：GPX 是 2002 年發布的開放格式，為 GPS 裝置而設計；編碼 polyline 格式是 Google 為自家 Maps API 發布的，目的是讓 API 回應裡的路線形狀盡量小。
• 相容性：幾乎所有為讀取軌跡檔而做的地圖、GIS、GPS 工具都能打開 GPX；polyline 得先有專門針對這套編碼寫的解碼器，才能變成能用的東西。
• 適合場景：想保留、想測量、想匯入其他工具的健行用 GPX；在伺服器與地圖之間暫時傳一下路線形狀用 polyline。
• 可讀性：GPX 是純文字 XML，肉眼就能讀；polyline 是一串不透明的字元，就算準確無誤，不解碼也看不出任何意義。

兩者互相轉換

把 GPX 軌跡轉成 polyline 是單向的。不少函式庫和線上工具能讀出 GPX 檔案裡的座標，把它們編碼成 polyline 字串，但讓 GPX 檔案適合用來回顧一次健行的那些東西——時間戳、海拔、逐點的細節——在目標格式裡根本沒地方放，只能被丟在半路。轉換出來的東西畫的是同一個形狀，僅此而已。

反過來轉更糟，因為已經沒什麼可丟了。把 polyline 解碼回座標，得到的只是一串光禿禿的經緯度，因為本來就沒存過任何時間戳或海拔。想從這裡再拼出一個 GPX 檔案，做的就不是找回遺失的東西，而是憑空造出缺的那部分——比如沿著這條線均勻地編幾個假時間戳——做出來的檔案看起來像一次記錄，其實並不是。

TrailCam 匯出什麼格式

TrailCam 把記錄下來的路線匯出成 GPX 1.1 或者 CSV 彙總，兩種格式都會在每個點上保留時間戳與海拔，而不是把一次健行壓縮成一個光禿禿的形狀。對於想事後回顧、匯入其他工具，或者當成一份真正的記錄留著，而不是某張地圖曾經畫過的一條線的健行來說，這個差別很重要。GPX 與 CSV 匯出屬於可選的 TrailCam Pro，App 本身免費下載。