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

簡單說

總下降的算法跟爬升一模一樣：把記錄到的高度讀數一個接一個地比，後一個比前一個低，就把差值累加進去。高度本來就是手機記錄裡抖動最厲害的一項，這份下降總數自然也繼承了跟爬升同樣的抖動，兩個 App 處理這份抖動的方式也很少一致。除了這份普通的雜訊，下降還多一個專屬的麻煩：有的平台把「下降」當成每一段往下的變化累加起來的總數，跟爬升算法對稱；另一些平台給出的其實更接近最高點和最低點的差。這是兩個不一樣的數字，混在一起說，才是差距變大的另一半原因。

影響爬升的那份抖動，這裡也一樣有

手機測出來的高度，本來就比經緯度抖得厲害，因為算高度用得上的衛星幾何條件，天生就比算水平位置弱。有的裝置和平台直接用原始 GPS 高度，有的靠氣壓感測器，能把短時間的抖動磨平一些，但會跟著天氣在幾個小時裡慢慢漂移。不管走哪條路，把成千上萬次微小的高度變化加總起來，這份抖動都會原封不動地帶進最後的總數裡。下降的算法跟爬升完全對稱，只是方向反過來，所以到這一步為止，兩個 App 在下降上對不上號，原因跟它們在爬升上對不上號是同一回事。

下降特有的地方

爬升是大多數健行和騎行平台都當成招牌數字來對待的量，所以各家的定義也大致統一：一段一段往上的變化累加起來的總數。下降就沒這麼統一了。偏登山向的 App，通常會像認真對待爬升那樣認真對待下降，一段一段累加。而更偏向記一次運動、不那麼強調路線本身的平台，有些給出的「下降」其實就是最高點和最低點的差——這確實是個說得通的數字，只是回答的是另一個問題，在一趟健行裡爬升和下降不只發生一次的情況下，這個數字很可能比真正累加出來的總數小上不少。

打個比方，一趟健行中途插了一小段回升，前後兩段下坡加起來一共下降了 300 公尺。按累加的算法，下降就是 300 公尺。按最高點減最低點的算法，除非最低點恰好出現在路線終點附近，否則這個數字會比 300 公尺小出一截。兩個 App 都沒算錯，只是「下降」這個標籤底下，各自回答的其實是不同的問題。

有些平台根本不把下降擺在明面上

不少平台會把爬升放在健行總結頁面最顯眼的位置，下降卻要點進更深一層的標籤頁，或者只出現在 CSV 匯出裡，甚至乾脆沒有。這跟數字對不上不是一回事——不是哪邊算錯了——但看起來的症狀很像：兩個 App 擺在一起打開，一個清清楚楚給出下降總數，另一個像是什麼都沒有，或者顯示的其實是另一個數字，例如淨高度變化，頂替了下降的位置。

高程校正對下降的影響跟對爬升一樣

有些平台壓根不用裝置實際記錄到的高度，而是只拿每個點的經緯度，去地形資料庫裡查一次海拔，再用查出來的數值重新算爬升和下降，兩個數字一起被換成了資料庫的答案，而不是當天裝置測到的值。經過高程校正的下降總數往往更平滑、更容易重現，因為它描述的是地面本身的形狀，而不是帶著天氣和訊號狀況的一次即時讀數——這也正是它跟另一個用原始高度算出來的總數會差出一截的原因。

實際該怎麼辦

• 先搞清楚兩個數字到底在量什麼，別急著認定哪個錯了——一段一段累加出來的下降總數，和最高點減最低點的差，都是站得住腳的數字，只是回答的問題不一樣。
• 看看這個平台的海拔資料是用裝置的原始高度，還是用地形資料庫查出來的——光是這一點，往往就能解釋掉一大截差距。
• 比起拿一個數字去對另一個平台，更值得信的是自己在同一個 App 裡、用同一套算法記錄下來的一串以往路線。

TrailCam 的情況

TrailCam 為每條路線記錄距離、行動時間、配速和爬升，回放路線時下方會顯示海拔曲線，下坡的路段可以直接從曲線上看出來，而不是被壓縮成另外一個單獨的下降總數。路線可以匯出成 GPX 1.1 或 CSV，裡面帶著的高度讀數，跟其他平台自己算下降總數時會用到的是同一份資料。匯出是可選的 TrailCam Pro 裡的功能，App 本身免費下載。