怎么算出一年一共爬升了多少

简单说

把记录的历史导出成 CSV，用表格软件打开，把爬升那一列加起来，方法跟加距离完全一样。如果导出的数据把徒步和跑步、骑行混在一起，先按活动类型筛一下，总数就只算徒步的部分。整个流程跟算年度距离总数一模一样，唯一的区别是加的是哪一列。

为什么一旦开始累加，爬升的表现就跟距离不一样了

单次徒步的爬升不是从山顶标牌上读出来的数字，而是把记录下来的每个点跟前一个点的高度做比较，只把升高的部分一段段加起来，降低的部分则忽略不计，这样算出来的。GPS 测高度比测位置抖得多，因为用来算高度的那部分卫星几何关系，天生就不如算平面位置时那么有利。这份抖动会让读数在实际高度没变的时候也微微上下晃动，而累加只数「升高」这一半的比较结果，这份抖动就不会平均抵消到零——它会在每次徒步里都把总数往高的方向轻轻推一点。

距离没有这个毛病。GPS 测位置比测高度准，位置上的小抖动放到一整段路线里，大体上会互相抵消，不会往一个方向堆积。也就是说，年度距离总数加的是一串本身比较稳的数字，而年度爬升总数加的是一串每次都轻微偏向一边的数字。两个总数都没算错，只是爬升这个总数用的原料本来就没那么稳，而且徒步次数越多、放进同一个年度总数里，这份不稳就越明显。

这意味着什么，又不意味着什么

这不代表年度爬升总数该被怀疑或者扔掉。一整年真实的爬升——一整个夏天走的山脊、来回爬的之字坡——远远超过每次徒步那点小噪声，就跟单次徒步的真实爬升远远超过噪声一样。真正的意思是，年度爬升总数更适合当作一个靠谱的大概数，而不是精确到几十米去比较的数字，也不太适合用来判定两个数字很接近的年份到底哪一年爬得更多。

另外，如果 App 之后重新计算了旧的记录，再导出一次，年度总数也可能会有点变化；跟另一个 App 导出同一份历史比，数字也可能对不上——不是数据丢了，而是爬升本来就是一种估算，对同一份带噪声的输入，不同的估算方式给出的答案本来就不会完全一样。同一次徒步在不同 App 里爬升不一样的那份指南，讲的就是同一个道理，只是发生在更小的尺度上。

把总数算出来，再切出有用的部分

把这一列加起来

不管是 Excel、Numbers 还是 Google 表格，对着爬升那一列用一个 SUM，二十次徒步还是两百次徒步都一次加完。只要年度的粗略总数，不用先拆分什么。

按活动类型或月份筛出一部分

在活动类型那一列筛一下，就能把徒步从同一份历史里单独挑出来，不管里面还混着多少次骑行或跑步；在日期那一列筛选，用同一张表、同一列总数就能缩小到某个季度或某个月。

排序，找出真正在爬升的那几天

按爬升给这些行排序，而不是直接加总，能一眼看出全年大部分爬升是哪几次徒步贡献的——通常是少数几次又长又陡的日子，而不是均匀分摊在每一次出行里。这个分布往往比总数本身更值得留意。

容易想岔的地方

• 指望年度爬升总数跟年度距离总数一样精确——两者用的原始数据质量不一样，爬升不管是单次还是全年累加，本来就是抖动更大的那一个。
• 重新导出同一年份，发现总数跟之前不太一样就觉得奇怪——那是同一个估算被重新算了一遍，不是数据不见了。
• 两个年份的总数很接近，就想靠它去判定到底哪一年爬得更多——这份差距很可能落在噪声范围内，不一定是真实爬升的差别。
• 不导出汇总，靠肉眼把一条条记录加起来——几十个数字靠心算相加，出错的概率远比爬升本身那点噪声要高得多。

TrailCam 能做什么

TrailCam 可以一次操作把整段轨迹历史导出成一个 CSV 文件，爬升跟距离、时长、配速一样按每次徒步算好，每一行还带着活动类型，只算徒步的总数靠筛选就能做到。要是哪天真需要路线本身的形状，同一段历史也能导成 GPX 1.1。导出功能属于可选的 TrailCam Pro，App 本身免费下载。