MaxLimit計算

MaxLimit計算は、個人的に混迷を極めている(?)分野なので、整理したいと思ってこのページを書きました。

MaxLimit計算の導入のモチベーション

山行の計画があまりに山深くまで行くことがあると、アクシデントが起きた時、例えば蛇にかまれたり怪我をしたりしたとき無事に下山することができなくなる。

そこで、ワンゲルでは夏山ではMax12p、冬山ではMax10pという制限があり、山行が計画されているどの場所でも12p以内もしくは10p以内に下山できなければならない。

このルールが守られているか保証するのがMaxLimit計算であり、ついでにいつまでに降り始めれば日没に間に合うのかも計算する(必要かどうかはさておき)

従来のMaxLimit計算

従来のMaxLimit計算は、以下のプロセスで行われている。

1. 各ピンについて、そこから出ているすべての方向について最短で下山する時間を調べる

2. 上述した方向のうち、2番目に早い下山方法でかかる時間(これを簡便のため第2下山時間という)を調べ、その極小値となるピンをMaxとする。また、"ORでピストンするようなとがっている場所"については、MaxORとする。

3. そのMax、MaxORについて、第1下山時間と第2下山時間のうち、林道区間を抜いて長いほうを"下山にかかる時間"とし、その値がMax12pもしくはMax10pを超えていないかどうか計算する。必要に応じて、この"下山にかかる時間"を用いて、日没関連の計算をする。

上のような状況での、上のプロセスを当てはめると、

1. 下山にかかる時間は、地点Aで、右:110、左:70、地点Bで、右:60、左120

2. 第2下山時間は、地点Aが110、地点Bが120なので、地点AがMax

3. 今回は、すべて林道でないとして、"下山にかかる時間"は110

従来の計算法の問題点

そんなこんなで従来の計算法が行われてきたが、いろいろと問題がある気がしてきた。

第2下山時間の極小値

第2下山時間の極小値という定義は、明らかにMaxでない場所がMaxになってしまう。

上図のような状況を考えると、第2下山時間は、地点Aが60、地点Bが110となるので、地点AがMax、地点BがMaxORとなるが、常識的に考えると明らかに地点AはMaxではない。

一応この問題は第1下山時間の極大値にすれば解決する。

Max12pを担保できていない

そもそもこの計算方法では、Max12pを担保できていない。

上図のような状況を考えると、地点Aは第1下山時間が10、第2下山時間が30となり、地点Bは、第1下山時間が20、第2下山時間が20となるため、地点BがMaxである。これは、定義を変えて第1下山時間の極大値としても地点BがMaxであることは変わらない。そのため、"下山にかかる時間"は、20である。

しかし、この図で最も下山に時間がかかるのは、500かかる地点Aと末端との間であり、それは明らかに20より大きい。これは、少し極端な図だが、このようにMax12pを保証できていない例が多くある。特にERが長かったりすると、計算からのずれが大きくなる。

ピンの頻度によって変わるMax

ピンの数が少ないと、実際にかかる時間よりもMaxが大きくなることがあり、そのためにLはよく、Max用のピンを打って探さなければならず、なかなかうっとうしい。

ループ上の場所での問題

沢や岩では、登ることはできるが下ることはできないといった場所がよくあるが、こういった場合うまく計算できない。

林道の取り扱い

林道を含めてMaxの位置を探すわりに、"下山にかかる時間"には林道を含めないため、よくわからんことになっている。

新定義

以上の問題を解決するために、ここに新定義を提案する。

新定義は、下山するのにかかる時間(ただし林道区間の時間は除く)の極大値となる場所(※)をMaxとする。ただし、従来ピン上にしか設定しなかったMaxをルート上にもとる。ルート上における時間の計算は、ピッチを比に従って適当に分割する。

]]

新定義に従って、上図のMaxを調べると、Maxは、地点Aから245下った地点であり、下山にかかる時間は255となる。

※(正確には極限をとると局所的supになる場所だが、最大値と考えて間違いはない)

問題点

この新定義の最大の問題点は、計算に結構手間がかかることである。しかし、装備管理システムに計算ツールをのっけて、この新定義に基づく計算を実装しているので、たぶん面倒くさくはないはず。

というか、もときに言われて気づいたがこっちの定義のほうが計算が楽そう。(なぜなら、末端からピンに時間を書いて、上流に向けてたどっていけば必然的に最短の値が出る。)