短くて急な登りをこなしたのに、獲得標高がほとんど増えないのはなぜか

まず結論

獲得標高は、センサーの値をそのまま読み取ったものではありません。一連の高度データを足し合わせて作られており、積算される前に、平らな地面での普通の揺れがそのまま偽の登りにならないよう、何らかのノイズフィルタを通されます。このフィルタは、信号のどこが本物の高さの変化で、どこが単なるセンサーのノイズかを推測する仕組みで、たいていは「狭くて急な変化」をひとまず疑ってかかることで区別しています。岩場のひと登りや短いよじ登り、数歩で終わる急な上りも、まさに「狭くて急」です。その一部はノイズと一緒に均されてしまうことがあり、これが、脚の記憶よりも合計が小さく感じられる理由です。

生の高度データの中で、短く急な登りはどう見えるか

獲得標高を出すアプリはどれも、軌跡上のほぼすべての点に高度の値が一つずつ付いた、同じ種類の元データから計算しています。ゆるやかに長く続く坂は、そのデータの中では何十点、何百点にもわたって少しずつ標高が上がり続ける形で現れます。短く急な登りはまったく違う形になります——数点だけ一気に値が跳ね上がり、そのあとすぐに地面が平らになって、値もすぐ元の高さで落ち着きます。地面が実際にどうだったかという情報抜きに、データの形だけを見ると、この狭いスパイクは、平らな地面で普通の GPS や気圧センサーのノイズが作る、短く鋭い揺れと見分けがつきにくいのです。

平坦な道を守るフィルタが、急な登りの代償にもなる理由

どのアプリも、積算する前に高度データへ何らかのフィルタをかけなければなりません。そうしないと、まったく平らな道を歩いただけで、センサーのゆらぎだけで何十メートルもの獲得標高がついてしまいます。このフィルタは、たいてい狭くて急な変化をひとまず疑うことで働きます。二、三点しか続かない上下の揺れを無視したり、データを均して、短いスパイクをその前後の平らな部分に近づけて引き下げたりする、といった具合です。平らな地面での本物の揺れに対しては、これはまったく正しい処理です。問題は、短く急な登りも同じスパイクの形をしているということです。だから、平坦な道を丘に見せないのと同じ平滑化が、合計に届くより前に、本物の鋭い登りの一部まで丸めてしまいます。

ゆるやかで長い登りが、同じようには削られない理由

ゆるやかに長い距離をかけて続く登りは、アプリが使っている平滑化の幅に対して十分に「広い」ので、フィルタが触れるのは登り始めと登り終わりの両端くらいで、その間の長く安定した上りにはほとんど手が入りません。短く急な登りは、幅の点でフィルタが取り除こうとしているノイズにずっと近いので、より大きな割合がその同じ幅の中に収まってしまいます。同じだけの高さを登った二つの登りが、最終的な合計にまったく違う量しか反映されないことがありますが、それはどちらかがより正確に測られたからではなく、それぞれがどれくらいの時間をかけて登られたか、その違いによるものです。

こういうときは見直してみる価値がある

• 本物の高さを登ったと確信している岩場やよじ登りが、高度プロフィールにほとんど現れず、その前後にあるゆるやかな区間ははっきり見える——これはここまで説明してきた通常のパターンで、記録に何か問題があるわけではありません。
• 短く急な登りがいくつも続くハイキングが、同じくらいの高さを登った一本のゆるやかな長い登りより、はっきり低い合計で終わる——同じ理由で起こりうることで、形の違う二つのルートを獲得標高だけで比べるときに覚えておく価値があります。
• よじ登った場所を覚えているちょうどその地点で、高度プロフィールの線に短く急な跳ね上がりが見える——これは合計には十分反映されなくても、記録されたデータそのものには本物の登りが残っている、ということです。
• 体感と合計の差が大きく、しかもその登りが実際には短くなく長かった場合——それはこのフィルタの効果ではうまく説明できないパターンなので、別の原因を考える価値があります。

TrailCam との関係

TrailCam は、記録中もリプレイのときも、すべてのルートについて獲得標高を地図の下の高度プロフィールとして表示するので、短く鋭い登りも、最後の合計値だけでなく線そのもので直接確かめられます。このプロフィールと合計値は、ルートを GPX 1.1 や CSV で書き出すときにもどちらも含まれます（GPX 1.1 / CSV 書き出しは任意の TrailCam Pro に含まれる機能です）。アプリ自体のダウンロードは無料です。