ビット演算をすることができないらしい。ネットを探したが、ビット演算子はついに見つけることができなかった。代わりにややこしい方法でビット演算を試みているページが見つかった。処理過程は良く分かるように書いてある。Googleのアルゴリズムの6番から11番までの処理を「hiroaki氏」は、たった9行で実現している。encodeString;};また、Googleのアルゴリズムの3番から5番の処理は、上の囲い枠の中と全く同じ処理で実行していた。した処理は、分かっている人にとっては当たり前の処理法なのだろう。誰がやってもこうなるしかない処理なのかも知れない。~(sgn_num);}return(encodeNumber(sgn_num));};実に明快な処理だ。level」という値を決め、エンコードする部分は多少面倒な処理が行われていたが、「hiroaki氏」の処理は簡潔明瞭で無駄がない。私が考えたら、ポリラインのポイントのエンコードと表示レベルのエンコードは別々にしそうだが、それを一度に同じルーチンを使って処理しているところが凄い。GPXデータを取り込んだのは、2次元配列だ。読めるのかどうかが心配だった。2次元配列のGPSデータの3番目ぐらいのデータを読んで表示させてみた。ところが不思議、ちゃんと読めている。変化させて、元のGPXデータを比較してみたが、どれも全く同じ値が取れている。しても、どんな値を代入しても、全く同じ値が取れている。偶然に値が一致しているだけではなさそうだ。丸カッコのままでOKなんだ・・・。部分を追加して書き上げたツールで、山好会の会長が登った「乗鞍岳」の軌跡(http://sks.dojin.com/report/110828/map.html)を描いてみたら、見事に描くことができた。これに気を良くして、私の「ホノケ山」の軌跡(http://www.gps-walk.com/yama/110521/map.html)を描かせてみたら、何故か表示しない。撮影地点のマーカーは描けるが、GPS軌跡は描けてない。何度試しても結果は同じ。「hiroaki氏」のソースはオブジェクトとして結果を吐き出しているが、私の場合は単なる文字列として吐き出している。この事が原因かもしれないと思って、「hiroaki氏」のツールで得た64進文字列と、私のツールで得た文字列を比較してみたら、途中まではきっちり文字列が一致しているが、「\」のところで「hiroaki氏」の文字列は「\\」に、私のは「\」のままだ。先の「乗鞍岳」はたまたま「\」に変換される「29」の数値が出現しなかっただけのようだ。メタキャラクタをそのまま使っていることがダメだったのだ。単なる文字列として「\」を使うために、メタキャラクタの機能を打ち消す必要があるのか・・・・。「hiroaki氏」のツールでは、それを自動的に行えるらしい。私の場合は、それができていない。encordline.replace(/\\/g,"\\\\");の1行を最後に追加してみた。