IE8

ソースの整理をしていて、IE8で怪しい動作をするのにきづいてしまった。

結果画面でF5を押して更新すると何も表示されなくなることがある。
実行した後の結果では特に影響もないし何回かF5を押すと表示されるので、原因不明のため対策できない・・・。

簡単なこと

IE7で遅いならIE7だけ元のページにすればよかったという簡単な結論。

難しく考えすぎてました。
渡される変数の仕様はまったく変わらないので、IE7のときだけ元のページに飛ばすだけで良い。

IE7かどうかの判断はHTTP_USER_AGENTで判断している。
"MSIE 7"のときだけ元のページに飛ばす。

6以前はさすがに対応しなくてもいいか・・。

迷った末

迷った末に、IE8でも効果が大きいことから、fromEncodedバージョンをbothにしたときも採用した。

こちらはまだまだ修正の余地があるが、動作自体は問題なくIE7以外では効果があるはずなのでお試しいただきたい。
動作方法は、いつも通りInput&Output ver.実行するだけだ。

ちなみにChromeを使ってる人はあまり実感がないかもしれない。

逆転現象

Shortest Path GraphicのPriorityをbothにしたとき、IE7ではEncodedしたほうが表示までが遅くなるという話はしたが、IE8betaでは圧倒的にEncodedした方が速くなっている。

IE8のbetaがとれれば正式稼働すればこの方が良いと思うのだが、それまでは現行バージョンにしておいたほうが良いのだろう。

どちらにせよGoogleChromeやFirefoxなどといった高速なブラウザに比べれば差は歴然でユーザーにはそういったブラウザを推奨したい。

Encodedバージョン

GoogleMapsの表示にfromEncoded機能を用いたものもすでに公開されているようだ。

ただ、どうやらpriorityにbothを選択したときは今までと変わらずEncodedされていないものが採用されたままだ。

IE7では通常表示のみで20秒程度で距離優先、速度優先両方とも表示される。
しかし、Encoded機能を用いた場合それが30から35秒かかってしまい、大きなタイムロスとなる。
表示されてからが速いと言ってもさすがにこれだけ差があると導入に踏み切れないのだろう。

ちなみに、Shortest　Path　GraphicではIEは推奨していない。

IE8での挙動

IE8をインストールして新バージョンと比較してみた。
今時ブラウザのインストールで再起動を要求されたり、β版にもかかわらずIE7をしっかりと上書きしたりするのは見なかったことにしておく。


旧バージョン（Encodedなし）：
「スクリプト実行に時間が・・・」のダイアログ表示が出る。

新バージョン（あり）：
ダイアログが出ない。

IE7とIE8では圧倒的にIE8が速い。体感ではOperaより速いイメージがある。
とはいえ、IE8で実行した後にChromeで実行するとやはり圧倒的差がある・・。

各ブラウザの挙動

新機能を入れるときは大手ブラウザでは実験している。

Encodedしたときの各ブラウザを比較してみた。

GoogleChrome
GoogleMapsというGoogleのシステムなだけあって、すべてにおいて問題なく、かつ他ブラウザに比べて圧倒的な体感速度。推奨ブラウザの一つ。

Firefox3.0.3
Chromeほどではないが十分高速かつ安定した表示をする。推奨ブラウザの一つ。

Safari
Firefoxより若干遅いイメージがあるが、差はほとんど感じられない。個人的にFirefoxの方が好きだから主観が入ってるのかもしれない。推奨ブラウザの一つ。

Opera
上記3つに比べると体感１ランク遅い。Encodedされたラインがなんだか表示されないことが・・。
移動して中心に持って行くと表示される。挙動がなんだかおかしい。

IE
Windowsユーザーなら1度は使ったことのあるブラウザ。
Operaに比べて体感２ランク遅い。表示自体は安定。1回表示されてしまえばEncodedバージョンでは他ブラウザとも大きな差は感じられない。


Encoded機能では表示までの時間は変わらないものの、表示されてからの操作が格段に速くなっているのが注目すべきところだろう。どのブラウザでもそれを体感することができる。
Operaの怪しい挙動はどう対処していこうか・・。

表示速度の比較

実際に描画にどのくらい差があるのかを時間計測してみた。
結果表示ページでF5を押すことによって計算時間を省けるため、実表示時間のみを計測できる。


通常の方は結果ファイルのリード、表示のまでの時間。
Encodedの方は結果ファイルのリード、エンコード、表示の時間になる。
IE以外のブラウザでは速すぎて差が分からないため、IEでのみの計測結果を表示する。

通常:11秒
Encoded:12秒

符号化のロスもあり、わずかにEncodedの方が遅い。
しかし、通常の方では「スクリプトの処理に時間がうんぬん」のダイアログが出てしまうが、Encodedの方では出ない。また、表示されてから拡大縮小の処理がスムーズにでき、全体としては明らかに上回っているだろう。

Encodedの方は、少しアルゴリズムを改善するなりで11秒の方に近づける可能性も残っている。

Encodeによる階層化

GoogleMapsのEncoded機能により距離による階層化を導入してみた。

体感できるくらい速くなりました。
読み込みこそそれなりに時間がかかるものの拡大縮小の処理の時にIEでもスムーズ。

まだ実装できる段階ではないので修正して早めに正式導入したい。

やはり、線の描画処理でだいぶ時間がかかるということだろう。

Encode化

実際にEncode化して表示までの速度を計ってみると、Chromeではあまり変わらないがIEではEncodeした方が遅くなっている。

また、実際にEncodeにかかる時間を調べてみると推測値1秒程度で終わっており、表示の時の差（約5秒）ほどではない。
やはりこれは、レベルに応じて表示するかしないかの処理を入れてから計ってみた方が良さそうだ。

サーバー側での符号化作業

実際に行っているわけではないがサーバー側で符号化するとしても問題点が生じる。

現時点では距離を出していないが各点間の距離を求める必要があることだ。

ただし、当たり前だが、ダイクストラ法の時点で各パスの距離はあるのでそれから求めてもよい。
また、次の点との距離を求めるのにはただ単に座標を用いて計算するのでもよい。

そもそもJavascriptでやってもたいして時間が変わらないという話もあるので、IEのみの対策になりそうだ。

今のところIEはサポートはしているが、推奨はしていない。

fromEncodedの効果

GPolyline.fromEncodedを実際に使い実装してみた。

特に拡大縮小等のときの処理を用いていないので、まだまだ改善の余地はある。


現時点では、速度的にはほとんど変わった印象はない。
ただし、変わってないと言っても符号化の時間を含めても変わっていないということなので、
符号化をサーバマシンで行ったり、拡大縮小を取り入れたりすれば話は変わってくるだろう。

ちょっと休憩

少し休憩して、一番重要な初期バージョンでの画像ファイルの大きさの検証をしてみる。

検証にはNYのグラフファイルを用いている。

入力画面のarcファイル
BB Ver. 612KB
NB Ver. 226KB

出力画面のファイル
BB Ver. 1.43MB
NB Ver. 10KB + 226KB(Path_file + arc_file)
(合成画像出力時 503KB)

となっている。
NBバージョンでは、入力画面で226KBの容量の画像を読み込むが、出力時は10KBのパスファイルと、入力画面時の画像226KBを重ねて表示する。
単純に足して236KBと考える人もいるだろうが、ブラウザがキャッシュから読み込んでくれる可能性は高いので実質10KBしか読み込まなくてよい。

BBバージョンでは1.43MBくらい別に良いかと思ってそのまま合成した画像を出力している。

高速描画

GoogleMapsではPolylineを用いてラインを引いている。
しかし、直接かつ大量の描画は動作が遅くなるというのはどうやらGoogle側も認識しているようだ。

そこで、Encoded Polyline Algorithmによって符号化することで高速化することができるようだ。
実際に1万点を超えるラインの描画はその符号化の計算時間も含めなければならないが、1度作ってしまえば読み込むだけなのでどちらがよいかは実際に作ってみるしかない。

KMLファイルの戦略を断念したのでこちらを試してみることにする。

符号化についてはこの当たりのページが参考になりそうだ。
http://hwat.sakura.ne.jp/hpod/200609/14-200000/

Google公式のアルゴリズムについてはこっち
http://code.google.com/intl/ja/apis/maps/documentation/polylinealgorithm.html

評判

Web上でサービスを公開していると色々と意見をいただいたりするが、今のところShortest Path Graphicには悪い意見はほとんどない。

KMLファイルに関しては公開したばかりで何も情報がないが、こちらもGoogle上のサーバーにも負担をかけることがないし、オフラインでも実行できるという利点もあり悪い評判は出ないだろう。
有名な都市間の最短距離、最速距離を求めておいてGoogle Earth上でその都市間のルートを検索すると面白い。

Google

Googleの検索で、

Optimization Online

と検索すると3番目くらいに表示されるようになっている。（日本語環境下でWeb全体から検索）

Shortest Path Graphic

で計算するとこのブログが一番上に、本来のページが2番目に表示される。


Shortest Path Online や Shortest Path

の検索でもトップページに来ればいいのだが。
いずれにしても名前は正式決定ではないが。

KML版公開

結局のところ、Google側のサーバーの仕様上どうしようもないと判断した。
そのため、最短路を計算、KMLファイルを作成しそのままダウンロードしてGoogle Earthを用いて使用できるバージョンがすでに公開されている。

今回の仕様は以下の通り

1,いつもの入力画面
2,いつもの計算ページ
3,KMLを作成するページ
4,ダウンロードするページ

ブラウザにもよるが、基本的に2～4は見えない。(4は空白のページが見えることもある)

3と4で分けているのは、KMLを使用して表示するバージョンの名残りなので特に意味はない。
Google側のサーバーの仕様変更によってすぐに対応できるという意味も含めてはいるが。

エラーの原因

表示されないエラーの原因を調べてみた。

GoogleMapsでは、直接URLを指定することでkmlファイルを表示することができる。

http://maps.google.co.jp/maps?q=http://hogehoge.jp/test.kml

にすれば読み込むことができる。

そこで、表示されるファイルと表示されないファイルをやってみると



・表示されるファイル→表示される（当たり前か）

・表示されないファイル→サーバーエラー。
場合によっては、ファイルが存在しないというエラーもある。

となる。

仮バージョン

いったんはKMLファイルを利用したInput&Outputバージョンを公開したが、色々事情があって旧バージョンに戻した。

実際に同じ入力でも結果が表示されたりされなかったりで安定しないことが原因。
短い距離の場合はいつでも表示されるため、KMLファイルの大きさによってGoogle側が拒否しているのかもしれない。

このままでは無駄になってしまうが、KMLファイルのダウンロードをできるようにすればGoogleEarthでも読み込むことができるし応用がないわけではない。

kmlによる描画

kmlに変更する基本的な作業は終わっているが、今のまま移項してしまうとChromeやFirefoxなどの高速なブラウザで実行してしまうとただの劣化版に見えてしまうため、完全に同機能を備えてからの公開になりそうだ。来週くらいまでにはなんとかしたい。
とはいえそのブラウザでも少しは速くなっているしIEでは体感300倍くらいの高速化がされている。

CEATEC

CEATEC JAPANに行ってきたが、GoogleEarthなどを利用している企業も多い。
簡単に実装できる仕様で、かつ高機能で見栄えがいいというのが魅力なのだろう。

軍事目的の使用などは危ないが、機能としては魅力的だし、誰が見ても面白いと思えるでしょう。

kmlファイル対応策

kmlファイルのキャッシュの問題だが色々調べているとどうやらアドレスで判断しているらしいことが分かった。
kmlファイルの後にゴミをつけてやればキャッシュを読みに行かずすぐに反映される。サーバに対してはあまりよくないのかもしれないが・・・。

今更感があるが、自前のサーバにGooglemapsを設置し、kmlファイルを読み込む方法は

map.addOverlay(new GGeoXml("http://honyanyara.jp/t.kml?gomi=hoge");

kmlファイルの読み込み

どうやら、kmlファイルの更新が反映されるにはある程度時間がかかるようだ。
GoogleMapsのサーバにキャッシュか何かが残っているのだと思われる。

Firefoxで実行した結果がIEでは実行していないはずの結果として表示されたりするので、ブラウザのキャッシュではないと言うことが一応の根拠。

GoogleEarthでは結果がすぐに反映されているので、その辺の仕様は違うのでしょう。

問題点

先日から話しているが、今回作成しているバージョンでは、kmlファイルを読み込んでいる。

kmlファイルがアクセスしたりダウンロードしたりすれば、自分のGoogle Earthでも読み込むことができる。


本題の問題点。
1回目の実行は問題なく実行でき、今までに比べ高速（特にIEで体感）でできている気がする。
が、2回目の実行が反映されない。
そこで、Google Earthから読み込んでみるとしっかりと反映される。

キャッシュの問題なのかGoogle側の問題なのかわからないがキャッシュの問題ならページをキャッシュさせないなどの処理が必要になる。
Google側がそのような仕様にしているならあきらめるしかない。

kmlを用いたShortest Path Graphic

試作品の試作品の試作品くらいのものを作ってみた。

現時点での仕様は確定ではないがこんな感じになる予定

１，いつもの入力画面
２，いつもの計算ページ
３，kml形式のファイル書き込み
４，kmlファイルを読み込んで表示するページ

1,2は基本的に何も変わらないが、3,4を新しくしている。
とはいってもユーザーから見た目はほとんど何も変わらない。

kml

Google Earthにはkmlと呼ばれるファイル形式があり、ポリゴンデータやプレイスマークなどがxml形式でかかれている。

これはGoogleMapsでも(一部形式のみ)使うことができるため、これを使うと表示を速くすることができそうという見通しがある。
実際にやってみてもIEでもストレスなくとまではいかないがちょびっとストレスくらいで表示することができる。

しばらくはこの作業を色々実験してみようと思う。

Shortest Path Graphic

しばらくブログを更新しませんでしたが生きてます。入院もしてません。
なんだか内定式とかもあったりで忙しかったことにしておいてください。


その間にもShortest Path Graphicの入出力バージョンも無事公開されたようで、だいぶ好評だ。

ただIEでの表示が遅いため、色々改善策が出てきている。