hPod

Google の説明例によれば、「例えば、各グループにおけるそれぞれのズームレベルとおよそ 4 つのズームレベルのための倍増を考えて、この値は16に設定されるべきです」（同引用の excite 翻訳による）。──そのようにしたら、あるズームレベルでは荒っぽくなり過ぎて駄目だったのだけれども、いやまてよ？　もしかしてこの zoomFactor が駄目だったのではなくこれは、 numLevels の値が、ズームレベルのバラエティ（ 0 〜 18 ）に対して小さいことがもとで、あるズームレベルのときの線が荒くなってしまっているのではないかしら。そんな気がしたというか、そう考える方が妥当かも知れないと閃いた。

解らないなりに思われたのは、 numLevels はできるだけズームレベルの段階と同じくらいの値にしたほうが、「あるズームレベルのときだけ荒っぽい」といったこともなくなり、各ズームレベルに於いて、それぞれに適したラインが描けるのではないだろうか、ということだ。おそらく。でもしぜんな導きだ。

こうして頭を悩ませているのは、じぶんのカンが鈍いというのもそうだけれど、それにしても Google の説明が不足気味だからだ。かといって、ほかに試しているひとはいないかしらと Web を探してみても Encoded Polyline を取り上げている例も、未だにほとんど見つからない。

でも、先日になってようやく参考にできそうなところをひとつだけ見つけられた。タイトルはずばり "Encoding polylines for Google Maps" ［参考１］。

そのページでは──じぶんの語学力ではどれだけ、書かれている事を呑み込めたのかは知れないが──各ズームレベル・グループごとのラインセグメント（線分）の距離はどのくらいにするのがよいかということが試されている。また試す事ができる。

そして結論としては、いちばんの広域であるズームレベル＝ゼロのときの２点間の距離（ベース・セグメント長）を 500,000 メートル（を超えるごとにポイントするように）とすると、ちょうど加減が良いのではなかろうかとある。そして、 numLevels をズームレベルのバラエティの数（ 18 ）に合わせ、レベルを詳細に近づけるごとに、セグメント長に 1/2 を掛ける。

この結論から逆に言えるのは、ズームレベル・グループごとの倍率は２倍で、比例しているということだ。これは numLevels を 18 にしたがための倍率のように思われる。というと、その２倍というのが、 zoomFactor に値するのかしら。

一歩確信に近づいたような気もしたけれども、ただ、地図の倍率についてはとくに言及されていないので、それとの関わりが、まだ解らない。

とにかく、これはためになるサンプルだということで、その考え方をじぶんのツール［参考２］に採り入れて試してみた。具体的な実装（コード）はそのページのそれとは異なるけれども、やっていることは同じものだ。

試してみた結果。

採用前の自前のそれでは（ Figure 1 ）、各レベルのセグメント長も適当だった。 numLevels=4 にして４つのズームレベル・グループに分けたそれぞれのセグメント長は、詳細ズームレベル・グループから、 0Km / 2Km / 10Km / 100Km だった。これは比例もしていない。

ゆえに、今考えれば、そのことも「あるズームレベルのときだけ荒っぽい」現象におおいに影響しているものと思われるので、この二例を単純に比較する事はできないのだけれども、ともかく適用後は（ Figure 2 ）あるズームレベルのときだけ荒っぽいというようなこともなくなったし、ラインの精度もいいようだ。

これはいいアルゴリズムかもしれない。ただちょっと精密すぎるかな？　じぶんのマシンではちょっと重たいような気もしないでもなかった。も少し疎でもよければ、セグメント長を大きくすればいいのかしら。

ただひとつ、このとき問題というか懸念されるところとしては、ズームレベルのバラエティ、いまは 18 （ 20 になったんだっけ？）のズームレベルがあるけれども、これが増減した時に影響があると思われるところだ。ただこれはズームレベルとスケール（倍率）とのペアを、 API のほうで用意してくれないとパラメータにはできないので、このアルゴリズムが足りないというわけではない。その情報の補填が望まれる。

──と思ったのだけれども、考えているうちにだんだん、こうも思うようになった。裏がとれていないので確信はないのだけれども。

まず根底の考え方からして変える。

numLevels で分つズームレベル・グループの倍率 zoomFactor の値は、ズームレベルの倍率とは無関係に設定するものだと考える。地図のズームレベルではなくて、ポリラインをオーバレイするレイヤのズームレベルとして、独立したものだと。そう仮に解釈すると、解り易い。地図のズームレベルを変更すると、それに応じたポリラインのズームレベル・グループも（変動すべきであれば）変更される。といった具合に。

例えば、地図のズームレベルの階層は意識しないで、ズームレベル・グループ numLevels を 18 に設定するとする。そして、 18 段階のレベル階層間のスケール倍率はそれぞれ 2 倍とする。つまり zoomFactor = 2 だ。このことで、ポリラインは地図の倍率とは独立したスケール空間で操作されると考える。

もちろん、ポリラインは地図の上にオーバレイされるものだから、地図のズームレベルと倍率に応じたズームレベル・グループが連動して選択されオーバレイされる。だから、ズームレベルと、ズームレベル・グループとは、相似した値である事が好ましい。

最初に試した、 numLevels が 4 で zoomFactor が 16 という設定では、ポリラインのズームレベル・グループが４段階しか設定されないことになる。すると、ひとつの段階が変更されるようになるには、その間、地図のズームレベルは４段階もの変更が伴う。その４段階の間の中では、ポリラインのズームレベル・グループが変化しないので、４段階の最初と最後とを比べたとき、地図は詳細になっていってもポリラインは疎なままになっている、といった現象が見られる。これが、「あるズームレベルのときだけ荒っぽい」となってしまった現象の解釈だ。

そしてこの仮定がもし正しかったすると、ズームレベルのバラエティが増減したところで、このアルゴリズムは影響されるものではないものだ（そのはずだ？）。相似した値がベターだという思惑は崩れてしまうかも知れないけれども、ズームレベル・グループを 18 もの階層に分けた時には、その１段階のスケールの倍率の違いはせいぜい２倍の範囲内での出来事だから、そのくらいのずれなら許容できるくらいのものだろう。

じぶんは想像と仮定の域が出られていないので、雲の中に居るようにアヤフヤで、説明すらうまくできていないのだけれども、ともかくも、 Encoded Polyline が登場して以来、冒頭から記して（迷走して）考えて来たようなところはもう全て忘れてしまって、その代わりにそんなふうに解釈を付けるほうがしぜんな気がする。むしろおおいなる勘違いをしていたような気もする。ので、ぜひそうであってほしい。

ほしいと願ってもしょうがないし願うものでもないんだけれども。

──そのへんを、だれかうまく解き明かしてくれないかしらん。と、どこへともなく期待を込めた、このエントリー、だ。でも結果はいいので、とりあえずこれでもいい。

引用
[1] Google Maps API Documentation - Encoded Polyline Algorithm
http://www.google.com/apis/maps/documentation/polylinealgorithm.html

参考
[1] Encoding polylines for Google Maps
http://facstaff.unca.edu/mcmcclur/GoogleMaps/EncodePolyline/

[2] GPX Editor JS
GPX Editor JS