インコがやって来た

我が家に何代目かのインコがやって来た。
こんどのは黄色。

先ずは自己紹介します。
「ぼく（わたし？）、生まれて1ヶ月です」
「時々このページで成長ぶりをお見せしたいと思います」
「よろしくお願いします」

栗ひろい

今年の栗拾いも先週の金曜日で最後にした。
先月の下旬ごろからほとんど毎日どこかの山に出かけて栗拾いをした。今年もずいぶん拾った。

最近はどこの山も、クマやイノシシの出没が報道されているが、栗拾いに行く里山もイノシシの足跡や食痕や「ヌタバ」が目立った。
イノシシのけもの道を辿って行くと、たいがい栗の木の下へ導かれた。

毎回3kg位は拾った。
そんなに拾ってどうするの？　と思われるかも知れないが、茹でて私達や孫たちが食べる。
妻はせっせと皮をむいて、冷凍保存する。
それを、次の年の秋口まで、ときどき冷蔵庫から出して、栗ご飯や炊き込みご飯に入れる。
孫たちが「お婆ちゃんちのご飯は美味しい！」って言ってくれるのが嬉しくて、妻はせっせと皮を剥く。

最近、里に熊やイノシシが出没して、ニュースになる。
TVなどでは栗やブナの実が不作だから・・・と言っているが、確かにそれもあるかも知れないが、本当の原因はもっと別のところにあると思っている。

木の実の豊作・不作は、何も今に始まったことではない。
大昔から、そんなことはあったはずだ。
ブナの実は7年周期で、大豊作になるらしい。自然観察会で習った。
不作の年は殆どを動物に食べられてしまっても、7年毎に大豊作になるので、その年に次の世代の苗を発芽できるそうだ。
自然は動物に食べられてしまうことまで織り込み済みらしい。
何万年も昔からこのようなことが繰り返されてきたわけだ。

私が子供の頃より動物の数が激増したとも思えないが、最近は私が生まれ育った村でも昔より里に出てくる大型動物が増えたらしい。
これは、ある学者の話では、昔は山を生活の場として、薪炭を生産したり、木の実や山菜を取ったり、人々が山に入っていろいろ作業をしたり手入れをしてきた。
つまり、家や畑のある「里」とその近隣の「里山」と、滅多に人が入らない「奥山」とに分かれていた。
しかし最近は山を生活の場とし利用することがなくなり、山は荒れ放題。
緩衝地帯としての「里山」がなくなり、民家の後ろはすぐ「奥山」と同じ環境になってしまったので、動物は奥山と里山の区別がつかなくなり戸惑っているのではないかと言うことだ。

その意味でも、里山にはせっせと人が入って、人間の気配を残し、里山には動物のエサはない状態にして、お互いの生活の場を区別する緩衝地帯をはっきりさせる必要があると思う。
クマやイノシシが出たというニュースが報道されると、立ち入り禁止になったり、立ち入りを自粛したりしたのでは、ますます動物のテリトリーになってしまうのではないかと思う。
逆効果だ。
動物が出たところは、手入れされた「里山」にしなくてはならない。
奥山に動物のエサになる「実がなる木」を植えると同時に、「里山」には、もっと人が入り、手入れをしたり、生活に利用するようにしなければ、動物が里に出没することはなくならないと思う。

江戸時代や明治時代は、おそらく動物の数は今以上に多かったのではないかと思う。
それでも人々は人気の少ない峠道を旅したはずだ。
熊やイノシシに出くわすことも多かったはずだが、今ほど大騒ぎはしなかったのではないかと思う。
もちろん、立ち入り禁止にしたりはしなかったはずだ。
動物と人間がお互いの生活の場を分ける知恵があったのではないかと思う。
動物にとっては「奥山」の方が安心して暮らせる場所のはずだ。その奥山に留まっていてくれるようにしなければならない。
むやみに奥山に無駄な林道を作ったり、植えただけで放置するスギの植林をしたりしないでほしい。

ある自然保護団体の機関誌に「林野庁（旧営林省）がなかったら、日本の森林はもっと守られていた」と書いてあったのを読んだことがある。
営林署は予算獲得のために、国有林を伐採し、スギを無駄に植える事業をしてきたと書いてあった。
確かに、山を歩いてみると、殆ど植えっぱなしの状態で放置されているスギ林がある。
国有林伐採には、大規模な林道を山奥にまで通している。
これは全部税金だ。

豊かな雑木林は保水能力も高く、そこから流れ出た水は海の魚をも育てると聞いたことがある。
役所の予算獲得のために、無駄な林道を作り、貴重な奥山を伐採し、植えっぱなしのスギを植林し、日本の豊かで多様性に富んだ森を荒廃させたのは行政そのものではないかと思う。
林野庁がなかったら、あるいはもっと日本の山は豊かだったのかも知れない？？

HP自動作成ツール

清水北山好会（http://sksanko.sakura.ne.jp/index.html）のホームページ担当になったので、会員が登った山の紹介と登山地図を作成しアップしている。
この作業は一度作ってしまえば、後は毎回同じことの繰り返しになる。
同じ作業を繰り返していると、自動化したくなるのは誰しも同じだと思う。

１．GPSログをカシミールなどの地図ソフトを使って、パソコンにダウンロードする。
２．ダウンロードしたGPSデータをGPX形式で書き出す。
３．ダウンロードしたGPSデータを基に登山グラグを描き保存する。
４．書き出したGPXデータを基に、GoogleMapと電子国土Mapを作成し、地図ページを作る。
５．GoogleMapの撮影ポイント用の画像を800×600ピクセルにリサイズする。
６．３番で保存したグラフをBMPからGIF画像にフォーマット変換し、トリミングする。
７．５番と６番で加工した画像を所定のフォルダにコピーする。
８．活動報告ページに、4番の地図ページへのリンクを追加する。
９．リンクが10個になったら、新しい「活動報告」ページを追加する。
10．古い「活動報告」のページ番号を1番ずつ繰り上げる。リンクURLも修正する。

今回は４番から10番までの単純作業を自動化した。
そこで、先ずは上記５番〜７番の画像リサイズ・フォーマット変換・トリミング・コピーの作業をするための画像加工ソフトをネットで探した。
スクリプトの中から実行したいので、GUIで操作するものではなく、コマンドラインから実行できるものを探したが、なかなか適当なものが見つからなかった。

１．コマンドラインから実行可能なもの
２．PCにインストールして使うものでなく、EXEファイルをその都度実行するもの
３．リサイズ・フォーマト変換・コピーは必須
４．縦位置・横位置に対応できるよう、長辺を指定サイズにリサイズできるもの。
５．出力フォルダ、出力ファイル名は自由に設定できるもの。
６．できればフリーソフト。有料でも1000円以下であること。

以上の条件を満足するものは見つからなかったが、４番以外は満足するものに「photoshifter」があった。
その他では「縮小専用」というフリーソフトもあったが、5番を満足しないのと、Windows7 での使用例報告が不安定だったので「photoshifter」に決定。
これには、詳しい「機能一覧」「設定法」「コマンドラインから実行する場合の使用法」が書いてあるページが付いていた。
http://www.h4.dion.ne.jp/~fht/software/photoshifter.html
使用法には「複数指定可能」となっていたが、その指定する方法が良く分からない。
複数指定をいろいろ試してみたが、結局うまくできなかったので、１枚指定の方法で複数回実行することにしたが、１枚大体１秒で可能。
GoogleMapにリンクする画像は精々10枚程度だから、10秒程度で終了。
これで「OK」ということにした。
今後の課題は作業内容の１番から３番までを何とか自動化したい。

Google Map エンコードポリライン つづき

＜前ページのつづき＞
「hiroaki氏」の「GPX Casual Editor」は Java Script で書かれている。
私のツールは VBScript で書いている。
Java Script に書き直してもいいが、どうやら Java Script にはファイルをコピーしたり、追加したりする機能はないというようなことが、どこかに書いてあった気がするので、書き慣れた VBScript から離れられずにいた。

しかし、VBScript はビット演算をすることができないらしい。
ネットを探したが、ビット演算子はついに見つけることができなかった。
代わりにややこしい方法でビット演算を試みているページが見つかった。
http://www.geocities.co.jp/SiliconValley/4334/unibon/asp/bitshift2.html
この通りにやればできるのかも知れないが、JavaScript なら　a = b << 1;　という簡単な方法でできることが、余りにも複雑な手順を踏まないとできないことに嫌気がして、VBScript のビット演算は諦めた。

参考にした「hiroaki氏」の「GPX Casual Editor」のJavaScript ソースは複雑でかつ膨大であるため全部は解読できなかったが、EncordPolyline の処理過程は良く分かるように書いてある。

前ページのGoogleのアルゴリズムの6番から11番までの処理を「hiroaki氏」は、たった9行で実現している。素晴らしい！！

var encodeNumber = function(num){
var encodeString = '';
while( num >= 0x20 ){
encodeString += (String.fromCharCode((0x20 | (num & 0x1f)) + 63));
num >>= 5;
}
encodeString += (String.fromCharCode(num + 63));
return encodeString;
};

また、前ページの3番から5番の処理は、前ページ上の囲い枠の中と全く同じ処理で実行していた。
多分こうした処理は、分かっている人にとっては当たり前の処理法なのだろう。誰がやってもこうなるしかない処理なのかも知れない。

var encodeSignedNumber = function(num){
var sgn_num = num << 1;
if( num < 0 ){
sgn_num = ~(sgn_num);
}
return(encodeNumber(sgn_num));
};

実に明快な処理だ。
感心するほかない。

GoogleMap の縮尺を高縮尺率にした場合、省略するポイントを決める「num level」という値を決め、エンコードする部分は多少面倒な処理が行われていたが、「hiroaki氏」の処理は簡潔明瞭で無駄がない。
私が考えたら、ポリラインのポイントのエンコードと表示レベルのエンコードは別々にしそうだが、それを一度に同じルーチンを使って処理しているところが凄い。

VBscript と JavaScript は混在できることは分かっていたが、VBScript でGPXデータを取り込んだのは、2次元配列だ。
JavaScript は1次元配列しか認められてないらしいので、2次元配列に取り込んであるGPSデータを、果して JavaScript から読めるのかどうかが心配だった。

取り敢えず、恐る恐る2次元配列のGPSデータの3番目ぐらいのデータを読んで表示させてみた。
ところが、あら不思議！　ちゃんと読めている。
半信半疑だったので
　　alert(gpsData(i,1))
で、i　を順次変化させて、元のGPXデータを比較してみたが、どれも完全に同じ値が取れている。
i=100　にしても、i=200　にしても、どんな値を代入しても、ちゃんと正しい値が取れている。
これは、行ける！！　たまたま偶然に値が一致しただけではなさそうだ。
へー！　JavaScript でも、ちゃんと2次元配列の値が読めるのか・・・・！
しかも、配列の書き方は角カッコ（[ ]）ではなく VBScript の丸カッコのままでOKなんだ・・・。

今までのGPS軌跡作成ツールに、JavaScript の EncordPolyline の部分を追加して書き上げたツールで、山好会の会長が登った「乗鞍岳」の軌跡（http://sks.dojin.com/report/110828/map.html）を描いてみたら、見事に描くことができた。
これに気を良くして、私の「ホノケ山」の軌跡（http://www.gps-walk.com/yama/110521/map.html）を描かせてみたら、何故か表示しない。
撮影地点のマーカーは描けるが、GPS軌跡は描けてない。
何度試しても結果は同じ。
「hiroaki氏」のソースはオブジェクトとして結果を吐き出しているが、私の場合は単なる文字列として吐き出している。
この事が原因かもしれないと思って、「hiroaki氏」のツールで得た64進文字列と私のツールで得た文字列を比較してみたら、途中まではきっちり文字列が一致しているが、「￥」のところで「hiroaki氏」の文字列は「￥￥」に、私のは「￥」のままだ。

points: 'spqyE{k_~XFEBRARANGBBN@N?￥￥BHF￥￥LTEZ････'  （「hiroaki氏」の場合）
points: 'spqyE{k_~XFEBRARANGBBN@N?￥BHF￥LTEZ･･･････'  （私のツールの場合）

なるほど、これだ。
先の「乗鞍岳」はたまたま「￥」に変換される「29」の数値が出現しなかっただけのようだ。
メタキャラクタをそのまま使っていることがダメだったのだ。単なる文字列として「￥」を使うために、メタキャラクタの機能を打ち消す必要があるのか・・・・。
「hiroaki氏」のツールでは、それを自動的に行えるらしい。
私の場合は、それができていない。そこで、正規表現で文字列変換する
　　newpolyline = encordline.replace(/￥￥/g,"￥￥￥￥");
　（グログでの表示の都合上￥マークは全角表示になっています）
の１行を最後に追加してみた。
結果は上々。見事表示に漕ぎ着けることができ、めでたし！　めでたし！

Google Map エンコードポリライン

私のホームページ（http://www.gps-walk.com/yama/110521/map.html）や弟のホームページ（http://www.55walking.sakura.ne.jp/yama/110723/map.html）、そして私が担当している「清水北山好会」のホームページ（http://sks.dojin.com/report/110828/map.html）のGoogle Map は、10進法のデータを64進法に変換してデータ量を少なくし表示速度を得ている。
この変換は Google サイトのアルゴリズム（http://code.google.com/intl/ja/apis/maps/documentation/utilities/polylinealgorithm.html）を見ると、とても面倒なように見え、かなり敷居が高そうだ。

同じことを感じているページが、ここにもあった。
http://blog.livedoor.jp/g0031067/archives/51496182.html
ところが、そのページの下の方に

3番〜5番までの処理がわずか4行で記述されていました。
function conv(lat){
var num = lat<<1; //1ビット右へシフト
if ( lat < 0 ) { //マイナスの場合は
num　=　~(num); //not値を取得
}
return num;
}

と書いてある。
つまり、Google のアルゴリズムのページに書いてある下記の３〜５番の処理を上記の function conv(lat) と言う簡単なファンクションで処理できるらしい。これは凄い！！
これなら自分にもできるかも知れない。

１．最初の符合付き値を取得します:
　　　-179.9832104
２．10 進値を取得して 1e5 で乗算すると、結果は丸められます:
　　　-17998321
３．この 10 進値を 2 進値に変換します。
　　負の値は2 進値に変換し、2 の補数を使用して算出して、1 を加える必要があることに
　　注意してください。
　　　00000001 00010010 10100001 11110001
　　　11111110 11101101 01011110 00001110
　　　11111110 11101101 01011110 00001111
４．2 進値の 1 ビットを左にシフトします。
　　　11111101 11011010 10111100 00011110
５．元の 10 進値が負の場合は、このエンコーディング結果を反転します。
　　　00000010 00100101 01000011 11100001
６．2 進値を 5 ビット単位に分割します（右側から）。
　　　00001 00010 01010 10000 11111 00001
７．5 ビットの集合を逆の順序に並べ替えます。
　　　00001 11111 10000 01010 00010 00001
８．後続のビット集合が続く場合は、各値に 0x20 の論理和演算を行います。
　　　100001 111111 110000 101010 100010 000001
９．各値を 10 進値に変換します。
　　　33 63 48 42 34 1
10．各値に 63 を加算します。
　　　96 126 111 105 97 64
11．各値を対応する ASCII 文字に変換します。
　　　`~oia@

そこで、2〜3年前に参考にしてやってみようと思った「hiroaki氏」のホームページ「What hwat?」のエンコードポリライン関連ページを読み返してみた。

「hiroaki氏」の制作過程の記事と Java Script で書かれた「GPX Casual Editor」のソースとGoogleページのアルゴリズムとを比較しながら１行ずつ読んでいった。
（長くなったので次のページに改めます）