同一趟健行，為什麼兩個 App 算出的爬升不一樣

簡單說

爬升不是一次量出來的數字，而是把一連串高度讀數裡每一次往上的變化加總出來的結果。而高度本身，恰恰是 GPS 裝置給出的所有數字裡最不精確的一個，抖動幅度比經緯度大出不少。同一趟健行，兩個 App 各自記錄，或者同一份記錄被兩個平台各自處理，起點的高度讀數可能不一樣，把多小的上下波動算作「真的在爬」這件事也判斷得不一樣，結果就是兩邊都說得通，數字卻離得不近。

高度天生就比位置測得粗

GPS 接收器靠比較天上多顆衛星訊號到達的時間差來算出自己的位置。這套辦法算水平位置比算高度準得多——能幫上水平定位的衛星散布在地平線四周，而對算高度真正有用的衛星往往偏向頭頂方向，同一時刻能用上的也更少。結果就是手機給出的原始 GPS 高度讀數，就算人站著不動，上下抖動的幅度也比水平位置大出好幾倍。用這份讀數的變化量累加出來的爬升總數，自然把這份抖動也一併繼承了下來。

兩種感測器，兩種誤差

有些裝置只靠 GPS 給出的高度，有些還會讀氣壓感測器——靠空氣壓力推算高度，而不是靠衛星，短時間內的高度變化通常比 GPS 追得更平滑。但氣壓讀數是相對值，需要一個起始海拔來校準，而幾個小時裡天氣本身的變化會改變同一個地點的氣壓，氣壓計沒辦法把這個和真的在爬坡區分開。同一條路線、同一台裝置，天氣平靜的一天和天氣正在轉變的一天，光是這一點，爬升總數就可能不一樣。

多小的波動才算「在爬」

就算高度讀數乾乾淨淨、只有一路來源，還有一個問題要決定：多小的上下波動該算進總數。什麼都不過濾，把每一次上升原封不動加起來，感測器本身的雜訊——升一公尺、又降半公尺，反覆上千次——就會把總數堆得遠超實際爬升，因為抖動加總起來很難自己抵消掉。過濾得太狠，把曲線抹得很平，或者只認變化幅度夠大的部分，那麼起伏地形上真實的小爬坡也會被當成雜訊一起丟掉。不同 App 在這道取捨題上停的位置不一樣，並沒有哪個設定是唯一正確答案，只是在容忍多少雜訊、和冒著丟掉多少真實爬升的風險之間，各自做了不同的選擇。

有些平台根本不用你記錄到的高度

不少平台壓根不用裝置記錄下來的高度，而是拿每個點的經緯度，去另一份地形資料庫裡查這個位置對應的海拔，再用查出來的數值算爬升，這就是常說的「高程校正」。因為地形資料庫不會像即時感測器那樣抖動，這麼算出來的總數往往更平滑、也更容易重現——但它描述的是這個座標點上地面本身的形狀，不是裝置走過去時實際測到的數值，和用原始高度算出的總數比起來，差出一截也不奇怪。

還有幾個悄悄影響數字的因素

• 「爬升」算的是只往上的那部分，還是最高點和最低點的差——這是兩個不同的數字，卻常常被混著說。
• 不同來源的地形資料庫精度不一樣，所以就算兩個平台用同樣的座標做高程校正，算出的數字也未必一致，不只是和原始 GPS 總數不一致。
• 在高樓密集或樹冠很厚的地方記錄的路線，GPS 高度會在原本就有的抖動之上再亂一層。
• 一台很久沒在戶外用過定位的裝置，氣壓計可能是從一個過時的基準點開始算的，導致整趟健行的高度讀數整體偏高或偏低一截。

實際該怎麼辦

不存在一個「真正的爬升」等著被更認真地找出來——高度本來就是這裡面抖動最厲害的讀數，每個 App 怎麼過濾這份抖動，有時候甚至要不要相信原始高度、還是乾脆信地形資料庫，都是各自合理的選擇。想讓自己的數字和朋友的 App 或者登山口牌子上寫的嚴絲合縫，其實是在追一個別人本來就沒用同樣辦法測出來的數字。真正有意義的比較，是拿這趟健行和自己用同一個 App 記錄的以往路線比——地面形狀變不了，但至少算法沒變。

TrailCam 會為每條路線記錄距離、行動時間、配速和爬升，回放路線時下方會顯示海拔曲線，讓你看到爬坡實際發生在哪裡，而不只是最後那一個總數。