怎么从 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 本身免费下载。