20年9月14日(月) 晴
200915訂正：サムネイルのぼやけを改善しました。
200923訂正：グラフ④の位置が間違っていましたので、下にずらすとともに、
その位置に本来あるべきグラフ③-1を追加しました。
カシミール３Dではトラックやルートデータから、グラフ機能を使って山行の水平距離や時間、標高差を知ったり、推定することができます。
その場合上りは適正な値が得られますが、下りが多くなると時間が予期したより短くなることが多くなります。
開発者もそのことはご存じで、それ故推定値を求めるデータ（WalkComp）を開放して、自由に変更できるようにされています。
そこでそのデータを関数化してはどうかと考えました。
WalkCompのテキストデータは傾斜(%)と歩行速度(km/時)との関係を表したものです。
当初、その正の側はほぼそのままに、負の側を変更した関数はできないものかと考えました。
そこでまずWalkCompデータをグラフ表示しましすと以下のようになります。
| ＜①Kas3D傾斜：速度グラフ＞（カシミール3D使用） |
 |
これは見慣れた関数のどれにも似ていませんので、これをどう変更するかも思い付きません。
それで歩行速度の代わりに、その逆数を採ってみました。
| ＜②Kas3D傾斜：時間グラフ＞（カシミール3D使用） |
 |
速度の逆数は「単位水平距離(km)進むに要する時間(時)」になりますが、ここでは簡単のために「時間」と表記します。
それで傾斜と時間の関係をグラフ化しますと、傾斜が正の部分はきれいなカーブを描きます。
これは指数関数に似ていると思い、傾斜0と1（100%）の値をWalkCompに合わせた指数関数を求め、グラフ化しました。
驚いたことに、図のように傾斜が正の部分では、ほとんど重なっています。
| ＜③傾斜：時間比較グラフ＞（カシミール3D使用） |
 |
ただ負の部分は大きく外れていきます。
（大勢に影響しませんが、WalkCompでは傾斜-100%の速度が0.01になっていますが、グラフではこれを0.1に変更しています。したがってその部分の時間は10としています。）
実際には負の部分も絶対値と共にほぼ指数関数的に増加するのだろうと想像できます。
正負とも絶対値とともに指数関数的に増加する関数として思いつくのは、懸垂線（電線が撓んでいる形）つまり双曲線関数です。
そこでいろんな条件を付けて適当な双曲線関数を探すことにしました。
具体的には双曲線関数をy=a*e^(kx)+b*e^(-kx)+c とおいて、a, b, c, k を求めることです。
ただしx＝0のときy=1になり、a+b+c＝1になりますから、3つのパラメータを決めればよいことになります。
また傾斜0.3の場合、下り時間は上りの3分の2程度になり、傾斜0.9の場合Kas3Dの値に一致するなどの条件を用い、もう一つの条件は微調整で決めていきます。
こうやって探した結果、Kas3Dの正の部分に極めてよく合うものとして次の結果を得ました。（③-1 Kas3D to 双曲線）
こうして一応結果を得た訳ですが、ただ正の部分でKas3Dによく合い、いくつかの条件を満たすものを決めたというだけで、何ら実際の登山を反映していない安易なやり方だという点が問題です。
それで実際に歩いたときのGPSの結果から近似関数として双曲線間巣を指定してその形を決めようと考えました。
その結果得られた結果をグラフ化したものが以下です。（グラフ④ 双曲線近似グラフ）
ただこの方法にもいくつかの問題点がありました。
GPSデータの中には休憩などいくつかの不要なデータが含まれているため、それを取り除く必要があります。（カシミール3Dの「間引き」機能が有効でした）
またGPSデータは大きなエラーを含むことが多いので、それを取り除く必要があります。
そのためプログラムの中で除外条件を設定しました。
さらに双曲線関数を決めるのには、ステップデータ（隣接するトラックデータの差）をいくつかのブロックに分ける必要があり、そのため正確さが損なわれます。
また双曲線関数はエクセルでは用意されていないので、プログラムの中で4つのパラメータを決める必要があり、そのため1個のデータの処理だけで10数分の時間と監視のため中断するために手数がかかります。
グラフに付記していますようにブロックデータを２次曲線で近似したグラフも表示しました。
これは元のステップデータがあればエクセルを用いて直ちに表示することが出来ますし、双曲線近似と大差はありません。
それじゃーブロック化など面倒なことはせずにステップデータを基にして直接２次曲線近似を表示させれば簡単ではないかと思いました。
またその際エラー除外の条件も改善しました。
つまり得られたデータを再利用してエラーとして扱う範囲を訂正しました。
それを２度繰り返して最終結果としました。
そのようにして得られた結果の例が以下です。
上と同じ元データを用いています。
| ＜⑤２次曲線近似グラフ＞（カシミール3D使用） |
 |
しかしこのグラフで原点に向かう点列は何でしょうか。
ランダムな点データを期待していたのに、これは意外でした。
カシミールから書き出したデータは高さがm単位に丸められていますので、そのためでしょうか。
それとも人間活動の知られていない何らかの規則性に由来するものでしょうか。
試みにカシミールからの書き出しを用いないで編集データ（トラックファイルをダブルクリック）をコピーしてグラフを描いてみますと、古い機器を用いたものでは、同じような点列傾向が見られますが、最新のソフトを搭載した機器ではランダムな点の集合になりました。
次がその例です
＜⑥GPSデータによる２次関数近似＞
やはり点列は高さデータが、整数値かどうかは別として、丸められていたためだったようです。
はっきりさせるために調べてみました。
グラフの横軸は「傾き」、つまり「高度差/水平距離」、縦軸は「時間」、正確には「時間/水平距離」、従って原点からの勾配は (時間/水平距離)÷(高度差/水平距離)＝「時間/高度差」（単位高度差当りの時間）となります。
GPSデータは私の場合原則的に10秒間隔で取得していますので、高度差が整数値など丸められた値だとすると、勾配も丸められたとびとびの値になり、グラフは原点に向かう点列群の集まりとなるわけです。
ただ、全てそうなっていないのは、主として休憩時間を除くなどのためデータの「間引き」を行っているからです。
しかしGPSによる「高度」の精度を考えると１m未満の値は意味がないと考えられます。
従って結局ここでは処理が簡単なtrkデータを用いることとしました。
このようにしてカシミールデータから書き出したtrkデータを用いて2次関数を求め、それぞれの式の係数を平均化たものを求めました。
それらを表したグラフが以下です。
| ＜⑦傾き：時間グラフ（トレイル）＞（カシミール3D使用） |
 |
以上はトレイルについてですが、山行の行き帰りのロードついても調べてみました。
| ＜⑧傾き：時間グラフ（ロード）＞（カシミール3D使用） |
 |
ここでトレイルとロードでは傾斜0の場合の平均速度が大きく異なっていることに気づきました。
得られたデータではトレイルのはロードの約0.6倍です。
ロードでの速度は各人その大体の値は把握していると思われますが、トレイルでの傾斜0の速度を知っている人はあるでしょうか。
そこで基準としてはロードでの平均速度を用いるべきだと思いました。
ただし登山と同じ装備と荷重で歩いた場合の値です。
空荷で歩いた場合の体重を体重に荷重加えた値で割ったものを掛ければおおよその値を知ることが出来ます。
つまり 「平地での速度(ロード)」＝「空荷での平地速度(ロード)」×「体重÷(体重＋荷重)」
このようにしてロード平均データで空荷での平地速度を1としたときのトレイル所要時間を求めました。それを示すグラフが以下です。（参考までにKas3Dのデータを2次曲線近似したものも含まれています。）
| ＜⑨傾き：時間グラフ（トレイル・標準化byロード）＞（カシミール3D使用） |
 |
さらにトレイル・ロードの平均データから時間の逆数を求めてWalkCompの代わりに用いることの出来るテキストデータを求めました。
トレイルテキストは WalkCompTrail.txt
ロードテキストは WalkCompRoad.txt
リンク先を右クリックして名前をつけて保存し、WalkComp.txtの入っているKashmirフォルダに貼り付けて追加すれば、Kas3Dソフトの中の「グラフ表示」の中の「設定」で「補正ファイル読み込み」から使うことが出来ます。
その際、元のWalkComp.txtは削除しないでください。
使用に際しては、トレイルとロードは分けて、トレイルでは～Trail.txtを、ロードでは～Road.txtを用います。
いずれの場合も「平地での速度」は上述の「平地での速度(ロード)」を用います。
元より使用したデータは私個人（同伴者を含む場合あり）のものですが、最終的には個人的な歩行速度は反映されていません。
しかし山行には個人によってスタイルが異なり、上りに意欲を示して速い人、逆に下りが得意な人などがあります。
それ故得られた結果ひには必ずしも一般性はありません。（下線部訂正200915）
また平均する前のグラフから分かりますように、山によっては平均からかなりずれるものもあります。
ご使用されての結果について責任は負えませんので、あくまでご参考まで。
