同一次徒步，为什么两个 App 算出的下降不一样

简单说

总下降的算法跟爬升一模一样：把记录到的高度读数一个接一个地比，后一个比前一个低,就把差值累加进去。高度本来就是手机记录里抖动最厉害的一项，这份下降总数自然也继承了跟爬升同样的抖动，两个 App 处理这份抖动的方式也很少一致。除了这份普通的噪声，下降还多一个专属的麻烦：有的平台把「下降」当成每一段往下的变化累加起来的总数，跟爬升算法对称；另一些平台给出的其实更接近最高点和最低点的差。这是两个不一样的数字，混在一起说，才是差距变大的另一半原因。

影响爬升的那份抖动,这里也一样有

手机测出来的高度，本来就比经纬度抖得厉害，因为算高度用得上的卫星几何条件,天生就比算水平位置弱。有的设备和平台直接用原始 GPS 高度，有的靠气压传感器,能把短时间的抖动磨平一些,但会跟着天气在几个小时里慢慢漂移。不管走哪条路,把成千上万次微小的高度变化加总起来,这份抖动都会原封不动地带进最后的总数里。下降的算法跟爬升完全对称,只是方向反过来,所以到这一步为止,两个 App 在下降上对不上号,原因跟它们在爬升上对不上号是一回事。

下降特有的地方

爬升是大多数徒步和骑行平台都当成招牌数字来对待的量，所以各家的定义也大致统一：一段一段往上的变化累加起来的总数。下降就没这么统一了。偏登山向的 App，通常会像认真对待爬升那样认真对待下降，一段一段累加。而更偏向记一次运动、不那么强调路线本身的平台，有些给出的「下降」其实就是最高点和最低点的差——这确实是个说得通的数字，只是回答的是另一个问题，在一次徒步里爬升和下降不止发生一次的情况下，这个数字很可能比真正累加出来的总数小上不少。

打个比方，一次徒步中途插了一小段回升，前后两段下坡加起来一共下降了 300 米。按累加的算法，下降就是 300 米。按最高点减最低点的算法，除非最低点恰好出现在路线终点附近，否则这个数字会比 300 米小出一截。两个 App 都没算错，只是「下降」这个标签底下，各自回答的其实是不同的问题。

有些平台压根不把下降摆在明面上

不少平台会把爬升放在徒步总结页面最显眼的位置，下降却要点进更深一层的标签页,或者只出现在 CSV 导出里,甚至干脆没有。这跟数字对不上不是一回事——不是哪边算错了——但看起来的症状很像：两个 App 摆在一起打开，一个清清楚楚给出下降总数，另一个像是什么都没有，或者显示的其实是另一个数字,比如净高度变化,顶替了下降的位置。

高程修正对下降的影响和对爬升一样

有些平台压根不用设备实际记录到的高度，而是只拿每个点的经纬度，去地形数据库里查一次海拔，再用查出来的数值重新算爬升和下降,两个数字一起被换成了数据库的答案,而不是当天设备测到的值。经过高程修正的下降总数往往更平滑、更容易复现，因为它描述的是地面本身的形状，而不是带着天气和信号状况的一次实时读数——这也正是它跟另一个用原始高度算出来的总数会差出一截的原因。

实际该怎么办

• 先搞清楚两个数字到底在量什么，别急着认定哪个错了——一段一段累加出来的下降总数，和最高点减最低点的差，都是站得住脚的数字，只是回答的问题不一样。
• 看看这个平台的海拔数据是用设备的原始高度，还是用地形数据库查出来的——光是这一点，往往就能解释掉一大截差距。
• 比起拿一个数字去对另一个平台，更值得信的是自己在同一个 App 里、用同一套算法记录下来的一串往期路线。

TrailCam 的情况

TrailCam 为每条路线记录距离、行动时间、配速和爬升，回放路线时下方会显示海拔曲线，下坡的路段可以直接从曲线上看出来，而不是被压缩成另外一个单独的下降总数。路线可以导出成 GPX 1.1 或 CSV，里面带着的高度读数，跟其他平台自己算下降总数时会用到的是同一份数据。导出是可选的 TrailCam Pro 里的功能，App 本身免费下载。