ソースの整理をしていて、IE8で怪しい動作をするのにきづいてしまった。
結果画面でF5を押して更新すると何も表示されなくなることがある。
実行した後の結果では特に影響もないし何回かF5を押すと表示されるので、原因不明のため対策できない・・・。
2008年10月28日火曜日
2008年10月26日日曜日
2008年10月25日土曜日
2008年10月24日金曜日
Encodedバージョン
GoogleMapsの表示にfromEncoded機能を用いたものもすでに公開されているようだ。
ただ、どうやらpriorityにbothを選択したときは今までと変わらずEncodedされていないものが採用されたままだ。
IE7では通常表示のみで20秒程度で距離優先、速度優先両方とも表示される。
しかし、Encoded機能を用いた場合それが30から35秒かかってしまい、大きなタイムロスとなる。
表示されてからが速いと言ってもさすがにこれだけ差があると導入に踏み切れないのだろう。
ちなみに、Shortest Path GraphicではIEは推奨していない。
ただ、どうやらpriorityにbothを選択したときは今までと変わらずEncodedされていないものが採用されたままだ。
IE7では通常表示のみで20秒程度で距離優先、速度優先両方とも表示される。
しかし、Encoded機能を用いた場合それが30から35秒かかってしまい、大きなタイムロスとなる。
表示されてからが速いと言ってもさすがにこれだけ差があると導入に踏み切れないのだろう。
ちなみに、Shortest Path GraphicではIEは推奨していない。
2008年10月23日木曜日
2008年10月22日水曜日
各ブラウザの挙動
新機能を入れるときは大手ブラウザでは実験している。
Encodedしたときの各ブラウザを比較してみた。
GoogleChrome
GoogleMapsというGoogleのシステムなだけあって、すべてにおいて問題なく、かつ他ブラウザに比べて圧倒的な体感速度。推奨ブラウザの一つ。
Firefox3.0.3
Chromeほどではないが十分高速かつ安定した表示をする。推奨ブラウザの一つ。
Safari
Firefoxより若干遅いイメージがあるが、差はほとんど感じられない。個人的にFirefoxの方が好きだから主観が入ってるのかもしれない。推奨ブラウザの一つ。
Opera
上記3つに比べると体感1ランク遅い。Encodedされたラインがなんだか表示されないことが・・。
移動して中心に持って行くと表示される。挙動がなんだかおかしい。
IE
Windowsユーザーなら1度は使ったことのあるブラウザ。
Operaに比べて体感2ランク遅い。表示自体は安定。1回表示されてしまえばEncodedバージョンでは他ブラウザとも大きな差は感じられない。
Encoded機能では表示までの時間は変わらないものの、表示されてからの操作が格段に速くなっているのが注目すべきところだろう。どのブラウザでもそれを体感することができる。
Operaの怪しい挙動はどう対処していこうか・・。
Encodedしたときの各ブラウザを比較してみた。
GoogleChrome
GoogleMapsというGoogleのシステムなだけあって、すべてにおいて問題なく、かつ他ブラウザに比べて圧倒的な体感速度。推奨ブラウザの一つ。
Firefox3.0.3
Chromeほどではないが十分高速かつ安定した表示をする。推奨ブラウザの一つ。
Safari
Firefoxより若干遅いイメージがあるが、差はほとんど感じられない。個人的にFirefoxの方が好きだから主観が入ってるのかもしれない。推奨ブラウザの一つ。
Opera
上記3つに比べると体感1ランク遅い。Encodedされたラインがなんだか表示されないことが・・。
移動して中心に持って行くと表示される。挙動がなんだかおかしい。
IE
Windowsユーザーなら1度は使ったことのあるブラウザ。
Operaに比べて体感2ランク遅い。表示自体は安定。1回表示されてしまえばEncodedバージョンでは他ブラウザとも大きな差は感じられない。
Encoded機能では表示までの時間は変わらないものの、表示されてからの操作が格段に速くなっているのが注目すべきところだろう。どのブラウザでもそれを体感することができる。
Operaの怪しい挙動はどう対処していこうか・・。
2008年10月21日火曜日
表示速度の比較
実際に描画にどのくらい差があるのかを時間計測してみた。
結果表示ページでF5を押すことによって計算時間を省けるため、実表示時間のみを計測できる。
通常の方は結果ファイルのリード、表示のまでの時間。
Encodedの方は結果ファイルのリード、エンコード、表示の時間になる。
IE以外のブラウザでは速すぎて差が分からないため、IEでのみの計測結果を表示する。
通常:11秒
Encoded:12秒
符号化のロスもあり、わずかにEncodedの方が遅い。
しかし、通常の方では「スクリプトの処理に時間がうんぬん」のダイアログが出てしまうが、Encodedの方では出ない。また、表示されてから拡大縮小の処理がスムーズにでき、全体としては明らかに上回っているだろう。
Encodedの方は、少しアルゴリズムを改善するなりで11秒の方に近づける可能性も残っている。
結果表示ページでF5を押すことによって計算時間を省けるため、実表示時間のみを計測できる。
通常の方は結果ファイルのリード、表示のまでの時間。
Encodedの方は結果ファイルのリード、エンコード、表示の時間になる。
IE以外のブラウザでは速すぎて差が分からないため、IEでのみの計測結果を表示する。
通常:11秒
Encoded:12秒
符号化のロスもあり、わずかにEncodedの方が遅い。
しかし、通常の方では「スクリプトの処理に時間がうんぬん」のダイアログが出てしまうが、Encodedの方では出ない。また、表示されてから拡大縮小の処理がスムーズにでき、全体としては明らかに上回っているだろう。
Encodedの方は、少しアルゴリズムを改善するなりで11秒の方に近づける可能性も残っている。
2008年10月20日月曜日
Encodeによる階層化
GoogleMapsのEncoded機能により距離による階層化を導入してみた。
体感できるくらい速くなりました。
読み込みこそそれなりに時間がかかるものの拡大縮小の処理の時にIEでもスムーズ。
まだ実装できる段階ではないので修正して早めに正式導入したい。
やはり、線の描画処理でだいぶ時間がかかるということだろう。
体感できるくらい速くなりました。
読み込みこそそれなりに時間がかかるものの拡大縮小の処理の時にIEでもスムーズ。
まだ実装できる段階ではないので修正して早めに正式導入したい。
やはり、線の描画処理でだいぶ時間がかかるということだろう。
2008年10月19日日曜日
2008年10月18日土曜日
サーバー側での符号化作業
実際に行っているわけではないがサーバー側で符号化するとしても問題点が生じる。
現時点では距離を出していないが各点間の距離を求める必要があることだ。
ただし、当たり前だが、ダイクストラ法の時点で各パスの距離はあるのでそれから求めてもよい。
また、次の点との距離を求めるのにはただ単に座標を用いて計算するのでもよい。
そもそもJavascriptでやってもたいして時間が変わらないという話もあるので、IEのみの対策になりそうだ。
今のところIEはサポートはしているが、推奨はしていない。
現時点では距離を出していないが各点間の距離を求める必要があることだ。
ただし、当たり前だが、ダイクストラ法の時点で各パスの距離はあるのでそれから求めてもよい。
また、次の点との距離を求めるのにはただ単に座標を用いて計算するのでもよい。
そもそもJavascriptでやってもたいして時間が変わらないという話もあるので、IEのみの対策になりそうだ。
今のところIEはサポートはしているが、推奨はしていない。
2008年10月17日金曜日
fromEncodedの効果
GPolyline.fromEncodedを実際に使い実装してみた。
特に拡大縮小等のときの処理を用いていないので、まだまだ改善の余地はある。
現時点では、速度的にはほとんど変わった印象はない。
ただし、変わってないと言っても符号化の時間を含めても変わっていないということなので、
符号化をサーバマシンで行ったり、拡大縮小を取り入れたりすれば話は変わってくるだろう。
特に拡大縮小等のときの処理を用いていないので、まだまだ改善の余地はある。
現時点では、速度的にはほとんど変わった印象はない。
ただし、変わってないと言っても符号化の時間を含めても変わっていないということなので、
符号化をサーバマシンで行ったり、拡大縮小を取り入れたりすれば話は変わってくるだろう。
2008年10月16日木曜日
ちょっと休憩
少し休憩して、一番重要な初期バージョンでの画像ファイルの大きさの検証をしてみる。
検証には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くらい別に良いかと思ってそのまま合成した画像を出力している。
検証には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くらい別に良いかと思ってそのまま合成した画像を出力している。
2008年10月14日火曜日
高速描画
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
しかし、直接かつ大量の描画は動作が遅くなるというのはどうやら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
2008年10月13日月曜日
評判
Web上でサービスを公開していると色々と意見をいただいたりするが、今のところShortest Path Graphicには悪い意見はほとんどない。
KMLファイルに関しては公開したばかりで何も情報がないが、こちらもGoogle上のサーバーにも負担をかけることがないし、オフラインでも実行できるという利点もあり悪い評判は出ないだろう。
有名な都市間の最短距離、最速距離を求めておいてGoogle Earth上でその都市間のルートを検索すると面白い。
KMLファイルに関しては公開したばかりで何も情報がないが、こちらもGoogle上のサーバーにも負担をかけることがないし、オフラインでも実行できるという利点もあり悪い評判は出ないだろう。
有名な都市間の最短距離、最速距離を求めておいてGoogle Earth上でその都市間のルートを検索すると面白い。
2008年10月12日日曜日
2008年10月11日土曜日
KML版公開
結局のところ、Google側のサーバーの仕様上どうしようもないと判断した。
そのため、最短路を計算、KMLファイルを作成しそのままダウンロードしてGoogle Earthを用いて使用できるバージョンがすでに公開されている。
今回の仕様は以下の通り
1,いつもの入力画面
2,いつもの計算ページ
3,KMLを作成するページ
4,ダウンロードするページ
ブラウザにもよるが、基本的に2~4は見えない。(4は空白のページが見えることもある)
3と4で分けているのは、KMLを使用して表示するバージョンの名残りなので特に意味はない。
Google側のサーバーの仕様変更によってすぐに対応できるという意味も含めてはいるが。
そのため、最短路を計算、KMLファイルを作成しそのままダウンロードしてGoogle Earthを用いて使用できるバージョンがすでに公開されている。
今回の仕様は以下の通り
1,いつもの入力画面
2,いつもの計算ページ
3,KMLを作成するページ
4,ダウンロードするページ
ブラウザにもよるが、基本的に2~4は見えない。(4は空白のページが見えることもある)
3と4で分けているのは、KMLを使用して表示するバージョンの名残りなので特に意味はない。
Google側のサーバーの仕様変更によってすぐに対応できるという意味も含めてはいるが。
2008年10月10日金曜日
2008年10月9日木曜日
2008年10月8日水曜日
2008年10月7日火曜日
2008年10月6日月曜日
kmlファイル対応策
kmlファイルのキャッシュの問題だが色々調べているとどうやらアドレスで判断しているらしいことが分かった。
kmlファイルの後にゴミをつけてやればキャッシュを読みに行かずすぐに反映される。サーバに対してはあまりよくないのかもしれないが・・・。
今更感があるが、自前のサーバにGooglemapsを設置し、kmlファイルを読み込む方法は
map.addOverlay(new GGeoXml("http://honyanyara.jp/t.kml?gomi=hoge");
kmlファイルの後にゴミをつけてやればキャッシュを読みに行かずすぐに反映される。サーバに対してはあまりよくないのかもしれないが・・・。
今更感があるが、自前のサーバにGooglemapsを設置し、kmlファイルを読み込む方法は
map.addOverlay(new GGeoXml("http://honyanyara.jp/t.kml?gomi=hoge");
2008年10月5日日曜日
kmlファイルの読み込み
どうやら、kmlファイルの更新が反映されるにはある程度時間がかかるようだ。
GoogleMapsのサーバにキャッシュか何かが残っているのだと思われる。
Firefoxで実行した結果がIEでは実行していないはずの結果として表示されたりするので、ブラウザのキャッシュではないと言うことが一応の根拠。
GoogleEarthでは結果がすぐに反映されているので、その辺の仕様は違うのでしょう。
GoogleMapsのサーバにキャッシュか何かが残っているのだと思われる。
Firefoxで実行した結果がIEでは実行していないはずの結果として表示されたりするので、ブラウザのキャッシュではないと言うことが一応の根拠。
GoogleEarthでは結果がすぐに反映されているので、その辺の仕様は違うのでしょう。
2008年10月4日土曜日
問題点
先日から話しているが、今回作成しているバージョンでは、kmlファイルを読み込んでいる。
kmlファイルがアクセスしたりダウンロードしたりすれば、自分のGoogle Earthでも読み込むことができる。
本題の問題点。
1回目の実行は問題なく実行でき、今までに比べ高速(特にIEで体感)でできている気がする。
が、2回目の実行が反映されない。
そこで、Google Earthから読み込んでみるとしっかりと反映される。
キャッシュの問題なのかGoogle側の問題なのかわからないがキャッシュの問題ならページをキャッシュさせないなどの処理が必要になる。
Google側がそのような仕様にしているならあきらめるしかない。
kmlファイルがアクセスしたりダウンロードしたりすれば、自分のGoogle Earthでも読み込むことができる。
本題の問題点。
1回目の実行は問題なく実行でき、今までに比べ高速(特にIEで体感)でできている気がする。
が、2回目の実行が反映されない。
そこで、Google Earthから読み込んでみるとしっかりと反映される。
キャッシュの問題なのかGoogle側の問題なのかわからないがキャッシュの問題ならページをキャッシュさせないなどの処理が必要になる。
Google側がそのような仕様にしているならあきらめるしかない。
2008年10月3日金曜日
kmlを用いたShortest Path Graphic
試作品の試作品の試作品くらいのものを作ってみた。
現時点での仕様は確定ではないがこんな感じになる予定
1,いつもの入力画面
2,いつもの計算ページ
3,kml形式のファイル書き込み
4,kmlファイルを読み込んで表示するページ
1,2は基本的に何も変わらないが、3,4を新しくしている。
とはいってもユーザーから見た目はほとんど何も変わらない。
現時点での仕様は確定ではないがこんな感じになる予定
1,いつもの入力画面
2,いつもの計算ページ
3,kml形式のファイル書き込み
4,kmlファイルを読み込んで表示するページ
1,2は基本的に何も変わらないが、3,4を新しくしている。
とはいってもユーザーから見た目はほとんど何も変わらない。
2008年10月2日木曜日
2008年10月1日水曜日
Shortest Path Graphic
しばらくブログを更新しませんでしたが生きてます。入院もしてません。
なんだか内定式とかもあったりで忙しかったことにしておいてください。
その間にもShortest Path Graphicの入出力バージョンも無事公開されたようで、だいぶ好評だ。
ただIEでの表示が遅いため、色々改善策が出てきている。
なんだか内定式とかもあったりで忙しかったことにしておいてください。
その間にもShortest Path Graphicの入出力バージョンも無事公開されたようで、だいぶ好評だ。
ただIEでの表示が遅いため、色々改善策が出てきている。
登録:
投稿 (Atom)