怎麼從 GPX 檔案裡找出一趟健行最陡的那一段

先說結論

按順序走過軌跡上的點，不要只算一次全程的坡度，而是把路線切成一段段又短又重疊的區間——比如每走滿 20 到 50 公尺就切一段，而不是每兩個相鄰點就算一次。每一段都拿海拔變化除以這段的距離，算法跟算整趟坡度時完全一樣。坡度最高的那一段，就是這條路線最陡的地方。算這個所需要的海拔和距離數字，本來就已經在檔案裡了，一條標準 GPX 軌跡不需要為此額外記錄什麼。

為什麼一個平均坡度回答不了這個問題

平均坡度是用累計爬升除以總距離算出來的，這個算法本身就把整趟健行當成了以同一個恆定速率一路爬升。一條路線如果是平緩的接近段、一小段陡坡，再加上後面比較緩的稜線，整體平均下來可能只有不起眼卻完全誠實的 8%，可單把那一小段陡坡拎出來，按幾十公尺算，坡度可能逼近 30%。平均數沒有說謊，它只是在回答另一個問題，而不是「哪裡變陡了」——盯著從全程裡抽出來的這一個數字看再久，都不會替你回答第二個問題。

像算配速那樣把健行切成每公里或每英里的分段，也會遇到程度輕一些的同樣問題。一小段又短又陡的爬坡，就算落在整體還算平緩的某一公里裡，照樣會跟這一公里的其他部分混在一起——只不過被稀釋的範圍從整趟健行縮小到了這一公里而已。真要找出最陡的那一小段，就得用一個短到真陡坡藏不進去的單位去看。

GPX 檔案裡已經有的材料

一條 GPX 軌跡就是一串按順序排列的點，每個點帶著經緯度，通常還有海拔和時間戳。這跟健行記錄裡顯示的總距離、累計爬升、平均配速、平均坡度這些數字背後的原始材料完全是同一份——它們都不是作為現成數字存在檔案裡的，而是每次都從這同一串點重新算出來的。路線某一小段的坡度，也不過是這串點能算出的又一個數字，用得到的只是連續幾個點的海拔和距離，其他都不需要。

唯一的坑：相鄰兩點之間的海拔雜訊太大，不能直接拿來用

海拔是手機記錄裡雜訊最大的一個數字，比定位還要晃。如果只拿相鄰兩個點來算坡度——這兩點往往只隔幾公尺，記錄時間也只差幾秒——一段實際上根本沒怎麼爬升的平地，也可能因為其中一個海拔讀數剛好偏高了幾公尺、下一個又剛好偏低了幾公尺，突然冒出 30% 甚至 40% 的坡度。要是不處理這種情況，這一小段純屬雜訊的「陡坡」反而會蓋過檔案裡所有真實的爬升，被誤判成「全程最陡」。

把區間放寬到一個固定距離——通常 20 到 50 公尺就夠——基本能解決這個問題：這樣算出來的是一段真實的海拔變化除以夠長的距離，兩端各自幾公尺的雜訊幾乎撼動不了結果，而一段真正持續 50 公尺以上的陡坡，依然能清清楚楚地顯現出來。區間切得太窄，雜訊就會贏；切得太寬，一小段真陡坡又會被周圍比較緩的地面稀釋掉，跟按公里分段時一樣的問題。真正合適的寬度，落在這兩者中間，既能讓一小段真實的陡坡露出來，又不至於被雜訊騙。

拿真實數字算一遍

假設一條軌跡大約每 5 公尺記一個點。某段 40 公尺的區間裡，海拔從 210 公尺升到 214 公尺——40 公尺爬升 4 公尺，坡度 10%。緊接著下一段 40 公尺，海拔從 214 公尺升到 226 公尺——40 公尺爬升 12 公尺，坡度 30%。再往前走，接下來那段 40 公尺只爬升了 2 公尺，坡度又降回 5%。中間那段 30% 的區間，就是這條路線最陡的地方——要是沒人去看比全程更短的區間，它本來會安安靜靜地被埋在這段爬升 12% 到 15% 左右的整體平均數裡，誰也看不出來。

TrailCam 能幫上什麼

TrailCam 會在回放路線的地圖下面畫出高度剖面圖，一小段又短又陡的爬坡會直接顯示成曲線上變陡的那一截，而不是被整趟健行的一個平均坡度蓋住。想自己動手跑上面這套算法的人，路線可以匯出成 GPX 1.1 或 CSV，記錄下的每一個點都完整保留，正好是這個方法需要的原始材料。匯出功能包含在可選的 TrailCam Pro 裡，App 本身免費下載。