どうやらPHP上でexecで呼び出すとプロセスを別に生成するらしい。
だから今まで書いたようなプロセス増えすぎ現象はそれで理解できる。
別の方法で呼び出す方法もあるが、プロセス数は一定に増えるので多重起動時のプロセス数を増えるプロセスのn倍にすれば解決する。
できれば1プロセスにしたいところだが、バイナリが変わってもシステム自体を大きく変えない限り大きな問題にはならないからそれで行くことにする。
2008年12月26日金曜日
多重起動3
停電中で落としていたサーバーも無事復旧したので多重起動を実装してみることに。
サンプルを作ってとりあえず動作確認もすませ、実装してみる。
思うように動きません・・。
とりあえずサンプルの時点で
$check = exec("ps -ef | grep -c binary_name");
をしてやると$checkが2になるのはわかっていた。1つはgrep自信でもう1つは謎だったが、とりあえず-2してやることに。
普通に動かしてみて、
$check = exec("ps -ef | grep -c binary_name") - 2;
の値を確認すると
$check=5
増えすぎです。
同時にもう一つ動かしてみると・・。
$check=5
変わりません。せめて増えてくれ。
サンプルを作ってとりあえず動作確認もすませ、実装してみる。
思うように動きません・・。
とりあえずサンプルの時点で
$check = exec("ps -ef | grep -c binary_name");
をしてやると$checkが2になるのはわかっていた。1つはgrep自信でもう1つは謎だったが、とりあえず-2してやることに。
普通に動かしてみて、
$check = exec("ps -ef | grep -c binary_name") - 2;
の値を確認すると
$check=5
増えすぎです。
同時にもう一つ動かしてみると・・。
$check=5
変わりません。せめて増えてくれ。
2008年12月23日火曜日
2008年12月21日日曜日
2008年12月20日土曜日
HTMLのdisabled
disabled属性が微妙。
ShortestPathの方でも当初は使う方向で進めていたがブラウザによって挙動が違うので避けていた。
SDPAオンラインソルバーの方でCPU数を指定するときに使っていて、その初期値がおかしくなっていたので修正。そのついでにちょっとソースを色々と細かく見てみるとこれって動いたっけ?
と思い色々なブラウザで挙動をチェック。
Firefox:正常動作
IE8:動かない
Chrome:動かない
Safari:動かない
Opera:正常動作
となった。こうしてみてもFirefoxの安定性は高い。一番規格に準拠しているのもFirefoxらしい。
ちなみにIEは規格を無視して独自規格で同じような機能をつけている。
disabled属性という単純なモノでもここまで差が出るので恐ろしい。
disabled属性よりは、hidden属性の方が安定している気がするのでそちらですむならそちらを使用した方が良い気がする。
また、disabled属性が動作しないというわけではなくdisabled属性のJavascriptによる変更ができないといった方が状況としては正しい。
ShortestPathの方でも当初は使う方向で進めていたがブラウザによって挙動が違うので避けていた。
SDPAオンラインソルバーの方でCPU数を指定するときに使っていて、その初期値がおかしくなっていたので修正。そのついでにちょっとソースを色々と細かく見てみるとこれって動いたっけ?
と思い色々なブラウザで挙動をチェック。
Firefox:正常動作
IE8:動かない
Chrome:動かない
Safari:動かない
Opera:正常動作
となった。こうしてみてもFirefoxの安定性は高い。一番規格に準拠しているのもFirefoxらしい。
ちなみにIEは規格を無視して独自規格で同じような機能をつけている。
disabled属性という単純なモノでもここまで差が出るので恐ろしい。
disabled属性よりは、hidden属性の方が安定している気がするのでそちらですむならそちらを使用した方が良い気がする。
また、disabled属性が動作しないというわけではなくdisabled属性のJavascriptによる変更ができないといった方が状況としては正しい。
2008年12月19日金曜日
オンラインソルバーの将来性
オンラインソルバーも基本機能はそろってきていると思う。対応できる問題が少ないというのが根本的な問題ではあるが。
ここまでくると、ユーザー側の使いやすさをもっと考える時期でもあると思う。
Ajaxを利用するなどと言うとさすがに無責任か。
AdobeのFlexなどを用いるのもありだと思う。見た目だけでなく色々な機能を比較的手軽に利用できる。
とはいえ、きちんと覚えるには1ヶ月くらいはかかってしまいそうなのでリスクも大きい。
学生証を添付すればAdobe Flex Builder 3が無償で手にはいるとのこと。
統合開発環境はなかなか手に入らないので、こういうのをやってみる人がいても良いとは思う。
興味がある人がいればの話ではあるが。
(https://freeriatools.adobe.com/flex/)
ここまでくると、ユーザー側の使いやすさをもっと考える時期でもあると思う。
Ajaxを利用するなどと言うとさすがに無責任か。
AdobeのFlexなどを用いるのもありだと思う。見た目だけでなく色々な機能を比較的手軽に利用できる。
とはいえ、きちんと覚えるには1ヶ月くらいはかかってしまいそうなのでリスクも大きい。
学生証を添付すればAdobe Flex Builder 3が無償で手にはいるとのこと。
統合開発環境はなかなか手に入らないので、こういうのをやってみる人がいても良いとは思う。
興味がある人がいればの話ではあるが。
(https://freeriatools.adobe.com/flex/)
2008年12月18日木曜日
2008年12月17日水曜日
2008年12月14日日曜日
Google Maps Hacks
オライリーの本です。
今まで、この本に限らずGoogleMapsに関する本はあまり読んだことがなかった。
ShortestPathに使えるかは別として違う視点から見られるのは面白い。
マーカーを減らすのにも非常に面白い手法を用いている。
知らない機能はほとんどなかったが、使い方一つでこういうことも可能なのかと思わされることもある。
Ajax自体がそもそもそういうモノだったりもするのだが・・・。
今まで、この本に限らずGoogleMapsに関する本はあまり読んだことがなかった。
ShortestPathに使えるかは別として違う視点から見られるのは面白い。
マーカーを減らすのにも非常に面白い手法を用いている。
知らない機能はほとんどなかったが、使い方一つでこういうことも可能なのかと思わされることもある。
Ajax自体がそもそもそういうモノだったりもするのだが・・・。
2008年12月13日土曜日
2008年12月12日金曜日
2008年12月3日水曜日
2008年12月2日火曜日
2008年11月27日木曜日
2008年11月26日水曜日
最適化オンラインソルバー
最短路だけではなく、様々な最適化問題用オンラインソルバーの仕様について以前行った作業があまりまとめられてないのでまとめてみる。
・基本は現在のSDPAオンラインソルバー
入出力はほとんどの場合、テキストファイルによる入出力であるため、変数化して、追加作業が楽なようにする。
現時点で、タイトルや結果をメールで送るときの文面をのぞいては、ほとんど作業が終わっている。
solver/common_data.php
にソルバーのディレクトリと表示されるタイトルを書く。
solver/ にそのディレクトリを作り中にstatus.phpを書く。
これで、メインページにはそのソルバーが追加され、ファイルのアップロード等もできる。
パラメータファイル等の記述もあるため、それらの心配もすることはない。
あとはexecute.phpのページに実行のコマンドを書く必要がある。ここもなんとか共通化したい。
・基本は現在のSDPAオンラインソルバー
入出力はほとんどの場合、テキストファイルによる入出力であるため、変数化して、追加作業が楽なようにする。
現時点で、タイトルや結果をメールで送るときの文面をのぞいては、ほとんど作業が終わっている。
solver/common_data.php
にソルバーのディレクトリと表示されるタイトルを書く。
solver/ にそのディレクトリを作り中にstatus.phpを書く。
これで、メインページにはそのソルバーが追加され、ファイルのアップロード等もできる。
パラメータファイル等の記述もあるため、それらの心配もすることはない。
あとはexecute.phpのページに実行のコマンドを書く必要がある。ここもなんとか共通化したい。
2008年11月24日月曜日
2008年11月23日日曜日
経由点バージョンその15
先日の通り、Operaでは右クリックできない。(設定を変えればできるかはユーザーではないので不明)
そこでOperaでは別処理として、最後のマーカーを削除するボタンをつけた。
これですべてのブラウザで最低限の機能は出そろった。
そこでOperaでは別処理として、最後のマーカーを削除するボタンをつけた。
これですべてのブラウザで最低限の機能は出そろった。
2008年11月22日土曜日
経由点バージョンその14
思っていたより時間がかかってしまったようだが、無事削除機能を備えた経由点バージョンも公開された。(正確には更新か・・。)
バグというバグは見つからなかったが使ってるマシンのIEがおかしかったため、各ブラウザの動作確認が遅れてしまったのが原因。
ブラウザによる問題は色々経験しているが、IEで起こるトラブルだけは原因不明で対処のしようがないから困る。
また、Operaでは右クリックで画像を表示とかのダイアログが出てしまう。
これは本家Google Mapsでもなってしまうのでこちらでは対応しにくい。
やはり無難に推奨ブラウザであるFirefox,Safari,Google Chrome辺りを使ってもらいたいというのが希望。
バグというバグは見つからなかったが使ってるマシンのIEがおかしかったため、各ブラウザの動作確認が遅れてしまったのが原因。
ブラウザによる問題は色々経験しているが、IEで起こるトラブルだけは原因不明で対処のしようがないから困る。
また、Operaでは右クリックで画像を表示とかのダイアログが出てしまう。
これは本家Google Mapsでもなってしまうのでこちらでは対応しにくい。
やはり無難に推奨ブラウザであるFirefox,Safari,Google Chrome辺りを使ってもらいたいというのが希望。
2008年11月21日金曜日
経由点バージョンその13
苦戦するかと思われていた処理もあっさり。
・消すマーカーがどのマーカーかをループで判定する。
・値をずらす
・マーカーの再作成
・マーカー数を1減らす
・終了
特にバグがなければこのまま公開になりそうだ。
・消すマーカーがどのマーカーかをループで判定する。
・値をずらす
・マーカーの再作成
・マーカー数を1減らす
・終了
特にバグがなければこのまま公開になりそうだ。
2008年11月20日木曜日
経由点バージョンその12
マーカーの番号変更の方法を考える。
マーカーのアイコンは、番号が上に振ってあるわけではなく、自分で1~10まで用意している。
すなわち、マーカーの番号を1個ずらすためには
・前のマーカーを移動する
・今あるマーカーを削除し、同じ場所に新しく作成し直す
のどちらかの操作が必要である。
後者の処理もそれほど負担がなかったのでそちらを採用することにした。
マーカーのアイコンは、番号が上に振ってあるわけではなく、自分で1~10まで用意している。
すなわち、マーカーの番号を1個ずらすためには
・前のマーカーを移動する
・今あるマーカーを削除し、同じ場所に新しく作成し直す
のどちらかの操作が必要である。
後者の処理もそれほど負担がなかったのでそちらを採用することにした。
2008年11月19日水曜日
経由点バージョンその11
これがこのバージョンの大きな仕様では最後の作業。
取り急ぎ削除の対応をしたが、今回は削除のバージョンアップといったところ。
機能は以下のような感じ。
・右クリックでどのマーカーを削除しても良い。
・削除したマーカーより後ろのマーカーは番号が一つずれるのでマーカーの番号を変更する。
・それに対応する変数の値を全て1つずらす。
これで削除に関しては問題ないであろう。作業を進めるのみ。
取り急ぎ削除の対応をしたが、今回は削除のバージョンアップといったところ。
機能は以下のような感じ。
・右クリックでどのマーカーを削除しても良い。
・削除したマーカーより後ろのマーカーは番号が一つずれるのでマーカーの番号を変更する。
・それに対応する変数の値を全て1つずらす。
これで削除に関しては問題ないであろう。作業を進めるのみ。
2008年11月18日火曜日
経由点バージョンその10
経由点指定バージョンで
いつの間にか最後のマーカーを右クリックすると消せるようになっている。
1 -> 2 -> 3 -> 4
とあると4だけ消せる。2を消したければ 4 -> 3 -> 2 と順番に消さなければならない。
ちょっと不便な気もするが、通常のviaバージョンから全てクリアの機能を削除しているだけなので大幅機能ダウンではない。
気づいていない方もいるかもしれないが、この経由点指定バージョンではドラッグしてアメリカの外にマーカーを持って行くとドラッグ前の点に戻るようになっている。
ちなみに、通常のGoogleMaps版では変更なく消滅する。
いつの間にか最後のマーカーを右クリックすると消せるようになっている。
1 -> 2 -> 3 -> 4
とあると4だけ消せる。2を消したければ 4 -> 3 -> 2 と順番に消さなければならない。
ちょっと不便な気もするが、通常のviaバージョンから全てクリアの機能を削除しているだけなので大幅機能ダウンではない。
気づいていない方もいるかもしれないが、この経由点指定バージョンではドラッグしてアメリカの外にマーカーを持って行くとドラッグ前の点に戻るようになっている。
ちなみに、通常のGoogleMaps版では変更なく消滅する。
2008年11月17日月曜日
2008年11月16日日曜日
経由点バージョンその9
引き続き作業中。
最後においたマーカーを消す場合、
現在のマーカーの個数を1個減らす。
最後のマーカーの緯度経度を0にする。
で処理すれば問題はない。
最低限これだけの機能はつける予定。
途中のマーカーを削除したい場合どうするかは模索中。
最後においたマーカーを消す場合、
現在のマーカーの個数を1個減らす。
最後のマーカーの緯度経度を0にする。
で処理すれば問題はない。
最低限これだけの機能はつける予定。
途中のマーカーを削除したい場合どうするかは模索中。
2008年11月15日土曜日
経由点バージョンその8
経由点バージョンのマーカー削除の作業を行っている。
基本的には使われていない右クリックによる動作で実現する予定。
GoogleMapsのイベントでは、
GEvent.addListener(map,"singlerightclick",function(point,src,overlay)){
処理
}
で実現できる。
マーカーを右クリックするとoverlayが指定されるため、
map.removeOverlay(overlay);
とでもやればマーカーが消えるだけならなんの問題もない。
基本的には使われていない右クリックによる動作で実現する予定。
GoogleMapsのイベントでは、
GEvent.addListener(map,"singlerightclick",function(point,src,overlay)){
処理
}
で実現できる。
マーカーを右クリックするとoverlayが指定されるため、
map.removeOverlay(overlay);
とでもやればマーカーが消えるだけならなんの問題もない。
2008年11月14日金曜日
経由点バージョンその7
管理を楽にするために、経由点バージョンの最大点数の指定を変数化した。
これで、1カ所変えるだけで移行できるため、マシンの拡張等があってもすぐに対応できる。
当たり前と言えば当たり前の作業だが、意外に手間取ってしまった。
JavascriptでFormの配列を読み込むには
document.form1.elements['hoge[' + (i) + ']'].value
にしなければならないらしい・・。
やればやるほどJavascriptがわからなくなってくる。
あと、PHPとJavascriptの連携ってのは面倒です。。
これで、1カ所変えるだけで移行できるため、マシンの拡張等があってもすぐに対応できる。
当たり前と言えば当たり前の作業だが、意外に手間取ってしまった。
JavascriptでFormの配列を読み込むには
document.form1.elements['hoge[' + (i) + ']'].value
にしなければならないらしい・・。
やればやるほどJavascriptがわからなくなってくる。
あと、PHPとJavascriptの連携ってのは面倒です。。
2008年11月13日木曜日
経由点バージョンその6
計10点まで対応。
このくらいならさほど速度の差を感じずに実行できる。
これ以上増やす意味もあまりないのでとりあえず10点で固定しておくことにする。
あと、経由点バージョンに足りないのは点の削除くらいだろうか。
このくらいならさほど速度の差を感じずに実行できる。
これ以上増やす意味もあまりないのでとりあえず10点で固定しておくことにする。
あと、経由点バージョンに足りないのは点の削除くらいだろうか。
2008年11月12日水曜日
経由点バージョンその5
公開されている経由点バージョン。
実際に使ってみると、通常版とあまり速度の差を感じられない。
5点くらいなら問題ないということか。
ちなみにIE8では相変わらず表示されたり表示されなかったりする。
実際に使ってみると、通常版とあまり速度の差を感じられない。
5点くらいなら問題ないということか。
ちなみにIE8では相変わらず表示されたり表示されなかったりする。
2008年11月11日火曜日
経由点バージョンその4
開発が進められていた入出力ともにGoogleMapsを用いた経由点バージョンが週末には公開されていたようだ。
先日書いたようなバグもそれに伴い修正されている。
どうやら今までのバージョンにも番号付きマーカーを利用するような設定にしたようだ。
新しいバージョンでは経由点を3個(すなわち合計5点まで)までしか指定できないのが残念なところ。
近いうちには10点くらいまでは対応するだろう。
先日書いたようなバグもそれに伴い修正されている。
どうやら今までのバージョンにも番号付きマーカーを利用するような設定にしたようだ。
新しいバージョンでは経由点を3個(すなわち合計5点まで)までしか指定できないのが残念なところ。
近いうちには10点くらいまでは対応するだろう。
2008年11月10日月曜日
経由点バージョンその3
出力だけGoogleMapsバージョンではfromEncoded機能を使っていなかった。
そこで、今回の機会でこちらも書き直すことに。
あれ?一部線が表示されていない。
おかしいと思って前のソースと見比べてみてもなんで正しく動くのかなぁと小一時間考えてしまった。
結局前のソースもおかしかったというオチ。
きちんと動いてたと思ってたんですが動いてなかったみたいです。
今までバグありのまま表示されてたようで早急に修正予定。
そこで、今回の機会でこちらも書き直すことに。
あれ?一部線が表示されていない。
おかしいと思って前のソースと見比べてみてもなんで正しく動くのかなぁと小一時間考えてしまった。
結局前のソースもおかしかったというオチ。
きちんと動いてたと思ってたんですが動いてなかったみたいです。
今までバグありのまま表示されてたようで早急に修正予定。
2008年11月9日日曜日
経由点バージョンその2
GoogleMapsで、番号付きマーカーを利用する方法は以下の通り。
1,番号付きマーカーのアイコンを準備する。
2,アイコン指定する。
これだけでよい。
念のためコマンドを書いておくと、
var num = 1;
var icon = new GIcon();
icon.image = "./marker" + num + ".png";
icon.shadow = "./shadow.png";
icon.iconSize = new GSize(20,34);
icon.shadowSize = new GSize(37,34);
icon.iconAnchor = new GPoint(10,34);
icon.infoWindowAnchor = new GPoint(10,0);
var newMarker = new GMarker(point,{icon:icon , draggable: true});
細かい説明は省くが、必要な値が入っていないと、ドラッグできなかったり表示できなかったりするので注意が必要。
特にドラッグが必要ない、影も必要なければ
icon.image
icon.iconSize
icon.iconAnchor
だけ指定すれば良い。(試してないですが)
番号付きマーカーの作成には
http://www.lumiere-couleur.com/pub/soft/markers/
のサイトが便利である。
1,番号付きマーカーのアイコンを準備する。
2,アイコン指定する。
これだけでよい。
念のためコマンドを書いておくと、
var num = 1;
var icon = new GIcon();
icon.image = "./marker" + num + ".png";
icon.shadow = "./shadow.png";
icon.iconSize = new GSize(20,34);
icon.shadowSize = new GSize(37,34);
icon.iconAnchor = new GPoint(10,34);
icon.infoWindowAnchor = new GPoint(10,0);
var newMarker = new GMarker(point,{icon:icon , draggable: true});
細かい説明は省くが、必要な値が入っていないと、ドラッグできなかったり表示できなかったりするので注意が必要。
特にドラッグが必要ない、影も必要なければ
icon.image
icon.iconSize
icon.iconAnchor
だけ指定すれば良い。(試してないですが)
番号付きマーカーの作成には
http://www.lumiere-couleur.com/pub/soft/markers/
のサイトが便利である。
2008年11月8日土曜日
2008年11月7日金曜日
2008年11月6日木曜日
Operaの修正
原因を一から探ってみると、
最短距離は表示されるが最短時間が表示されないことがわかった。
その辺に原因がある(Operaで読み込んでくれない)のだろうと推測し、ソースを書き直す。
色々事情があり、それぞれ独立させていたのだがこれを機に関数化してまとめてみたところ普通に動いた。
他のブラウザでも問題ないため、結果的に見ればソースが綺麗になってOperaも動くし良かった。
ちなみに相変わらずIE8では動かない。完全にIE8のバグで対応策も一応公開されてますが、面倒なので後回し。確認のため言っておくと、正式版のIE7では問題ない。また、IEでの実行は推奨していない。
最短距離は表示されるが最短時間が表示されないことがわかった。
その辺に原因がある(Operaで読み込んでくれない)のだろうと推測し、ソースを書き直す。
色々事情があり、それぞれ独立させていたのだがこれを機に関数化してまとめてみたところ普通に動いた。
他のブラウザでも問題ないため、結果的に見ればソースが綺麗になってOperaも動くし良かった。
ちなみに相変わらずIE8では動かない。完全にIE8のバグで対応策も一応公開されてますが、面倒なので後回し。確認のため言っておくと、正式版のIE7では問題ない。また、IEでの実行は推奨していない。
2008年11月5日水曜日
Vine4.x
ちょっと話題がそれてVineの話。
日本語の表示が綺麗で動作も軽く、リモートアクセスで使う分にはなんの不自由もないVine。
別にVineにこだわってるわけではないが5.xの登場が待ち遠しい。予定が遅れてるらしく来年の頭になりそうな感じ。
Vine4.xではFirefox3に対応していなかったが、今は対応済。
apt-get install Firefox3
でインストールできるようだ。Firefox2との共存も問題ない。
どこかの会社が作ったOSドッキングブラウザみたいに前のバージョンが使えなくなることもないので心配ない。
Shortest path Graphicも試してみたがやはり3の方が圧倒的に早い。
仮想マシンのせいなのかOSのせいなのかブラウザのせいなのかはわからないが、WindowsのFirefox3の方が実行が早い気がする。
中のプログラムは速いのがいいが、オンラインソルバーのようなものは様々な状況が関わってくるので体感時間も重要視しなければならない。
最終描画まで同じ時間でも表示のタイミングを変えるだけで印象が大きく変わるのが怖いところ。
日本語の表示が綺麗で動作も軽く、リモートアクセスで使う分にはなんの不自由もないVine。
別にVineにこだわってるわけではないが5.xの登場が待ち遠しい。予定が遅れてるらしく来年の頭になりそうな感じ。
Vine4.xではFirefox3に対応していなかったが、今は対応済。
apt-get install Firefox3
でインストールできるようだ。Firefox2との共存も問題ない。
どこかの会社が作ったOSドッキングブラウザみたいに前のバージョンが使えなくなることもないので心配ない。
Shortest path Graphicも試してみたがやはり3の方が圧倒的に早い。
仮想マシンのせいなのかOSのせいなのかブラウザのせいなのかはわからないが、WindowsのFirefox3の方が実行が早い気がする。
中のプログラムは速いのがいいが、オンラインソルバーのようなものは様々な状況が関わってくるので体感時間も重要視しなければならない。
最終描画まで同じ時間でも表示のタイミングを変えるだけで印象が大きく変わるのが怖いところ。
2008年11月4日火曜日
2008年11月3日月曜日
2008年10月29日水曜日
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での表示が遅いため、色々改善策が出てきている。
2008年9月15日月曜日
GoogleMapsのクロスブラウザ問題
今回もShortest Path Graphicに新機能などを入れるためにいくつかクロスブラウザ問題が発生している。
一番重要なPolylineの表示だが、IEではデフォルトでは表示することが出来ない。
などをincludeする必要がある。
Operaでは
と言うように使えず、色の指定はRGB値を指定しなければならない。これだと青のラインが表示されてしまった。
大きな問題は上の2つくらいだろうか。
FirefoxでもJavascriptからHTML内のオブジェクトとつなげにくかったりといった直接は関係ないものもあったが、厳密に記述すれば解決できるのでそれを心がけていけばよい。
これだけブラウザが増えてしまうと実験だけでも一苦労だ。
特にIEはJavascriptが遅すぎてCPUファンはうなり出すわ結果は出ないわでストレスがたまります。
スタイルシートは一番IEが気持ちを読み取ってくれる気がしますけど。
個人的にはFirefoxメイン、Google系のアプリならGoogleChromeが良いかと思ってます。Chromeはセキュリティホールも結構見つかってるようですし。
一番重要なPolylineの表示だが、IEではデフォルトでは表示することが出来ない。
<html xmlns="http://www.w3.org/1999/xhtml">
などをincludeする必要がある。
Operaでは
echo("map.addOverlay(new GPolyline(points,'red',"5","0.7"));");
と言うように使えず、色の指定はRGB値を指定しなければならない。これだと青のラインが表示されてしまった。
大きな問題は上の2つくらいだろうか。
FirefoxでもJavascriptからHTML内のオブジェクトとつなげにくかったりといった直接は関係ないものもあったが、厳密に記述すれば解決できるのでそれを心がけていけばよい。
これだけブラウザが増えてしまうと実験だけでも一苦労だ。
特にIEはJavascriptが遅すぎてCPUファンはうなり出すわ結果は出ないわでストレスがたまります。
スタイルシートは一番IEが気持ちを読み取ってくれる気がしますけど。
個人的にはFirefoxメイン、Google系のアプリならGoogleChromeが良いかと思ってます。Chromeはセキュリティホールも結構見つかってるようですし。
2008年9月14日日曜日
GoogleMapsを使ってみる15
入出力をGoogleMapsにしたShortest Path Graphicも来週くらいには公開になりそうだ。
新バージョンの新機能等は以下の通り。
1,入力画面もGoogleMaps
2,入出力ともにマウスホイールでのZoomIn、ZoomOutに対応
3,出力画面の最初は入力画面の縮尺、中心座標で表示
2の機能マウスホイールに関しては、他のバージョンの出力にはすでに先行導入されている。前々から入れたかったのだが、APIをただ見逃していただけでした。
と入れるだけで実装できる。
3は今までは2点間の中心座標とZoom値11というようにしていた(特に何の根拠もない)。今回は入力もGoogleMapsということでそのような仕様にした。
今までのバージョンも中心だと道を外れる可能性もあり、始点を中心に表示するよう変更されるかもしれない。
新バージョンの新機能等は以下の通り。
1,入力画面もGoogleMaps
2,入出力ともにマウスホイールでのZoomIn、ZoomOutに対応
3,出力画面の最初は入力画面の縮尺、中心座標で表示
2の機能マウスホイールに関しては、他のバージョンの出力にはすでに先行導入されている。前々から入れたかったのだが、APIをただ見逃していただけでした。
map.enableScrollWheelZoom();
と入れるだけで実装できる。
3は今までは2点間の中心座標とZoom値11というようにしていた(特に何の根拠もない)。今回は入力もGoogleMapsということでそのような仕様にした。
今までのバージョンも中心だと道を外れる可能性もあり、始点を中心に表示するよう変更されるかもしれない。
2008年9月13日土曜日
GoogleMapsを使ってみる14
Shortest Path Graphicの入出力ともにGoogleMapsを用いたバージョンも作成が進んでいるようだ。
昨日の問題点1
クリックされた場所が地図にある保証がない(現時点であるのは全米のみ)
については地道な作業をすることでなんとか実装している。
GoogleMapsの機能として住所が分かればそこから緯度経度を出すことは可能なのだが、逆が出来ないようでちょっと面倒な作業になってしまった。
inUSAという関数を作り、戻り値が1ならUSA内(正確にはハワイとアラスカは除く)で0ならアウト。といったかんじ。
大まかには長方形で囲んで中にあるか外にあるかを判定。
それだけではカナダとの国境などが危ないので、もう少し判定を厳しくする。
カナダとの国境は幸い、大まかには緯度が同じ地図上で言う真横にひかれたラインと斜めにひかれた直線でいる。そのため、斜めの直線とクリックした点の右上右下判定だけすればある程度細の判断までできる。
厳密にはまだまだだが、実装レベルとしては悪くないのではないかと思う。
自分一人では何とも言えないので色々意見をもらうことになるだろう。
昨日の問題点1
クリックされた場所が地図にある保証がない(現時点であるのは全米のみ)
については地道な作業をすることでなんとか実装している。
GoogleMapsの機能として住所が分かればそこから緯度経度を出すことは可能なのだが、逆が出来ないようでちょっと面倒な作業になってしまった。
inUSAという関数を作り、戻り値が1ならUSA内(正確にはハワイとアラスカは除く)で0ならアウト。といったかんじ。
大まかには長方形で囲んで中にあるか外にあるかを判定。
それだけではカナダとの国境などが危ないので、もう少し判定を厳しくする。
カナダとの国境は幸い、大まかには緯度が同じ地図上で言う真横にひかれたラインと斜めにひかれた直線でいる。そのため、斜めの直線とクリックした点の右上右下判定だけすればある程度細の判断までできる。
厳密にはまだまだだが、実装レベルとしては悪くないのではないかと思う。
自分一人では何とも言えないので色々意見をもらうことになるだろう。
2008年9月12日金曜日
GoogleMapsを使ってみる13
GoogleMapsバージョンも公開されたShortest Path Graphicだが、どうやら次は入力部分もGoogleMapsに対応する予定のようだ。
入力にもGoogleMapsを使う意味や利点は以下の通り。
1,結果もGoogleMapsなのだから当たり前。
2,マーカーのドラッグ機能などを駆使できる。
3,拡大縮小が自由にできるため細かい値を指定しやすい。
問題点は以下の通り。
1,クリックされた場所が地図にある保証がない(現時点であるのは全米のみ)
2,すべての計算が全米になってしまうので負荷がかかる。
1はユーザーが正しいものを入力してくれると信じれば特に気にする必要はないため、実装は後にする方針。緯度経度の取得はできるので最低限なんとかなるだろうということもあり楽観視しているという噂もある。
2はとりあえず見ないことにする。P2Pバージョンに限定するなどの処置を取ることも場合によっては視野に入れる必要があるかもしれない。
利点の2について少し説明する。
基本的に今まで用いてきた技術を変えていけば作成可能になるが、ドラッグイベントの処理は少々面倒なので今まで使っていたのとは違い以下のようにしてみる。
でドラッグできるマーカーが作成できる。
また、load()関数の中で
しておけばよい。marker1とmarker2を使い、3つめのマーカーが作られたときに古い方のマーカーを消す作業を入れている。これは既存のShortest Path Graphicと同じような仕様だ。
参考:http://www.tatamilab.jp/~ooi1/GoogleSample5.html
入力にもGoogleMapsを使う意味や利点は以下の通り。
1,結果もGoogleMapsなのだから当たり前。
2,マーカーのドラッグ機能などを駆使できる。
3,拡大縮小が自由にできるため細かい値を指定しやすい。
問題点は以下の通り。
1,クリックされた場所が地図にある保証がない(現時点であるのは全米のみ)
2,すべての計算が全米になってしまうので負荷がかかる。
1はユーザーが正しいものを入力してくれると信じれば特に気にする必要はないため、実装は後にする方針。緯度経度の取得はできるので最低限なんとかなるだろうということもあり楽観視しているという噂もある。
2はとりあえず見ないことにする。P2Pバージョンに限定するなどの処置を取ることも場合によっては視野に入れる必要があるかもしれない。
利点の2について少し説明する。
基本的に今まで用いてきた技術を変えていけば作成可能になるが、ドラッグイベントの処理は少々面倒なので今まで使っていたのとは違い以下のようにしてみる。
var newMarker = new GMarker(point, {draggable: true});
でドラッグできるマーカーが作成できる。
var map;
var marker_num=0;
var marker1=null;
var marker2=null;
var tmp_marker=null;
var marker1_tmp = null;
function eventMarker(point){
map.closeInfoWindow();
var newMarker = new GMarker(point, {draggable: true});
if(marker_num % 2 == 1){
tmp_marker = marker2;
marker2 = newMarker;
}
else{
tmp_marker = marker1;
marker1 = newMarker;
}
GEvent.addListener(newMarker, "dragstart", function() {
map.closeInfoWindowHtml();
});
GEvent.addListener(newMarker, "dragend", function() {
var currentPoint = newMarker.getPoint();
newMarker.openInfoWindowHtml("latitude: " + (currentPoint.lat()) + "
longitude: " + (currentPoint.lng()));
});
GEvent.addListener(newMarker, "click", function() {
var currentPoint = newMarker.getPoint();
newMarker.openInfoWindowHtml("latitude: " + (currentPoint.lat()) + "
longitude: " + (currentPoint.lng()));
});
map.addOverlay(newMarker);
if(tmp_marker!=null)map.removeOverlay(tmp_marker);
marker_num++;
}
また、load()関数の中で
GEvent.addListener(map, "click", function(overlay, point){
if(point){
eventMarker(point);
}
});
しておけばよい。marker1とmarker2を使い、3つめのマーカーが作られたときに古い方のマーカーを消す作業を入れている。これは既存のShortest Path Graphicと同じような仕様だ。
参考:http://www.tatamilab.jp/~ooi1/GoogleSample5.html
2008年9月11日木曜日
GoogleMapsバージョン
例のページ(http://opt.indsys.chuo-u.ac.jp/portal/)でGoogleMapsを使用したバージョンもどうやら公開されたようだ。
公開はされたが、拡大を大きくすると若干のずれが生じてしまうのは今も変わらないのでメルカトル図法用の座標計算をし直すのを導入するしかない。
また、ほぼ同時に全バージョンで時間優先、距離優先の選択肢が追加されたようだ。
GoogleMapsのP2Pバージョンではその両方の結果を表示するオプションもついている。
公開はされたが、拡大を大きくすると若干のずれが生じてしまうのは今も変わらないのでメルカトル図法用の座標計算をし直すのを導入するしかない。
また、ほぼ同時に全バージョンで時間優先、距離優先の選択肢が追加されたようだ。
GoogleMapsのP2Pバージョンではその両方の結果を表示するオプションもついている。
2008年9月10日水曜日
Google Mapsの道検索
GoogleMapsの道検索では厳密な最短路は求めていない。
もちろん車で移動することを前提にしているならば、時間優先の探索になるであろうしその方が現実的だ。
データは違うものの時間優先検索で検索した結果と「ほぼ」同じになっている。
違う点は、GoogleMapsの方が分岐の近くでも大きな道路を選んでいる。
スタートとゴールの近くの大通りまで出てあとは大通りを進めばよいと言う発想だろう。
これを見ても時間優先の厳密解ではないと思われる。
そもそも、信号等の不確定な状況下なので厳密解まで必要ないということなのだろう。
もちろん車で移動することを前提にしているならば、時間優先の探索になるであろうしその方が現実的だ。
データは違うものの時間優先検索で検索した結果と「ほぼ」同じになっている。
違う点は、GoogleMapsの方が分岐の近くでも大きな道路を選んでいる。
スタートとゴールの近くの大通りまで出てあとは大通りを進めばよいと言う発想だろう。
これを見ても時間優先の厳密解ではないと思われる。
そもそも、信号等の不確定な状況下なので厳密解まで必要ないということなのだろう。
2008年9月9日火曜日
2008年9月8日月曜日
2008年9月7日日曜日
GoogleMapsを使ってみる12
GoogleMapsでは渋滞情報という機能がアメリカの方にはある。
各道路の渋滞情報を見ることが出来る機能で、おそらくGoogleがカーナビと連携して使うことになるのだと思われる。
map.addOverlay(trafficInfo);
で付け加えることが出来る。
直接最短路とは関係がないが、時間優先で最短路を求めてみると渋滞に巻き込まれやすいことがわかる。時間優先の最短路は、渋滞を考慮しているわけではなく最高速度で決まっているため、多くの人が最高速度が速い道を使っていると言うことだろう。
実際の速度とは大きく違うことになりそうだが。
各道路の渋滞情報を見ることが出来る機能で、おそらくGoogleがカーナビと連携して使うことになるのだと思われる。
map.addOverlay(trafficInfo);
で付け加えることが出来る。
直接最短路とは関係がないが、時間優先で最短路を求めてみると渋滞に巻き込まれやすいことがわかる。時間優先の最短路は、渋滞を考慮しているわけではなく最高速度で決まっているため、多くの人が最高速度が速い道を使っていると言うことだろう。
実際の速度とは大きく違うことになりそうだが。
2008年9月5日金曜日
Google Chrome
GoogleからGoogle Chromeというブラウザが出たので早速インストールしてみた。
別にGoogleのブログを使ってるから宣伝するというわけではないが、速さ重視と言うことで「最速」とも言われているFirefox3と比べて気になったというのもある。
Google ChromeはAppleのHTML描画が高速な「Webkit」を用いている。またJavaScriptを独自のV8エンジン(名前はV型8気筒エンジンに由来するらしい)を搭載して高速化を実現している。
残ったログを見てみるとユーザーエージェント(UA)は
AppleWebKit/525.13 (KHTML, like Gecko) Chrome/0.2.149.27 Safari/525.13
となっている。
Shortest Path Graphicの各バージョンで試してみたが問題なく動作することを確認している。
また、実際に動作させてみるとUSAのグラフで体感2倍くらいFirefoxより表示が速い。これは結構大きい。
GoogleMapsの拡大縮小などの処理はFirefoxより体感3倍くらい違っている。
どちらも正確に計ったわけではないが、体感速度というのはこういうサービスでは重要なことであろう。
機能面ではFirefoxの方が上であり、どちらを取るかはユーザー次第と言ったところか。
別にGoogleのブログを使ってるから宣伝するというわけではないが、速さ重視と言うことで「最速」とも言われているFirefox3と比べて気になったというのもある。
Google ChromeはAppleのHTML描画が高速な「Webkit」を用いている。またJavaScriptを独自のV8エンジン(名前はV型8気筒エンジンに由来するらしい)を搭載して高速化を実現している。
残ったログを見てみるとユーザーエージェント(UA)は
AppleWebKit/525.13 (KHTML, like Gecko) Chrome/0.2.149.27 Safari/525.13
となっている。
Shortest Path Graphicの各バージョンで試してみたが問題なく動作することを確認している。
また、実際に動作させてみるとUSAのグラフで体感2倍くらいFirefoxより表示が速い。これは結構大きい。
GoogleMapsの拡大縮小などの処理はFirefoxより体感3倍くらい違っている。
どちらも正確に計ったわけではないが、体感速度というのはこういうサービスでは重要なことであろう。
機能面ではFirefoxの方が上であり、どちらを取るかはユーザー次第と言ったところか。
2008年9月4日木曜日
GoogleMapsを使ってみる11
今までの通常のShortest Path Graphicにもあった経由点を指定できるバージョン。
こちらもGoogleMapsに対応させるべく作業を進めている。
当初は、小一時間程度で終わると楽観視していたが、諸処に問題が発生することが次第に分かってきてだいぶ手間取っている。
座標の入力からクエリファイルの書き出しまではそのまま使用しているので問題はない。
プログラムに渡して出力が帰ってきてからが少々面倒になる。
前回の話にも出たマーカーはsetCenterの後でなければならないという仕様は意外に厄介な仕様になっている。
そもそも、Centerの位置をどこにしようかというのは難しいのだが・・。
こちらもGoogleMapsに対応させるべく作業を進めている。
当初は、小一時間程度で終わると楽観視していたが、諸処に問題が発生することが次第に分かってきてだいぶ手間取っている。
座標の入力からクエリファイルの書き出しまではそのまま使用しているので問題はない。
プログラムに渡して出力が帰ってきてからが少々面倒になる。
前回の話にも出たマーカーはsetCenterの後でなければならないという仕様は意外に厄介な仕様になっている。
そもそも、Centerの位置をどこにしようかというのは難しいのだが・・。
2008年9月3日水曜日
GoogleMapsを使ってみる10
マーカーを使って緯度経度を表示するという話を前回したが、実際色々やってみると表示されないことがあり原因を調べてみた。
これはどこにいれてもいいというわけではなく、
のようにsetCenterメソッドを先にいれる必要があるらしい。
そうしないとJavaScript側でエラーを返されてしまう。
なぜそのような仕様かはGoogleに聞かないと分からないですが。
これに気づくのに時間がかかりすぎてしまい、後々手間取ることになってしまいました。
var source_info = 'hoge';
var dist_info = 'hogehoge';
var marker1 = new makeMarker(point_source, source_info);
var marker2 = new makeMarker(point_dist, dist_info);
これはどこにいれてもいいというわけではなく、
map.setCenter(new GLatLng(41.2,-73.55), 11);
のようにsetCenterメソッドを先にいれる必要があるらしい。
そうしないとJavaScript側でエラーを返されてしまう。
なぜそのような仕様かはGoogleに聞かないと分からないですが。
これに気づくのに時間がかかりすぎてしまい、後々手間取ることになってしまいました。
2008年9月2日火曜日
GoogleMapsを使ってみる9
GoogleMapsのOpenInfoWindowを使用して始点と終点に緯度経度を付け加えてみた。
このように、関数を使って、イベントを作成しておくと後が楽。
とすれば実際にマーカーが表示される。
この場合、point_sourceなどは、GLatLngでセットしておく必要がある。
HTMLタグを使いたいときは上の方のOpenInfoWindowをOpenInfoWindoHtmlにすればよい。
参考:http://japonyol.net/editor/googlemaps.html
function makeMarker(point , info_text){
var marker = new GMarker(point);
GEvent.addListener(marker, "click" ,function(){
marker.openInfoWindow(info_text);
});
return marker;
}
このように、関数を使って、イベントを作成しておくと後が楽。
var source_info = 'hoge';
var dist_info = 'hogehoge';
var marker1 = new makeMarker(point_source, source_info);
var marker2 = new makeMarker(point_dist, dist_info);
とすれば実際にマーカーが表示される。
この場合、point_sourceなどは、GLatLngでセットしておく必要がある。
HTMLタグを使いたいときは上の方のOpenInfoWindowをOpenInfoWindoHtmlにすればよい。
参考:http://japonyol.net/editor/googlemaps.html
2008年9月1日月曜日
GoogleMapsを使ってみる8
GoogleMapsバージョンで新しく加えようと思っている機能(すでに実装されているものもあり)は以下の通りだ。
・距離としての最短路を求めるか時間(速度制限等を考慮)を最短にする道かを選択。
両方同時も考えているが、問題が生じる可能性もあり詳細は考え中。
・各マーカーに緯度軽度の情報を加える。
GoogleMapsのOpenInfoWindowを使用。
・入力された始点と終点が両方表示される縮尺に自動変更。
緯度経度の値から計算するしかない。
現在は適当な縮尺で固定して、中心は2点間の中心にしている。
・距離としての最短路を求めるか時間(速度制限等を考慮)を最短にする道かを選択。
両方同時も考えているが、問題が生じる可能性もあり詳細は考え中。
・各マーカーに緯度軽度の情報を加える。
GoogleMapsのOpenInfoWindowを使用。
・入力された始点と終点が両方表示される縮尺に自動変更。
緯度経度の値から計算するしかない。
現在は適当な縮尺で固定して、中心は2点間の中心にしている。
2008年8月31日日曜日
GoogleMapsを使ってみる7
前回、実際に実装したという話をした。
場所によっては地球が丸いからか地図データが違うからかはさておき、やはりずれているのが気になる部分がある。
とはいえ橋などの一番重要な部分に問題がないのが幸いだろう。
国道?のような大きな通りでもずれが出ている部分があるが、道路の形と線の形が似ているため、目分量で修正することもできる。
場所によっては地球が丸いからか地図データが違うからかはさておき、やはりずれているのが気になる部分がある。
とはいえ橋などの一番重要な部分に問題がないのが幸いだろう。
国道?のような大きな通りでもずれが出ている部分があるが、道路の形と線の形が似ているため、目分量で修正することもできる。
2008年8月30日土曜日
GoogleMapsを使ってみる6
今までの話を総合して下のような形でGoogleMapsを使った最短路オンラインソルバーを実際に作ってみた。
・入力ページは今までと同じ(2点をクリックしてSubmit)
・計算時に画像の作成、結合処理が不要なので削除。
・上記の代わりに到達点までのルートを出力。
・出力ページはシンプルにGoogleMapsが出力されるのみ。
実際に動作させてみるとおおむね問題なく動作。
心配されていた処理の遅さも気になることはない。(ナローバンド環境下ではわからないが)
地図データの違いからか地球が丸いからかはわからないが、道のずれも多少はあるもののそこまで致命的ではない。
・入力ページは今までと同じ(2点をクリックしてSubmit)
・計算時に画像の作成、結合処理が不要なので削除。
・上記の代わりに到達点までのルートを出力。
・出力ページはシンプルにGoogleMapsが出力されるのみ。
実際に動作させてみるとおおむね問題なく動作。
心配されていた処理の遅さも気になることはない。(ナローバンド環境下ではわからないが)
地図データの違いからか地球が丸いからかはわからないが、道のずれも多少はあるもののそこまで致命的ではない。
2008年8月29日金曜日
GoogleMapsを使ってみる5
引き続き問題点を。
今回こちらで用いているデータは交差点から交差点への座標(緯度経度)である。
すなわち地図データがないためカーブはすべて直線で表されることになる。
大きな問題のようにも見えるが、実際はそこまでは1本道のはずなのでそれほどではないはず。(ただし、見た目が悪くなる可能性はある)
入力にGoogleMapsを用いた場合USAデータ以外に対応していない現在はそこをどうするかを考えなくてはならない。
マーカーのセット時にUSA内かを判断するなりしなければならない。
とりあえずは入力は今までのページでいいだろう。
今回こちらで用いているデータは交差点から交差点への座標(緯度経度)である。
すなわち地図データがないためカーブはすべて直線で表されることになる。
大きな問題のようにも見えるが、実際はそこまでは1本道のはずなのでそれほどではないはず。(ただし、見た目が悪くなる可能性はある)
入力にGoogleMapsを用いた場合USAデータ以外に対応していない現在はそこをどうするかを考えなくてはならない。
マーカーのセット時にUSA内かを判断するなりしなければならない。
とりあえずは入力は今までのページでいいだろう。
2008年8月28日木曜日
GoogleMapsを使ってみる4
実際に実装するときの問題点を確認。
・実行時間はどうか?
・グラフデータに違いがある。
・その他
実行時間についてはやってみないと分からないとしかいえません。
ただ、GoogleMaps自体がそんなに軽くないし動かしたりするとCPUががんばっちゃったりします。ラインを引くのは数本はやってみたけど大丈夫な予感。
グラフデータに違いがあるというのは今回の最大の問題点。
GoogleMapsで使用されているデータと使用しているTigerのデータでは少し違いがあること。
これが細かいところに影響してくるでしょう・・。
その他
微妙に規約に引っかかりそうだったけどセーフな部分。
リアルタイムルート案内を禁止しているみたいです。車両と通信するシステムについてだからとりあえず問題ないはずだけど。
・実行時間はどうか?
・グラフデータに違いがある。
・その他
実行時間についてはやってみないと分からないとしかいえません。
ただ、GoogleMaps自体がそんなに軽くないし動かしたりするとCPUががんばっちゃったりします。ラインを引くのは数本はやってみたけど大丈夫な予感。
グラフデータに違いがあるというのは今回の最大の問題点。
GoogleMapsで使用されているデータと使用しているTigerのデータでは少し違いがあること。
これが細かいところに影響してくるでしょう・・。
その他
微妙に規約に引っかかりそうだったけどセーフな部分。
リアルタイムルート案内を禁止しているみたいです。車両と通信するシステムについてだからとりあえず問題ないはずだけど。
2008年8月27日水曜日
GoogleMapsを使ってみる3
前回までの話を使うとそのまま、最短路問題に移行できる。
事前情報ではラインを引くのが遅いというものもあったがいかに・・。
事前操作としては、
1、座標の修正。
2、ページの作成。
座標の修正は、座標をGoogleMaps用に緯度経度に変換する作業。
元のグラフデータが緯度経度を元にして作られているのでそれほど大きな問題はない。
ページの作成。
出力ページは完全にGoogleMaps依存のページに変更。
比べるという意味で、今までの画面はあってもいいかともおもう。
入力ページは
1,今までと変わらず。
2,こっちもGoogleMaps使っちゃおう。
その2択かなぁと。
事前情報ではラインを引くのが遅いというものもあったがいかに・・。
事前操作としては、
1、座標の修正。
2、ページの作成。
座標の修正は、座標をGoogleMaps用に緯度経度に変換する作業。
元のグラフデータが緯度経度を元にして作られているのでそれほど大きな問題はない。
ページの作成。
出力ページは完全にGoogleMaps依存のページに変更。
比べるという意味で、今までの画面はあってもいいかともおもう。
入力ページは
1,今までと変わらず。
2,こっちもGoogleMaps使っちゃおう。
その2択かなぁと。
2008年8月26日火曜日
GoogleMapsを使ってみる2
マーカーの設置方法。
var point = new GLatLng(33.613158, -117.640931);
var mk = new GMarker(point);
map.addOverlay(mk);
これだけでただのマーカーが出現する。
ラインの引き方。
point0 = new GLatLng(34.983939, -78.773673);
points.push(point0);
point1 = new GLatLng(34.984196, -78.775077);
points.push(point1);
point2 = new GLatLng(34.984277, -78.775519);
points.push(point2);
point3 = new GLatLng(34.984444, -78.775971);
points.push(point3);
map.addOverlay(new GPolyline(points,'red',1,1.0));
で、0->1->2->3のラインが引かれる。
ここまで来るとShortest Path Onlineも楽に実装出来るのではないかと思い始める。
var point = new GLatLng(33.613158, -117.640931);
var mk = new GMarker(point);
map.addOverlay(mk);
これだけでただのマーカーが出現する。
ラインの引き方。
point0 = new GLatLng(34.983939, -78.773673);
points.push(point0);
point1 = new GLatLng(34.984196, -78.775077);
points.push(point1);
point2 = new GLatLng(34.984277, -78.775519);
points.push(point2);
point3 = new GLatLng(34.984444, -78.775971);
points.push(point3);
map.addOverlay(new GPolyline(points,'red',1,1.0));
で、0->1->2->3のラインが引かれる。
ここまで来るとShortest Path Onlineも楽に実装出来るのではないかと思い始める。
2008年8月25日月曜日
GoogleMapsを使ってみる
実際にGoogleMapsがどんなものかと使ってみる。
APIキーを申し込んだらサンプルが表示されるのでそれをそのままコピペしたページは一応動作する。それを基準にちょこちょこ変えていくのが楽そうだ。
現時点でのバージョンは2がデフォルト。1を使って説明しているページもあるのでそこは注意。特に座標の設定が違う。
point = new GLatLng(34.983939, -78.773673);
のような感じ。
縮尺とか航空写真のボタン?はデフォルトでは出ないらしくオプション扱い。
map.addControl( new GSmallMapControl() );
map.addControl( new GMapTypeControl() );
SmallではなくLargeにすると縮尺?みたいなやつもでてくる。
右下に窓を表示して今の場所とかをみたいなら
map.addControl(new GOverviewMapControl());
で追加できる。
APIキーを申し込んだらサンプルが表示されるのでそれをそのままコピペしたページは一応動作する。それを基準にちょこちょこ変えていくのが楽そうだ。
現時点でのバージョンは2がデフォルト。1を使って説明しているページもあるのでそこは注意。特に座標の設定が違う。
point = new GLatLng(34.983939, -78.773673);
のような感じ。
縮尺とか航空写真のボタン?はデフォルトでは出ないらしくオプション扱い。
map.addControl( new GSmallMapControl() );
map.addControl( new GMapTypeControl() );
SmallではなくLargeにすると縮尺?みたいなやつもでてくる。
右下に窓を表示して今の場所とかをみたいなら
map.addControl(new GOverviewMapControl());
で追加できる。
2008年8月23日土曜日
Google Maps
GoogleMapsを利用して最短路を表示しようというのは前々から議論されている。
前持った情報では時間がかかるなど言われているが、最短路であればそれほど本数が増えないのではないかと考えている。
実際にやってみなければわからないが、GoogleMapsで最短距離が示されれば説得力もあがるしなんとか導入してみたいところだ。
前持った情報では時間がかかるなど言われているが、最短路であればそれほど本数が増えないのではないかと考えている。
実際にやってみなければわからないが、GoogleMapsで最短距離が示されれば説得力もあがるしなんとか導入してみたいところだ。
2008年8月22日金曜日
2008年8月21日木曜日
内部処理
昨日Shortest Path Graphic において、座標処理を緯度経度に変更していると書いた。
とはいえ、表示している値は座標なのでその値を軸に考えなければならない。
場所によっては緯度経度で入力したモノをもう一度座標に戻しているものもあり、一長一短である。
将来Google Mapsを使うとして必要なある点における緯度経度取得はできるような状況である。
非公開のクエリ作成ページでは座標とともに、実際の緯度経度を表示するようにしている。
とはいえ、表示している値は座標なのでその値を軸に考えなければならない。
場所によっては緯度経度で入力したモノをもう一度座標に戻しているものもあり、一長一短である。
将来Google Mapsを使うとして必要なある点における緯度経度取得はできるような状況である。
非公開のクエリ作成ページでは座標とともに、実際の緯度経度を表示するようにしている。
2008年8月20日水曜日
緯度経度
現在のShortest Path Graphic の座標の計算を緯度経度を用いるように変更している。
将来的にGoogle Mapsなどと連携できるとおもしろいと考えているため、そちらの仕様にあわせる必要があるためだ。
ちなみに現時点では見た目も結果も何の変化もない。
将来的にGoogle Mapsなどと連携できるとおもしろいと考えているため、そちらの仕様にあわせる必要があるためだ。
ちなみに現時点では見た目も結果も何の変化もない。
2008年8月16日土曜日
2008年8月15日金曜日
2008年8月14日木曜日
2008年8月12日火曜日
2008年8月11日月曜日
2008年8月10日日曜日
2008年8月9日土曜日
2008年8月8日金曜日
2008年8月7日木曜日
PHP
header(location:"url");
というのをページ遷移によく使っている。
ural?hoge1=xxx&hoge2=yyy
というようにすれば変数もGETで渡せるので非常に便利。
それを利用していたら
Header may not contain more than a single header, new line detected.
というのが出てきたんだけど、なんでしょうこれ。
変数の中に改行文字とか入ってるとまずいのかな??
最悪一旦ファイルに書き込み、それを読み込んでファイルを消すという方法もあるのでそこまで重要視してはいないがなんだかいろいろとしっくりこない。
というのをページ遷移によく使っている。
ural?hoge1=xxx&hoge2=yyy
というようにすれば変数もGETで渡せるので非常に便利。
それを利用していたら
Header may not contain more than a single header, new line detected.
というのが出てきたんだけど、なんでしょうこれ。
変数の中に改行文字とか入ってるとまずいのかな??
最悪一旦ファイルに書き込み、それを読み込んでファイルを消すという方法もあるのでそこまで重要視してはいないがなんだかいろいろとしっくりこない。
2008年8月6日水曜日
2008年8月5日火曜日
2008年8月4日月曜日
PHPからのプログラムの実行
PHPからプログラムやコマンドを実行するのにsystem、execなどが用意されている。また、shellの実行もshell_execなど別に用意されている。
Cでコンパイルしたバイナリで表示された値を取得したかったので何かいい方法がないか探したのだが直接はどうも読み出せなかった。
仕方がないので
binary.shにCでコンパイルしたファイルの実行を入れ、
ataigahosii = exec("sh ./binary.sh");
とやったら値を取得できた。本当はほかにいい方法があるのだろうけどとりあえずこれで行くことにする・・・。
Cでコンパイルしたバイナリで表示された値を取得したかったので何かいい方法がないか探したのだが直接はどうも読み出せなかった。
仕方がないので
binary.shにCでコンパイルしたファイルの実行を入れ、
ataigahosii = exec("sh ./binary.sh");
とやったら値を取得できた。本当はほかにいい方法があるのだろうけどとりあえずこれで行くことにする・・・。
2008年8月3日日曜日
クエリ仕様の公開に向けての作業
先日お伝えしたとおり、Shortest Path Graphic でクエリを直接入力できるようなバージョンを作成している。
全員が正しいクエリを入れてくれれば公開してもいいのだが、色々実験する人も出てくるであろうし世の中には悪い人もいるのでクエリのチェックをかけなくてはならない。
どんなファイルを入れてくるかわからないので色々テストもしなければならないので結構大変な作業になるかもしれない。
全員が正しいクエリを入れてくれれば公開してもいいのだが、色々実験する人も出てくるであろうし世の中には悪い人もいるのでクエリのチェックをかけなくてはならない。
どんなファイルを入れてくるかわからないので色々テストもしなければならないので結構大変な作業になるかもしれない。
2008年8月2日土曜日
クエリ仕様
Shortest Path Graphic に新たに、クエリを直接入力できるバージョンを作成している。
Dimacsのデータの一部を使用できるような設定になっているが、知らない人の方が多いであろう。
そこで、クエリ作成のページも作成し、設定した道順のクエリを出力できるようにした。
これは、実際にバイナリを配布することになった後でも使えるようにすることも目的にある。
Dimacsのデータの一部を使用できるような設定になっているが、知らない人の方が多いであろう。
そこで、クエリ作成のページも作成し、設定した道順のクエリを出力できるようにした。
これは、実際にバイナリを配布することになった後でも使えるようにすることも目的にある。
2008年8月1日金曜日
表示されないバグ
最近は少なかったが、Shortest Path Graphic で結果が表示されないことがあるバグが見つかっていたが、原因不明だった。
今回、超高解像度版だと頻繁に起こっていたので調べてみると表示できないのはブラウザやOSの問題ではないかという推測になっている。
Windowsだとほとんどのブラウザで表示できないがLinuxだと32ビット、64ビット関わらず、またFirefox2,3両方とも表示されている。
Shortest Path GraphicではLinux+Firefox(できればver.3)を推奨しているようだ。
今回、超高解像度版だと頻繁に起こっていたので調べてみると表示できないのはブラウザやOSの問題ではないかという推測になっている。
Windowsだとほとんどのブラウザで表示できないがLinuxだと32ビット、64ビット関わらず、またFirefox2,3両方とも表示されている。
Shortest Path GraphicではLinux+Firefox(できればver.3)を推奨しているようだ。
2008年7月31日木曜日
オープンキャンパス2
オープンキャンパスの時に学食のメニューが少なかった。
こういうときこそメニューをしっかりとそろえたり人件費を使ってもいいと思うのだが。
前にいた大学では学食の無料券を配っていた気がする。
もちろん無料券を配るだけでは意味がないし質も上げていかなければならないと思う。
こういうときこそメニューをしっかりとそろえたり人件費を使ってもいいと思うのだが。
前にいた大学では学食の無料券を配っていた気がする。
もちろん無料券を配るだけでは意味がないし質も上げていかなければならないと思う。
2008年7月30日水曜日
オープンキャンパス
先日オープンキャンパスがあって、今回のうちの研究室のメインはShortest Path Graphicであった。
そもそもコンピュータに興味のある学生はうちの学科にはこないのか、詳しい人はほとんどいなかった。
まだ高校生だし、学科の中身までわかる人は少ないのだろう。
学生には大学名や学科名だけじゃなく中まで考えて選んで欲しいと思う。
とはいえ日本の風潮が学歴社会だから微妙なのだが・・。
そもそもコンピュータに興味のある学生はうちの学科にはこないのか、詳しい人はほとんどいなかった。
まだ高校生だし、学科の中身までわかる人は少ないのだろう。
学生には大学名や学科名だけじゃなく中まで考えて選んで欲しいと思う。
とはいえ日本の風潮が学歴社会だから微妙なのだが・・。
2008年7月29日火曜日
2008年7月28日月曜日
2008年7月27日日曜日
ネーミング
何の名前でもセンスが問われる。
子供に変な名前をつける親がいたりと問題になったりしているが名前をつけられた方の身になって考えてもらいたいものだ。
今はShortest Path Graphicとして公開しているが、正式な名前は決まっていない。
Graphical Shortest Path や、Shortest Path Online Solver など色々名前の候補はあるが、略称もうまくなるようにしたいなど色々と難しい。
子供に変な名前をつける親がいたりと問題になったりしているが名前をつけられた方の身になって考えてもらいたいものだ。
今はShortest Path Graphicとして公開しているが、正式な名前は決まっていない。
Graphical Shortest Path や、Shortest Path Online Solver など色々名前の候補はあるが、略称もうまくなるようにしたいなど色々と難しい。
2008年7月26日土曜日
座標の調整
Shortest Path Graphic を利用するブラウザによっては、左上端の座標が(0,0)にならないものもある。
IEやSafari、Firefox2では(0,0)になるのだが、Firefox3、Operaでは少し大きめになってしまう。
それによってクリックしたつもりの場所と結果が違うとおもっていたユーザーが多いかもしれない。
実際に調べて、ブラウザによって判別するようにした。Firefox3、Operaではx,y座標共に取得した値より8を引いた値を入力の値としている。
試してみると微妙なところをクリックしても思った点を指定できている気がする。
IEやSafari、Firefox2では(0,0)になるのだが、Firefox3、Operaでは少し大きめになってしまう。
それによってクリックしたつもりの場所と結果が違うとおもっていたユーザーが多いかもしれない。
実際に調べて、ブラウザによって判別するようにした。Firefox3、Operaではx,y座標共に取得した値より8を引いた値を入力の値としている。
試してみると微妙なところをクリックしても思った点を指定できている気がする。
2008年7月25日金曜日
event.offset
座標を取得する際にJQueryを利用しているのは前にも書いた。
また、ブラウザにはCtrl + '+' or '-' などで拡大縮小することができるのだが普通のブラウザはそれによって座標が変わることはない。
IEはスクロールやそういった事象を考慮に入れている。
その割に画像のサイズ等の変更はしないため、取得する方法がわからなかったが、
x = event.offsetX;
y = event.offsetY;
で取得できることがわかった。ブラウザによって仕様が違いすぎて困る・・。
できればIEは使いたくないがシェアが大きすぎる以上仕方がない・・。
また、ブラウザにはCtrl + '+' or '-' などで拡大縮小することができるのだが普通のブラウザはそれによって座標が変わることはない。
IEはスクロールやそういった事象を考慮に入れている。
その割に画像のサイズ等の変更はしないため、取得する方法がわからなかったが、
x = event.offsetX;
y = event.offsetY;
で取得できることがわかった。ブラウザによって仕様が違いすぎて困る・・。
できればIEは使いたくないがシェアが大きすぎる以上仕方がない・・。
2008年7月24日木曜日
ナローバンド版
経由点を複数指定できるようになったShortest Path Graphic だが、どうやらナローバンド版も出たようだ。
前にも書いたが、日本だけなら必要のないバージョンだが世界的にはまだまだブロードバンドが普及していない国も多いため必要なものである。
通常の2点指定のバージョンと同じで、出力時はグラフファイルをキャッシュから読み込むことを期待して、透過処理を用いて実現している。
ブロードバンド版では合成した画像を表示しているため、その時点でキャッシュに入ることはないが、そもそもブロードバンドなので画像の重さはそれほど気にしなくても良い。
また、2点指定と同様に、それらを組み合わせた画像のダウンロードもできるようになっている。
公開がブロードバンド版よりも数日遅れたのはそちらの対応が思ったよりうまくいかなかったからのようである。
前にも書いたが、日本だけなら必要のないバージョンだが世界的にはまだまだブロードバンドが普及していない国も多いため必要なものである。
通常の2点指定のバージョンと同じで、出力時はグラフファイルをキャッシュから読み込むことを期待して、透過処理を用いて実現している。
ブロードバンド版では合成した画像を表示しているため、その時点でキャッシュに入ることはないが、そもそもブロードバンドなので画像の重さはそれほど気にしなくても良い。
また、2点指定と同様に、それらを組み合わせた画像のダウンロードもできるようになっている。
公開がブロードバンド版よりも数日遅れたのはそちらの対応が思ったよりうまくいかなかったからのようである。
2008年7月23日水曜日
Line Width
Shortest Path Graphic では経路が表示される線の太さを2としてデフォルトにしている。
開発者やユーザーの間では細いし3か4にした方がいいのではないか?との意見も出ている。
ただ、Resolutionを1600にするとちょうどよく表示され、画像として保存した場合に2の方が綺麗になるという理由もある。
また、USAでは2でも太いくらいでマップに依存することかラも2が適切と判断している。
ログを見てみてもユーザーはデフォルトで実行することが多いので難しいところだ。
グラフやResolutionによって自動判断するというのも手かもしれない。
開発者やユーザーの間では細いし3か4にした方がいいのではないか?との意見も出ている。
ただ、Resolutionを1600にするとちょうどよく表示され、画像として保存した場合に2の方が綺麗になるという理由もある。
また、USAでは2でも太いくらいでマップに依存することかラも2が適切と判断している。
ログを見てみてもユーザーはデフォルトで実行することが多いので難しいところだ。
グラフやResolutionによって自動判断するというのも手かもしれない。
2008年7月22日火曜日
経由点バージョン
Shortest Path Graphicの経由点バージョンが数日前正式に公開されたようだ。
公開直後はバグがあったようだが、今はすでに修正されてるようで大きなバグは見つかっていない。
USAのグラフで中継点を多く指定するとやはり実行時間が増えてしまう。
それでも初期バージョンのように2点で1分かかっていた頃よりは高速化されているので10点以内なら1分かかることはないであろう。
どうやらこのバージョンでは同じグラフファイルで2人が同時に使用すると2人目は実行できなくなっているようだ。
公開直後はバグがあったようだが、今はすでに修正されてるようで大きなバグは見つかっていない。
USAのグラフで中継点を多く指定するとやはり実行時間が増えてしまう。
それでも初期バージョンのように2点で1分かかっていた頃よりは高速化されているので10点以内なら1分かかることはないであろう。
どうやらこのバージョンでは同じグラフファイルで2人が同時に使用すると2人目は実行できなくなっているようだ。
2008年7月21日月曜日
Resolution変更
Resolutionを変更すると座標の方も変わるのが普通のShortest Path Graphicの仕様だ。
しかし、Viaバージョンでは複数の座標を渡しているため、その計算が非常に大変になっている。
ページを読み込んだときにすべての座標をJavaScriptの変数に格納してしまい、Resolutionが変更されたらすべての座標を計算する方法で実装した。
2点指定のバージョンでもそうだが、その時点の座標との相対値を使用しているため1回1回計算しているので最初の座標と少しずれてしまっていたりするのが難点・・。
元の座標から計算するようにそのうち変更する予定。
しかし、Viaバージョンでは複数の座標を渡しているため、その計算が非常に大変になっている。
ページを読み込んだときにすべての座標をJavaScriptの変数に格納してしまい、Resolutionが変更されたらすべての座標を計算する方法で実装した。
2点指定のバージョンでもそうだが、その時点の座標との相対値を使用しているため1回1回計算しているので最初の座標と少しずれてしまっていたりするのが難点・・。
元の座標から計算するようにそのうち変更する予定。
2008年7月20日日曜日
2008年7月19日土曜日
2008年7月18日金曜日
中継点
中継点を複数指定できるShortest Path Graphicの準備はほとんど終わっている。
現在、バグ探しや、最終調整を行っているらしいので近いうちに公開されるだろう。
負整数の入力で無限ループに陥るなどのバグ報告があった。
入力をはじいてた部分を通らないように変更してしまったためであったがもう少し厳しくチェックをいれる必要がある。
また、結果表示ページに入力したルートを表示するかどうかは途中の仕様が変わっているので未だ不確定な状況だが、機能を落としたくないということでなるべく削らないで行く方向のようではある。
現在、バグ探しや、最終調整を行っているらしいので近いうちに公開されるだろう。
負整数の入力で無限ループに陥るなどのバグ報告があった。
入力をはじいてた部分を通らないように変更してしまったためであったがもう少し厳しくチェックをいれる必要がある。
また、結果表示ページに入力したルートを表示するかどうかは途中の仕様が変わっているので未だ不確定な状況だが、機能を落としたくないということでなるべく削らないで行く方向のようではある。
2008年7月17日木曜日
ソース改変による仕様変更
Shortest Path Graphic のクエリ変更に従い、今まで機能していた仕様を削除しているものもある。
Resolutionが変更されると座標も同時に変更する仕様になっていたが、1個以上座標が指定されているときは変更できなくなった。
元から同じサイズで扱えと言いたいところもあるので、大きな影響はないであろうがちょっと寂しい。
Resolutionが変更されると座標も同時に変更する仕様になっていたが、1個以上座標が指定されているときは変更できなくなった。
元から同じサイズで扱えと言いたいところもあるので、大きな影響はないであろうがちょっと寂しい。
2008年7月16日水曜日
ソース改編3
引き続きShortest Path Graphicのソースの改編を行っている。
先日のClearボタンの話であるが、Setされた時点では入力されたデータは変数としては格納されていない。実際に扱うのは変更不可のテキストに入力されたデータから扱っている。
座標の指定が
(x1,y1) -> (x2,y2) -> (x3,y3)・・・
となっているため、->を基準にClearボタンなどを動作させている。
->が1つもなければ座標は1つ以下であるから全部クリアしてしまうことと同じ。
逆に2つ以上->があるときは一番最後の->まで消してしまえばよい。
->は複数存在するため後方検索しなければならないので、JavaScriptの
str.lastIndexOf()を用いている。
先日のClearボタンの話であるが、Setされた時点では入力されたデータは変数としては格納されていない。実際に扱うのは変更不可のテキストに入力されたデータから扱っている。
座標の指定が
(x1,y1) -> (x2,y2) -> (x3,y3)・・・
となっているため、->を基準にClearボタンなどを動作させている。
->が1つもなければ座標は1つ以下であるから全部クリアしてしまうことと同じ。
逆に2つ以上->があるときは一番最後の->まで消してしまえばよい。
->は複数存在するため後方検索しなければならないので、JavaScriptの
str.lastIndexOf()を用いている。
2008年7月15日火曜日
ソース改編2
Shortest Path Graphicのソースの改編を行っている。
今まで通りクリックで座標を指定するが、その時点では確定せずSetボタン(仮)を押すことで確定。
次の点を指定して同様にSetボタン(仮)を押すことで確定。
これを繰り返し最後に、Submitを押す仕様。
ひとつ前の決定をクリアしたい場合にはClearボタンを、全部クリアしたい場合はAll Clearを押せばよい。
今まで通りクリックで座標を指定するが、その時点では確定せずSetボタン(仮)を押すことで確定。
次の点を指定して同様にSetボタン(仮)を押すことで確定。
これを繰り返し最後に、Submitを押す仕様。
ひとつ前の決定をクリアしたい場合にはClearボタンを、全部クリアしたい場合はAll Clearを押せばよい。
2008年7月14日月曜日
ソース改編
最近更新されてないように見えるShortest Path Graphicだが、いま大きなソース改編を行っている。
先日書いたとおり、経由点を指定できるような仕様に変更している。
1点だけ経由するバージョンを仮に動かしていたが、新仕様では複数点に対応している。
そのためのグラフィック的な仕様から内部の仕様まで大きく変える必要があるため、少々時間がかかってしまっている。
先日書いたとおり、経由点を指定できるような仕様に変更している。
1点だけ経由するバージョンを仮に動かしていたが、新仕様では複数点に対応している。
そのためのグラフィック的な仕様から内部の仕様まで大きく変える必要があるため、少々時間がかかってしまっている。
2008年7月13日日曜日
2008年7月12日土曜日
高速道路
経過点にも対応するShortest Path Graphicだが、実際に使ってみると結構離れている道でも同じルートを途中まで通ることが多いのが視覚的にわかる。
今までそのように言われていたのは知っていたが、実際にやってみると改めて思い直すものだ。
今までそのように言われていたのは知っていたが、実際にやってみると改めて思い直すものだ。
2008年7月11日金曜日
2008年7月10日木曜日
ログ2
Shortest Path Graphicではログをつけ始めている。
使用しているブラウザも残した方がいいんじゃないかということで、そういった情報も残すようにした。
PHPでは、
http_user_agent= getenv( "HTTP_USER_AGENT" );
で環境変数を取得できるので、これをそのまま出力している。
別にブラウザだけである必要はなく、情報は細かい方がよいので何も処理せずそのまま残している。
Mozilla/5.0 (Windows; U; Windows NT 5.1; ja; rv:1.9) Gecko/2008052906 Firefox/3.0
こういった形で出力されている。意外にこれだけで細かいことまで調べられることがわかる。
convert時に何かあったか、プログラムの連携などといったログも残したいと思っているのでそちらも随時対応していきたい。
その場合は今のログの残し方の形式を少々複雑にしなければならないが・・。
使用しているブラウザも残した方がいいんじゃないかということで、そういった情報も残すようにした。
PHPでは、
http_user_agent= getenv( "HTTP_USER_AGENT" );
で環境変数を取得できるので、これをそのまま出力している。
別にブラウザだけである必要はなく、情報は細かい方がよいので何も処理せずそのまま残している。
Mozilla/5.0 (Windows; U; Windows NT 5.1; ja; rv:1.9) Gecko/2008052906 Firefox/3.0
Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.1.4322)Mozilla/5.0 (X11; U; Linux i686; ja; rv:1.8.1.15) Gecko/20080703 Vine/2.0.0.15-1vl4 Firefox/2.0.0.15
こういった形で出力されている。意外にこれだけで細かいことまで調べられることがわかる。
convert時に何かあったか、プログラムの連携などといったログも残したいと思っているのでそちらも随時対応していきたい。
その場合は今のログの残し方の形式を少々複雑にしなければならないが・・。
2008年7月9日水曜日
ブラウザの「戻る」ボタン
ブラウザの「戻る」ボタンで戻るとキャッシュからデータを読み込み、こちらが意図しているような動作をしてくれないことが多々ある。
Shortest Path Graphicでも、Resolutionの値と画像のサイズで異なってしまう現象が発生してしまう。
解決策として、キャッシュを保存させないなどを考えたが、ただでさえサイズが軽くない画像を扱う以上、なるべくならキャッシュから読み込んで欲しいので新しいウィンドウで開くという方法を採用した。
悪くはないが何かしっくりこない・・。
Shortest Path Graphicでも、Resolutionの値と画像のサイズで異なってしまう現象が発生してしまう。
解決策として、キャッシュを保存させないなどを考えたが、ただでさえサイズが軽くない画像を扱う以上、なるべくならキャッシュから読み込んで欲しいので新しいウィンドウで開くという方法を採用した。
悪くはないが何かしっくりこない・・。
2008年7月8日火曜日
ページ遷移
Shortest Path Graphicでは、入力ページ、計算ページ、出力ページに分かれている。
入力ページ→計算ページは Submitボタンで遷移。
計算ページ→出力ページはheader("location")を使っている。
そもそも入力エラーが合ったときにheader("location")で最初のページに戻れば良かったのだがすっかり忘れていたのでその処理をした。
ちなみにheader("location")はそのページの最後まで処理をするので途中で終わらせるときは
exit;
をつけてやらなければならない。
入力ページ→計算ページは Submitボタンで遷移。
計算ページ→出力ページはheader("location")を使っている。
そもそも入力エラーが合ったときにheader("location")で最初のページに戻れば良かったのだがすっかり忘れていたのでその処理をした。
ちなみにheader("location")はそのページの最後まで処理をするので途中で終わらせるときは
exit;
をつけてやらなければならない。
2008年7月7日月曜日
ログ
ご指摘をいただいたようにこそこそとShortest Path Graphicのログをつけ始めている。
とはいえ、まだまだ簡易版でプログラム側との連携をしていくよう改良していく予定。
今ログからできることは同じ状況の再現のみで実行状況を逐次チェックまではしていない。
色々ファイル状況などと複雑に絡むのでいったんここまでを動かしておいてそこから変更していく方針。
当たり前だが、ユーザー側からは何も変わってないように見えるはずである。
とはいえ、まだまだ簡易版でプログラム側との連携をしていくよう改良していく予定。
今ログからできることは同じ状況の再現のみで実行状況を逐次チェックまではしていない。
色々ファイル状況などと複雑に絡むのでいったんここまでを動かしておいてそこから変更していく方針。
当たり前だが、ユーザー側からは何も変わってないように見えるはずである。
2008年7月6日日曜日
Shortest Path Graphic
気がつけば3000行を超えていて意外に早いものだと思わされた。
実際はIE用を別に作ったり、ブロードバンド版、ナローバンド版で分けていたりするのでそこまで書いているわけではないが。
ソースも汚くなり始めているので落ち着いたら少しずつ整理していきたい。
実際はIE用を別に作ったり、ブロードバンド版、ナローバンド版で分けていたりするのでそこまで書いているわけではないが。
ソースも汚くなり始めているので落ち着いたら少しずつ整理していきたい。
2008年7月5日土曜日
今後の方針
Shortest Path Graphicの基本的にやりたかった部分の実装は終わっている。
今後は他の人の意見を取り入れての変更が中心になるだろう。
緯度経度に対応して、GoogleMapsとの連携などそういったこともしていきたい。
こちらは共同研究者の方との連携が必須となる。
今後は他の人の意見を取り入れての変更が中心になるだろう。
緯度経度に対応して、GoogleMapsとの連携などそういったこともしていきたい。
こちらは共同研究者の方との連携が必須となる。
2008年7月4日金曜日
謎のバグ
宣伝が多いんじゃないかとつっこまれたくなるようなShortest Path Graphic。
点を2つ入力して結果を返すんだが、どのような条件かわからないが、最短パスが表示されないことがある。同じ点でもやり直すと結果が出るため原因がわからない・・。
パスが出ないと言うことは、arcファイルとpathファイルを合成するときにpathファイルがないということしかはっきりしていない。
今動いてるのが偶然なのかどうか引き続き検証中・・。そのような現象が起こってしまうときの状況を随時募集中・・。
点を2つ入力して結果を返すんだが、どのような条件かわからないが、最短パスが表示されないことがある。同じ点でもやり直すと結果が出るため原因がわからない・・。
パスが出ないと言うことは、arcファイルとpathファイルを合成するときにpathファイルがないということしかはっきりしていない。
今動いてるのが偶然なのかどうか引き続き検証中・・。そのような現象が起こってしまうときの状況を随時募集中・・。
2008年7月3日木曜日
フルブラウザ
最近の携帯電話にはフルブラウザ機能がついているものも多い。
Shortest Path Graphicのナローバンド版が出たということで今までのバージョンでは画像ファイルの容量の関係で辛かった携帯電話(DoCoMo SH906i)のフルブラウザで動作させてみた。
一番サイズが大きいと言われているNYでも表示させることができるが、PNGファイルの透過に対応していないらしく、パスが現れなかった。
しかたがないので、Downloadボタンとやらを押してみて合成させたPNGファイルを表示させたところ無事パスも表示され、携帯電話でもとりあえず無事動作した。
残念なのはクリックに対応していないため、座標が手入力な所だ。
Shortest Path Graphicのナローバンド版が出たということで今までのバージョンでは画像ファイルの容量の関係で辛かった携帯電話(DoCoMo SH906i)のフルブラウザで動作させてみた。
一番サイズが大きいと言われているNYでも表示させることができるが、PNGファイルの透過に対応していないらしく、パスが現れなかった。
しかたがないので、Downloadボタンとやらを押してみて合成させたPNGファイルを表示させたところ無事パスも表示され、携帯電話でもとりあえず無事動作した。
残念なのはクリックに対応していないため、座標が手入力な所だ。
2008年7月2日水曜日
ナローバンド版
こっそりとShortest Path Graphicのナローバンド版を公開している。
これによって海外でまだまだブロードバンドが普及していないところでも使いやすくなったはず。
幸か不幸か自分でその環境を試しにくいというのがあるが・・・。
今までとの違いは以下のような形となっている。
・地図データの画像ファイルのサイズの基本を1600から800に変更し、それに伴い実行画面のResolutionのMax値を800に。
・結果画面では元の画像ファイルをキャッシュから読み込んでくれることを期待してパスを作ったファイルとの透過にし、読み込む容量が減ることを期待。
・上のままでは画像の保存ができないので別にDownloadボタンを使うことによりそこで2つのPNGファイルを結合して表示させている。
これによって海外でまだまだブロードバンドが普及していないところでも使いやすくなったはず。
幸か不幸か自分でその環境を試しにくいというのがあるが・・・。
今までとの違いは以下のような形となっている。
・地図データの画像ファイルのサイズの基本を1600から800に変更し、それに伴い実行画面のResolutionのMax値を800に。
・結果画面では元の画像ファイルをキャッシュから読み込んでくれることを期待してパスを作ったファイルとの透過にし、読み込む容量が減ることを期待。
・上のままでは画像の保存ができないので別にDownloadボタンを使うことによりそこで2つのPNGファイルを結合して表示させている。
2008年7月1日火曜日
IEにおける座標の取得
Shortest Path Graphicにおいて、jQueryにおいてIEのみ座標指定がおかしくなる話は先日書いたとおり。
調べてみたところIEではスクロールの部分を余計に足してしまったりするらしいのでそれを引いてやらなければならない
if(window.createPopup){
var x = e.pageX - $('#image').position().left - document.body.scrollLeft;
var y = e.pageY - $('#image').position().top - document.body.scrollTop;
}else{
var x = e.pageX - $('#image').position().left;
var y = e.pageY - $('#image').position().top;
}
document.body.scrollLeft(Top)の部分があるのとないのでIEへの対応をしている。
実際にはif文が乱立してしまうのでIEのみ別のページに飛ばして対応している。
参考:http://www.openspc2.org/JavaScript/Ajax/Ajax_study/chapter05/013/index.html
調べてみたところIEではスクロールの部分を余計に足してしまったりするらしいのでそれを引いてやらなければならない
if(window.createPopup){
var x = e.pageX - $('#image').position().left - document.body.scrollLeft;
var y = e.pageY - $('#image').position().top - document.body.scrollTop;
}else{
var x = e.pageX - $('#image').position().left;
var y = e.pageY - $('#image').position().top;
}
document.body.scrollLeft(Top)の部分があるのとないのでIEへの対応をしている。
実際にはif文が乱立してしまうのでIEのみ別のページに飛ばして対応している。
参考:http://www.openspc2.org/JavaScript/Ajax/Ajax_study/chapter05/013/index.html
2008年6月30日月曜日
2008年6月29日日曜日
問題
公開から大きなトラブルもなく微妙にバージョンをあげてきたと思われていたShortest Path Graphicだが、ここにきて、大きな問題が見つかってしまった。
IEでの座標の取得に支障が出ていたのに全く気づかなかった。
小さい地図では問題ないんだが大きな地図や画面を小さくしたときに影響が出る。
なんとかしなければならないが対策が思いつかない・・・。
IEでの座標の取得に支障が出ていたのに全く気づかなかった。
小さい地図では問題ないんだが大きな地図や画面を小さくしたときに影響が出る。
なんとかしなければならないが対策が思いつかない・・・。
2008年6月28日土曜日
ナローバンド
日本ではブロードバンドが普及しナローバンドはあまり見なくなった。
しかし、海外ではまだまだそういった環境も多いためShortest Path Graphicでは海外ユーザーのためにそのような環境も作成する予定。
現バージョンとの違いは以下のようにしようと考えている。
・1600の解像度の画像を800に変更。
・結果ページにおいて、現在はpngファイルの合成をしてから表示しているが、少し前に書いた透過の技術を用いて実装。
解像度を落とすのは根本的対策で、結果ページの方法はキャッシュから画像を読み込んでもらうことにより、表示を早くしようという考え。
また、時間がかかってもいい人用に解像度3200といったものを用意してもいいかもしれない。
しかし、海外ではまだまだそういった環境も多いためShortest Path Graphicでは海外ユーザーのためにそのような環境も作成する予定。
現バージョンとの違いは以下のようにしようと考えている。
・1600の解像度の画像を800に変更。
・結果ページにおいて、現在はpngファイルの合成をしてから表示しているが、少し前に書いた透過の技術を用いて実装。
解像度を落とすのは根本的対策で、結果ページの方法はキャッシュから画像を読み込んでもらうことにより、表示を早くしようという考え。
また、時間がかかってもいい人用に解像度3200といったものを用意してもいいかもしれない。
2008年6月27日金曜日
VMware-toolbox
VMware-toolboxがインストールされていると、ホストOSとのコピペができたりマウスの透過ができたり非常に処理がしやすくなる。
インストール方法は1年前くらいに書いているので省略するが、自動実行するには
Vine4.xにおいてはtoolboxを起動したいユーザーで
デスクトップ→設定→高度な設定→セッション
で自動起動するプログラムのところに
/usr/bin/vmware-toolbox
とすればよい。自分の場合別のワークスペースに移してしまうのでこのままだが、最小化したければ
/usr/bin/vmware-toolbox --minimize
としておけばよい。
インストール方法は1年前くらいに書いているので省略するが、自動実行するには
Vine4.xにおいてはtoolboxを起動したいユーザーで
デスクトップ→設定→高度な設定→セッション
で自動起動するプログラムのところに
/usr/bin/vmware-toolbox
とすればよい。自分の場合別のワークスペースに移してしまうのでこのままだが、最小化したければ
/usr/bin/vmware-toolbox --minimize
としておけばよい。
2008年6月26日木曜日
2008年6月25日水曜日
ブラウザ
先日ブラウザによって挙動が違うという話をした。
そのときはSafariが厳密に読んでくれたのがいいのか悪いのかはわからないがSafariのみ対応していないという状況であった。
今回はIEが読んでくれない現象が生じてIEだけ対応できないという状況になってしまった。
これに関してはnameを指定していなかったからなのだが、残り2つのブラウザはこれらを考慮して読んでくれていた。一つしかないのならこれを読んでほしいものだが、まぁ仕方がない。
Ajaxが流行ってきているが一番の問題はこういったブラウザ間で挙動が違うクロスブラウザ問題を考慮しなければならない。
とはいえ、ブラウザを何個もインストールしているのはちょっと悲しくなる。
そのときはSafariが厳密に読んでくれたのがいいのか悪いのかはわからないがSafariのみ対応していないという状況であった。
今回はIEが読んでくれない現象が生じてIEだけ対応できないという状況になってしまった。
これに関してはnameを指定していなかったからなのだが、残り2つのブラウザはこれらを考慮して読んでくれていた。一つしかないのならこれを読んでほしいものだが、まぁ仕方がない。
Ajaxが流行ってきているが一番の問題はこういったブラウザ間で挙動が違うクロスブラウザ問題を考慮しなければならない。
とはいえ、ブラウザを何個もインストールしているのはちょっと悲しくなる。
2008年6月24日火曜日
Windows Update
自分のブログによくWindows Updateができないというトラブルで流れてくる人がいる。
エラーのログが「%windir%/WindowsUpdate.log」(ファイル名を指定して実行で打ち込めばよい)というところにあるので、そのエラーナンバーを確認する。後はそれを適当に検索をかければよいでしょう
0x80004002に関しては昔自分も書いている。
%Windir%\system32\net.exe stop bits
%Windir%\system32\net.exe stop wuauserv
%Windir%\system32\regsvr32.exe atl.dll
%Windir%\system32\regsvr32.exe jscript.dll
%Windir%\system32\regsvr32.exe msxml3.dll
%Windir%\system32\regsvr32.exe softpub.dll
%Windir%\system32\regsvr32.exe wuapi.dll
%Windir%\system32\regsvr32.exe wuaueng.dll
%Windir%\system32\regsvr32.exe wuaueng1.dll
%Windir%\system32\regsvr32.exe wucltui.dll
%Windir%\system32\regsvr32.exe wups.dll
%Windir%\system32\regsvr32.exe wups2.dll
%Windir%\system32\regsvr32.exe wuweb.dll
%Windir%\system32\net.exe start bits
%Windir%\system32\net.exe start wuauserv
これをコピーして
ファイル名を指定して実行→cmd→でDosの窓が出てきたら貼り付ければ全部順番に実行してくれる。
昔書いたブログが役に立ってしまったというのはここだけの話だ・・。
そしてこのOSは自分のアップデートもうまくできないのですね。
参考:http://d.hatena.ne.jp/Gazebo/20070802/p1
エラーのログが「%windir%/WindowsUpdate.log」(ファイル名を指定して実行で打ち込めばよい)というところにあるので、そのエラーナンバーを確認する。後はそれを適当に検索をかければよいでしょう
0x80004002に関しては昔自分も書いている。
%Windir%\system32\net.exe stop bits
%Windir%\system32\net.exe stop wuauserv
%Windir%\system32\regsvr32.exe atl.dll
%Windir%\system32\regsvr32.exe jscript.dll
%Windir%\system32\regsvr32.exe msxml3.dll
%Windir%\system32\regsvr32.exe softpub.dll
%Windir%\system32\regsvr32.exe wuapi.dll
%Windir%\system32\regsvr32.exe wuaueng.dll
%Windir%\system32\regsvr32.exe wuaueng1.dll
%Windir%\system32\regsvr32.exe wucltui.dll
%Windir%\system32\regsvr32.exe wups.dll
%Windir%\system32\regsvr32.exe wups2.dll
%Windir%\system32\regsvr32.exe wuweb.dll
%Windir%\system32\net.exe start bits
%Windir%\system32\net.exe start wuauserv
これをコピーして
ファイル名を指定して実行→cmd→でDosの窓が出てきたら貼り付ければ全部順番に実行してくれる。
昔書いたブログが役に立ってしまったというのはここだけの話だ・・。
そしてこのOSは自分のアップデートもうまくできないのですね。
参考:http://d.hatena.ne.jp/Gazebo/20070802/p1
2008年6月23日月曜日
意見
様々なユーザーから意見をいただいているShortest Path Graphic。
海外ではナローバンドの回線も少なくないので、そういったバージョンも作った方が良さそうだ。
また、逆に高解像度版を用意してUSAでの楽しさも体感してもらうのもおもしろいかもしれない。
ただ、自分が負けず嫌いなのもあるが「ナローバンドの方はこちら」と書かれていても動作に影響がなく遅いだけならブロードバンド版の方を選んでしまう気もする。
海外ではナローバンドの回線も少なくないので、そういったバージョンも作った方が良さそうだ。
また、逆に高解像度版を用意してUSAでの楽しさも体感してもらうのもおもしろいかもしれない。
ただ、自分が負けず嫌いなのもあるが「ナローバンドの方はこちら」と書かれていても動作に影響がなく遅いだけならブロードバンド版の方を選んでしまう気もする。
2008年6月22日日曜日
高速化
今までUSAのグラフになると1分前後かかっていたShortest Path Graphicだが、10秒以内に解けるようになっている。
元々計算時間より、グラフデータの読み込みの時間が多かったため、それを削減した形。
現在はファイルを使い回しているため、表示のページを更新すると後から使用したユーザーの結果が表示されてしまうことがある。
今後の方針としては、クエリ番号をつけてユーザー数に応じて出力ファイルを残しておく予定。
元々計算時間より、グラフデータの読み込みの時間が多かったため、それを削減した形。
現在はファイルを使い回しているため、表示のページを更新すると後から使用したユーザーの結果が表示されてしまうことがある。
今後の方針としては、クエリ番号をつけてユーザー数に応じて出力ファイルを残しておく予定。
2008年6月21日土曜日
ユーザー視点
知り合いの大学1年生(理系)にShortest Parth Graphicを使わせてみた。
使い方以外の前情報を与えずにやらせてみたところ、USAを最初に実験していた。
やはり一般的に大きい地図の方が興味があるのだろう。
「山道などの速度は考えているんですか?」
と質問されたが、これは最短路なので距離が最小のものを出している。
とはいえ、グラフファイルには高速道路等を加味したものもあるとのことなのでいずれそちらにも対応するだろう。
余談だが、ブックマークしてくれたそうだ。
使い方以外の前情報を与えずにやらせてみたところ、USAを最初に実験していた。
やはり一般的に大きい地図の方が興味があるのだろう。
「山道などの速度は考えているんですか?」
と質問されたが、これは最短路なので距離が最小のものを出している。
とはいえ、グラフファイルには高速道路等を加味したものもあるとのことなのでいずれそちらにも対応するだろう。
余談だが、ブックマークしてくれたそうだ。
2008年6月20日金曜日
Shortest Path Graphicのバグ
公開時点でSafariで表示できないことをすっかり忘れていた。
携帯電話のフルブラウザでもやってみたが、できなくなっていたのに気づき(当初はできた)ソースを見直してみるとHTMLのタグのミスであることが発覚。
修正したところSafariでも携帯でも表示できることを確認。
間違ったタグを無視してなかったことにして読み込むブラウザがいいのかそれを厳密に解釈するブラウザがいいのかは別としてHTMLはエラーメッセージとかがでないので開発は非常にやりにくい。
携帯電話のフルブラウザでもやってみたが、できなくなっていたのに気づき(当初はできた)ソースを見直してみるとHTMLのタグのミスであることが発覚。
修正したところSafariでも携帯でも表示できることを確認。
間違ったタグを無視してなかったことにして読み込むブラウザがいいのかそれを厳密に解釈するブラウザがいいのかは別としてHTMLはエラーメッセージとかがでないので開発は非常にやりにくい。
2008年6月19日木曜日
Shortest Path Graphic
準備を進めていた最短路問題におけるオンラインソルバーが公開できる程度になった。
http://opt.indsys.chuo-u.ac.jp/portal/
で試すことができる。
まだまだ試作段階のため改良点は多い。同一の地図で複数ユーザーがアクセスすると2人目以降のアクセスはブロックしてしまうので実行に時間がかかるUSAの実行ではビジーになりやすいので注意していただきたい。
また、FireFox3ではWebページの座標で10程度のずれが生じてしまう。(v2では問題なし)
Shortest Path Graphic使用方法
画像の好きな点2つをクリックし、座標が2つ入力されていることを確認する。
Submitをクリックして計算するのを待てば最短路が書かれた画像が表示される。
この画像は右クリックの画像を保存などでローカルに保存することもできる。
http://opt.indsys.chuo-u.ac.jp/portal/
で試すことができる。
まだまだ試作段階のため改良点は多い。同一の地図で複数ユーザーがアクセスすると2人目以降のアクセスはブロックしてしまうので実行に時間がかかるUSAの実行ではビジーになりやすいので注意していただきたい。
また、FireFox3ではWebページの座標で10程度のずれが生じてしまう。(v2では問題なし)
Shortest Path Graphic使用方法
画像の好きな点2つをクリックし、座標が2つ入力されていることを確認する。
Submitをクリックして計算するのを待てば最短路が書かれた画像が表示される。
この画像は右クリックの画像を保存などでローカルに保存することもできる。
2008年6月18日水曜日
2008年6月16日月曜日
ShortestPath Online
をこっそりと昨日から仮サーバーで動かしている。
サーバーも実際に稼働予定のマシンにうつしてみて実行・・!
と思ったがどうも変数の受け渡しがうまくいかない。
結局php.iniの設定の問題であったがマシンが違うとそういうところも気を付けなければならない。
サーバーも実際に稼働予定のマシンにうつしてみて実行・・!
と思ったがどうも変数の受け渡しがうまくいかない。
結局php.iniの設定の問題であったがマシンが違うとそういうところも気を付けなければならない。
2008年6月14日土曜日
2008年6月13日金曜日
gfarm v2
v1のときに問題のなかった
config-agent
がエラーで止まってしまう。
/usr/local/bin/config-agent: line 232: mkcnf_agent_sysdep: command not found
/usr/local/etc/gfarm.conf: updated
created /etc/init.d/gfarm_agent
added gfarm_agent service
Starting gfarm_agent:/usr/local/bin/gfarm_agent: symbol lookup error: /usr/local/bin/gfarm_agent: undefined symbol: GFARM_ERR_NO_SUCH_OBJECT [failed]
config-agent: cannot start gfarm_agent
config-agent failure
ちょっと調べてみるとfuseかglibc-not-hiddenを入れなければならないらしいが・・。
逆にv1のときはなぜ動いていたか疑問になる。
config-agentが実行できないため
gfrun,gfgrep等のコマンドも
gfrun: symbol lookup error: gfrun: undefined symbol: gfarm_spool_server_port
gfgrep: symbol lookup error: gfgrep: undefined symbol: gfs_pio_get_node_rank
等が使用できない。どうしたものか・・。
fuseもCentOS5版があればいいのだが。
config-agent
がエラーで止まってしまう。
/usr/local/bin/config-agent: line 232: mkcnf_agent_sysdep: command not found
/usr/local/etc/gfarm.conf: updated
created /etc/init.d/gfarm_agent
added gfarm_agent service
Starting gfarm_agent:/usr/local/bin/gfarm_agent: symbol lookup error: /usr/local/bin/gfarm_agent: undefined symbol: GFARM_ERR_NO_SUCH_OBJECT [failed]
config-agent: cannot start gfarm_agent
config-agent failure
ちょっと調べてみるとfuseかglibc-not-hiddenを入れなければならないらしいが・・。
逆にv1のときはなぜ動いていたか疑問になる。
config-agentが実行できないため
gfrun,gfgrep等のコマンドも
gfrun: symbol lookup error: gfrun: undefined symbol: gfarm_spool_server_port
gfgrep: symbol lookup error: gfgrep: undefined symbol: gfs_pio_get_node_rank
等が使用できない。どうしたものか・・。
fuseもCentOS5版があればいいのだが。
2008年6月12日木曜日
GFarm2のインストール
GFarm2のインストールに戸惑っていたがとりあえず解決した。
v1に比べて若干変更があったようで、
http://filesystem.g.hatena.ne.jp/n314/
を参考にさせていただいた。
gfarm2.1.0というフォルダがあるとする。
cd gfarm2.1.0
./configure
make
sudo make install
ここまではv1と変更がない。
config-gfarm -t(root)
で問題なければ
config-gfarm(root)
を実行。
この時PostgreSQL等が起動していたらエラーが出るので
ps -ef | grep postgre
などでプロセスを確認してkillすればよい。
v1はこのままconfig-gfsdを実行していたが、
v2の場合、
gfhost -c -a x86_64-centos5-linux -n 4 -p 600 ore00.optsys.xxx.ac.jp ore00(user)
を先に実行する。
useradd -c "Gfarm gfsd" -m _gfarmfs
した上で、
config-gfsd -t
間違いなければ
config-gfsd
で完了。
gfhostについても-pでポートを指定しなければならなくなったようだ。
また、そのままで全てのユーザーで使えるわけではなく、
gfuser -c hoge hoge /hoge ""
のようにユーザーを登録しなければならなくなった。
また、config-gfarmを実行したユーザーのみはこの作業は不要である。
v1に比べて若干変更があったようで、
http://filesystem.g.hatena.ne.jp/n314/
を参考にさせていただいた。
gfarm2.1.0というフォルダがあるとする。
cd gfarm2.1.0
./configure
make
sudo make install
ここまではv1と変更がない。
config-gfarm -t(root)
で問題なければ
config-gfarm(root)
を実行。
この時PostgreSQL等が起動していたらエラーが出るので
ps -ef | grep postgre
などでプロセスを確認してkillすればよい。
v1はこのままconfig-gfsdを実行していたが、
v2の場合、
gfhost -c -a x86_64-centos5-linux -n 4 -p 600 ore00.optsys.xxx.ac.jp ore00(user)
を先に実行する。
useradd -c "Gfarm gfsd" -m _gfarmfs
した上で、
config-gfsd -t
間違いなければ
config-gfsd
で完了。
gfhostについても-pでポートを指定しなければならなくなったようだ。
また、そのままで全てのユーザーで使えるわけではなく、
gfuser -c hoge hoge /hoge ""
のようにユーザーを登録しなければならなくなった。
また、config-gfarmを実行したユーザーのみはこの作業は不要である。
2008年6月11日水曜日
htmlで画像を重ねて表示
ご存じの人も多いかと思うが、PNGやGIFといったファイルは「透過色」なるものが用意されており、後ろが透過して見えるような色(?)を使うことができる。
故に画像を重ねれば見た目合成したようにすることができるのだが、単純にhtml上にImgで並べるだけでは合成されない。
<img border=0 src="gazou.png" width=400 height=400 style="position: absolute; top:0; left:0;">
<img border=0 src="sitagasukeru.png" width=400 height=400 style="position: absolute; top:0; left:0;">
<>をhtmlタグとして認識されてしまうらしく、全角で表示しているのでコピペする方は注意していただきたい。
のように強制的に位置を決めてやってしまえば良い。
上の例だと上から0,左から0の位置に400x400で表示するという設定。
スタイルシートに書いたけどうまくいかなかったので直接貼り付けたのはここだけの話。
故に画像を重ねれば見た目合成したようにすることができるのだが、単純にhtml上にImgで並べるだけでは合成されない。
<img border=0 src="gazou.png" width=400 height=400 style="position: absolute; top:0; left:0;">
<img border=0 src="sitagasukeru.png" width=400 height=400 style="position: absolute; top:0; left:0;">
<>をhtmlタグとして認識されてしまうらしく、全角で表示しているのでコピペする方は注意していただきたい。
のように強制的に位置を決めてやってしまえば良い。
上の例だと上から0,左から0の位置に400x400で表示するという設定。
スタイルシートに書いたけどうまくいかなかったので直接貼り付けたのはここだけの話。
2008年6月9日月曜日
2008年6月6日金曜日
座標を渡す
先日の座標を取得するプログラムの件だが、一応の解決はした。
元々最短路問題において出発点と到着点を取得するのが目的であったのだが、1点のみの座標取得は容易にできるのに対し、その情報を保持しつつ2つめの点の取得にはいろいろと条件がかかってしまっていた。
JavaScriptでは静的な情報しか保存できないのが厄介。
その問題は以下のようにして解決した。
ほとんど見た目が変わらないページ1とページ2とページ3を用意する。
ページ1において座標を取得。
決定ボタンをおき、出発点の座標をページ2にわたす。
ページ2において到達点の座標を取得する。
出発点の座標はこの時点で変数に格納されているため失われることはない。
決定ボタンとクリアボタンを置き、決定ボタンを押すと二つの点の座標をページ3に渡す。
クリアボタンを押した場合はページ1に戻る。
ページ3ではそれらの座標を使って処理すればよい。
これにより問題なくプログラム側に座標を渡すことは可能になった。
グラフィック的に点をクリックするとそこが塗りつぶされるとかそういう効能があるとベストなので改良の余地は多々ある。
見た目的にもわるすぎるのでそのあたりも考慮しなければならない。
元々最短路問題において出発点と到着点を取得するのが目的であったのだが、1点のみの座標取得は容易にできるのに対し、その情報を保持しつつ2つめの点の取得にはいろいろと条件がかかってしまっていた。
JavaScriptでは静的な情報しか保存できないのが厄介。
その問題は以下のようにして解決した。
ほとんど見た目が変わらないページ1とページ2とページ3を用意する。
ページ1において座標を取得。
決定ボタンをおき、出発点の座標をページ2にわたす。
ページ2において到達点の座標を取得する。
出発点の座標はこの時点で変数に格納されているため失われることはない。
決定ボタンとクリアボタンを置き、決定ボタンを押すと二つの点の座標をページ3に渡す。
クリアボタンを押した場合はページ1に戻る。
ページ3ではそれらの座標を使って処理すればよい。
これにより問題なくプログラム側に座標を渡すことは可能になった。
グラフィック的に点をクリックするとそこが塗りつぶされるとかそういう効能があるとベストなので改良の余地は多々ある。
見た目的にもわるすぎるのでそのあたりも考慮しなければならない。
2008年6月4日水曜日
PHPとJavaScript
研究の関係でブラウザ上で画像のクリックした部分の座標を取得するプログラムを作らなければならない。
JavaScriptでの座標取得は比較的容易にできる。
しかし、その後にPHPで作業をするためにPHP側の変数として扱うためには$_GETや$_POSTを用いてページをリロードするしかない。
当たり前の話だが、PHPの変数をJavaScriptに与えるのは容易である。
JavaScriptでの座標取得は比較的容易にできる。
しかし、その後にPHPで作業をするためにPHP側の変数として扱うためには$_GETや$_POSTを用いてページをリロードするしかない。
当たり前の話だが、PHPの変数をJavaScriptに与えるのは容易である。
2008年6月3日火曜日
GFarm2.1.0
がリリースされたそうなのでインストールしてみるが、
config-gfarm
を実行するとPostgreSQLの開始時にエラーが出る。
ps -ef grep postgre
をしてみてもプロセスは消えているんだが・・。
1.4でも大きな問題は発生していないのでしばらくはこっちを使っていよう・・。
config-gfarm
を実行するとPostgreSQLの開始時にエラーが出る。
ps -ef grep postgre
をしてみてもプロセスは消えているんだが・・。
1.4でも大きな問題は発生していないのでしばらくはこっちを使っていよう・・。
2008年5月28日水曜日
あっさり進行
無事クラスタ内では解決したので別の実験用オンラインソルバーのマシンにもGFarmをインストールしてみた。
./configure
make
sudo make install
といつもの感じであっさり終了
config-gfarm -t
config-gfarm
config-agent -t
config-agent
config-gfsd -t
config-gfsd
あっさり終了。
gfhost
にて自分自身は認識しているのを確認。
/usr/local/etc/gfarm.conf
をクラスタの方のgfarm.confにコピー。
クラスタの方の.gfarm_shared_keyを実験用マシンにコピー。
gfhost
にてクラスタと、実験用マシンの両方を認識していることを確認。
あっさり行きすぎて怖いがここまでは問題なし。
とはいえ、問題がないわけではなく
オンラインソルバーから使用することになるため今のままだとapacheユーザーを使わなければならない。良い方法がないかどうか考え中。
./configure
make
sudo make install
といつもの感じであっさり終了
config-gfarm -t
config-gfarm
config-agent -t
config-agent
config-gfsd -t
config-gfsd
あっさり終了。
gfhost
にて自分自身は認識しているのを確認。
/usr/local/etc/gfarm.conf
をクラスタの方のgfarm.confにコピー。
クラスタの方の.gfarm_shared_keyを実験用マシンにコピー。
gfhost
にてクラスタと、実験用マシンの両方を認識していることを確認。
あっさり行きすぎて怖いがここまでは問題なし。
とはいえ、問題がないわけではなく
オンラインソルバーから使用することになるため今のままだとapacheユーザーを使わなければならない。良い方法がないかどうか考え中。
2008年5月26日月曜日
24時間制限
だいぶ前(3/19)にも書いたが、Gfarmにおいて
gfkey
で作成されたキーは24時間しか持たない。MAX24時間でそれ以上はもう一度作り直さなければならない。それを回避するために
gfkey -f -p 200000000
が使えるかもというのを実験してみたが予想通り(?)問題なく24時間後も動作している。
ちなみに本当にこの時間で鍵が切れるかは2315日経ってみないとわからない。
現実的にセキュリティを考えると1か月に1回くらいはリブートもするだろうしその都度鍵ファイルを作り直すのがいいだろう。
前回書いた
connection refused
のエラーについてはただgfsdのサービスを起動してないという基本的なミスでした・・。
いろいろ疑ってかかって問題解決に時間を食ってしまった・・orz
gfkey
で作成されたキーは24時間しか持たない。MAX24時間でそれ以上はもう一度作り直さなければならない。それを回避するために
gfkey -f -p 200000000
が使えるかもというのを実験してみたが予想通り(?)問題なく24時間後も動作している。
ちなみに本当にこの時間で鍵が切れるかは2315日経ってみないとわからない。
現実的にセキュリティを考えると1か月に1回くらいはリブートもするだろうしその都度鍵ファイルを作り直すのがいいだろう。
前回書いた
connection refused
のエラーについてはただgfsdのサービスを起動してないという基本的なミスでした・・。
いろいろ疑ってかかって問題解決に時間を食ってしまった・・orz
2008年5月24日土曜日
変更
オンラインソルバーのページ設定をしばらく続け、各ソルバーをプルダウンメニューで替えるようにした。
前に書いたかも知れないが各ソルバーには極論を言ってしまうと
バイナリ(+オプション)、インプットファイル、アウトプットファイルの3種類しかないため、そこの部分だけを考え全部共通仕様になっている。
実行ページ、ファイル管理ページは問題なく動作はするはずようにはなっているはず。
後はちょこちょこ変更していけばこっちはそれほど問題にならないだろう。
大きく直さなければならないのはログの管理くらいか・・。
それにしてもPHPはコンパイルがないし、html文も入ってたりで括弧が山のようになりエラーの場所を探すのが面倒だ。
そんなところでいったんこちらには見切りを付けてGfarmの方に戻ってきた。
接続できないという問題は解決しいざ色々と実験しようかと思ったら次の日にまた接続できなくなった。
パス認証の問題ではなくconnection refusedになる・・。
おそらくすぐに解決すると思うので
オンラインソルバーの実験用サーバーにもGfarmを入れて、実際に実行可能かを試す段階までなんとか週末でやりたい・・。
前に書いたかも知れないが各ソルバーには極論を言ってしまうと
バイナリ(+オプション)、インプットファイル、アウトプットファイルの3種類しかないため、そこの部分だけを考え全部共通仕様になっている。
実行ページ、ファイル管理ページは問題なく動作はするはずようにはなっているはず。
後はちょこちょこ変更していけばこっちはそれほど問題にならないだろう。
大きく直さなければならないのはログの管理くらいか・・。
それにしてもPHPはコンパイルがないし、html文も入ってたりで括弧が山のようになりエラーの場所を探すのが面倒だ。
そんなところでいったんこちらには見切りを付けてGfarmの方に戻ってきた。
接続できないという問題は解決しいざ色々と実験しようかと思ったら次の日にまた接続できなくなった。
パス認証の問題ではなくconnection refusedになる・・。
おそらくすぐに解決すると思うので
オンラインソルバーの実験用サーバーにもGfarmを入れて、実際に実行可能かを試す段階までなんとか週末でやりたい・・。
2008年5月1日木曜日
簡略化
Gfarmがどうもうまくいかないので最近は気晴らしもかねてPHPの方の作成をしている。
だいぶ前にも書いた通り最適化オンラインソルバーの運用に向けて、
1,ほとんどのソルバーにおいてほぼ同じような使い方ができる
2,ソルバーを追加する作業を簡略化する
の2点を中心に進めている。
各ソルバーには設定ファイルが用意されており、そこに使用する計算機、パラメータの種類等を記述する。それに従ったフォルダを初ログイン時に作成し、メインページではその設定ファイルに従ってファイルを読み出すことになる。
ソルバーを登録するときはその設定ファイルと実行ファイル(バイナリ)だけ用意すればできるのが最終目標であるが、ファイル実行時には様々な制約がかかりそこの部分だけはまだ考慮する必要がありそうだ。
今回行っていた作業は元のSDPAのメインページより、共通部分をPHP化し、設定ファイルを読み出すことができるようにした。
これによりパラメータ等が何個であってもソルバーに応じてループ文で対応できる。
ログの残し方、実行時のメールの送信をどうするかなど細かい面も詰めていってもいいかとおもう。
先生にも言われてるようにインターフェイスをどうするかが結構課題・・。
GWくらいで見切りをつけ、Gfarmの方も再開せねば。
だいぶ前にも書いた通り最適化オンラインソルバーの運用に向けて、
1,ほとんどのソルバーにおいてほぼ同じような使い方ができる
2,ソルバーを追加する作業を簡略化する
の2点を中心に進めている。
各ソルバーには設定ファイルが用意されており、そこに使用する計算機、パラメータの種類等を記述する。それに従ったフォルダを初ログイン時に作成し、メインページではその設定ファイルに従ってファイルを読み出すことになる。
ソルバーを登録するときはその設定ファイルと実行ファイル(バイナリ)だけ用意すればできるのが最終目標であるが、ファイル実行時には様々な制約がかかりそこの部分だけはまだ考慮する必要がありそうだ。
今回行っていた作業は元のSDPAのメインページより、共通部分をPHP化し、設定ファイルを読み出すことができるようにした。
これによりパラメータ等が何個であってもソルバーに応じてループ文で対応できる。
ログの残し方、実行時のメールの送信をどうするかなど細かい面も詰めていってもいいかとおもう。
先生にも言われてるようにインターフェイスをどうするかが結構課題・・。
GWくらいで見切りをつけ、Gfarmの方も再開せねば。
2008年4月11日金曜日
ホストの追加方法
Gfarmにおいてホストを追加するには下のようなコマンドを打てばよい
x86_64やCentOS5の部分は環境によってはもちろん変更する。
gfhost -c -a x86_64-centos5-linux -n 4 ore01.optsys.xxx.ac.jp ore01
面倒だが、登録数分やらないとたぶんダメである。
設定が完了すれば
gfhost -l
で細かく見ることができる。
0.06/0.02/0.00 s x86_64-centos5-linux 4 ore00.optsys.xxx.ac.jp(xx.x.x.xx)
-.--/-.--/-.-- - x86_64-centos5-linux 4 ore01.optsys.xxx.ac.jp(xx.x.x.xx) ore01
-.--/-.--/-.-- - x86_64-centos5-linux 4 ore02.optsys.xxx.ac.jp(xx.x.x.xx) ore02
-.--/-.--/-.-- - x86_64-centos5-linux 4 ore03.optsys.xxx.ac.jp(xx.x.x.xx) ore03
-.--/-.--/-.-- - x86_64-centos5-linux 4 ore04.optsys.xxx.ac.jp(xx.x.x.xx) ore04
x.xx/x.xx/x.xx - x86_64-centos5-linux 4 ore05.optsys.xxx.ac.jp ore05
最初の部分が
-.--/-.--/-.-- -
のときはポートが閉じている場合や認証が通らない場合などに起こるのでそちらの設定を見直す。
x.xx/x.xx/x.xx
のときはそもそも存在しないか間違っているかなのでもう一度ホストの設定を見直す必要がある。
上の場合はおそらくore05というのが存在してないと推測できます。台数の勘違いでしょう。
自分のように-.--/-.--/-.-- -のときにホストをいくらみても解決しないとならないように気をつけたい。
普通にマニュアルに書いてあることですけど。
x86_64やCentOS5の部分は環境によってはもちろん変更する。
gfhost -c -a x86_64-centos5-linux -n 4 ore01.optsys.xxx.ac.jp ore01
面倒だが、登録数分やらないとたぶんダメである。
設定が完了すれば
gfhost -l
で細かく見ることができる。
0.06/0.02/0.00 s x86_64-centos5-linux 4 ore00.optsys.xxx.ac.jp(xx.x.x.xx)
-.--/-.--/-.-- - x86_64-centos5-linux 4 ore01.optsys.xxx.ac.jp(xx.x.x.xx) ore01
-.--/-.--/-.-- - x86_64-centos5-linux 4 ore02.optsys.xxx.ac.jp(xx.x.x.xx) ore02
-.--/-.--/-.-- - x86_64-centos5-linux 4 ore03.optsys.xxx.ac.jp(xx.x.x.xx) ore03
-.--/-.--/-.-- - x86_64-centos5-linux 4 ore04.optsys.xxx.ac.jp(xx.x.x.xx) ore04
x.xx/x.xx/x.xx - x86_64-centos5-linux 4 ore05.optsys.xxx.ac.jp ore05
最初の部分が
-.--/-.--/-.-- -
のときはポートが閉じている場合や認証が通らない場合などに起こるのでそちらの設定を見直す。
x.xx/x.xx/x.xx
のときはそもそも存在しないか間違っているかなのでもう一度ホストの設定を見直す必要がある。
上の場合はおそらくore05というのが存在してないと推測できます。台数の勘違いでしょう。
自分のように-.--/-.--/-.-- -のときにホストをいくらみても解決しないとならないように気をつけたい。
普通にマニュアルに書いてあることですけど。
2008年4月3日木曜日
2008年4月2日水曜日
復旧作業2
新しいHDDに変えた上で復旧作業をするわけだが、設定ファイルとwww以下のデータファイルさえコピーすればおそらく問題ないであろう。
昨日の復旧中で分かったことだがPHP4→5にするとどうやら変数の扱いが微妙になるらしく、ユーザーから受け取った値を直接printすると警告が出る。
htmlspecialchars()を使えばいったん変換されるので警告が消える。特殊文字など使ってないとは思うのだが・・。
MySQLのデータベースの移行はコマンドがあるらしいが普通にvar以下にあるようなコピーして持ってくるだけでも問題なく移行はできた。あまり推奨はされてないのかもしれないが・・。
昨日の復旧中で分かったことだがPHP4→5にするとどうやら変数の扱いが微妙になるらしく、ユーザーから受け取った値を直接printすると警告が出る。
htmlspecialchars()を使えばいったん変換されるので警告が消える。特殊文字など使ってないとは思うのだが・・。
MySQLのデータベースの移行はコマンドがあるらしいが普通にvar以下にあるようなコピーして持ってくるだけでも問題なく移行はできた。あまり推奨はされてないのかもしれないが・・。
2008年3月19日水曜日
2008年2月8日金曜日
現行からの変更点(予定)
現行のままでは不便が生じるのと管理者が変わったときに大変なので以下のように変更することが自分の中ではほぼ決定。
今のmain.phpは
solver/sdpa/main.php
に移動して管理する予定。
元の場所のmain.phpは各種solverへのリンク集みたいなのと情報ページみたいになるのかな・・。
というわけでShortest Pathであれば、
solver/shortestpath/main.php
になるわけで
基本的にmain.phpというファイルは変数で書けるものは変数で書いてなるべく同じ書式にする。
基本フォーマットにはソルバーに関係なく使えるようなサンプルファイルを用意する。ソルバーの追加や変更を容易にするのとユーザーから見てフォーマットが似てる方が使いやすいという二つの意図があり。
それに伴い、共通の設定は別にcommonファイルを用意。ソルバー独自の設定が別に必要だがなるべくmain.phpのファイルをいじらないで別のphpファイルから読み出せるようにしたい。
最終的な決定は何種類か最適化プログラムの仕様が分かってからにならざるを得ないが・・。
それと前の更新で書いた一方を採用し、
userdata/username/solvername/data(param)
フォルダに入出力データを入れることに変更。
そうしないと一括管理が非常に難しくなるのと、input,output系のファイルが複数にわたるときの管理が面倒になるという理由があり。
今現在、初ログイン時に、必要なフォルダをmkdirコマンドを呼び作成しているのだが、そのままの仕様にするなら作成するフォルダの一覧を変数にして別のファイルに用意しておいた方が良いかな。
インターフェイスも変えたいがこういった仕様を先に決めておかないと後が厄介なのと自分に美的センスがないのとで結構悩みどころ・・。
今のmain.phpは
solver/sdpa/main.php
に移動して管理する予定。
元の場所のmain.phpは各種solverへのリンク集みたいなのと情報ページみたいになるのかな・・。
というわけでShortest Pathであれば、
solver/shortestpath/main.php
になるわけで
基本的にmain.phpというファイルは変数で書けるものは変数で書いてなるべく同じ書式にする。
基本フォーマットにはソルバーに関係なく使えるようなサンプルファイルを用意する。ソルバーの追加や変更を容易にするのとユーザーから見てフォーマットが似てる方が使いやすいという二つの意図があり。
それに伴い、共通の設定は別にcommonファイルを用意。ソルバー独自の設定が別に必要だがなるべくmain.phpのファイルをいじらないで別のphpファイルから読み出せるようにしたい。
最終的な決定は何種類か最適化プログラムの仕様が分かってからにならざるを得ないが・・。
それと前の更新で書いた一方を採用し、
userdata/username/solvername/data(param)
フォルダに入出力データを入れることに変更。
そうしないと一括管理が非常に難しくなるのと、input,output系のファイルが複数にわたるときの管理が面倒になるという理由があり。
今現在、初ログイン時に、必要なフォルダをmkdirコマンドを呼び作成しているのだが、そのままの仕様にするなら作成するフォルダの一覧を変数にして別のファイルに用意しておいた方が良いかな。
インターフェイスも変えたいがこういった仕様を先に決めておかないと後が厄介なのと自分に美的センスがないのとで結構悩みどころ・・。
2008年2月4日月曜日
フォルダの変更
オンラインソルバーを実際に稼働するときにはソルバーが今までのようにSDPA1個ではなくなるのでファイル管理の方式を変えなければならない。
今は一つのフォルダの中にパラメータのフォルダ、データのフォルダになっているのを
param/"solver_name"/
data/"solver_name"/
のように変更するつもりだ。このくらいの変更ならすぐにできるので問題はないはず。
問題があるとすればあるかわからないが他にファイルが必要になるソルバーだろう。あったとしてももう一つフォルダを作るとか逆に
"solver_name"/param/
"solver_name"/data/
"solver_name"/nannka/
のようにすれば良いだろう。
拡張性という意味では後者の方がいいかもしれない。
現行では、初ログイン時に、パラメータとサンプルファイルをコピーしているがこの処理を移項するまでは新フォルダと旧フォルダに両方コピーするようにしておこうと思う・・・。
今は一つのフォルダの中にパラメータのフォルダ、データのフォルダになっているのを
param/"solver_name"/
data/"solver_name"/
のように変更するつもりだ。このくらいの変更ならすぐにできるので問題はないはず。
問題があるとすればあるかわからないが他にファイルが必要になるソルバーだろう。あったとしてももう一つフォルダを作るとか逆に
"solver_name"/param/
"solver_name"/data/
"solver_name"/nannka/
のようにすれば良いだろう。
拡張性という意味では後者の方がいいかもしれない。
現行では、初ログイン時に、パラメータとサンプルファイルをコピーしているがこの処理を移項するまでは新フォルダと旧フォルダに両方コピーするようにしておこうと思う・・・。
2008年2月1日金曜日
インターフェイス
オンラインサービスにおいてインターフェイスというのは重要な存在で、技術的でなくても優先順位は高い方になる。美的センスのない自分がどうするかというのは色々考えているが・・。
それはさておき、なんにせよ実際にオンラインソルバーを動かすときも今と配置を結構変えなければならない。左の方にソルバーのリストを置いておき、使用するソルバーのページに飛んでもらって問題を解く形式にしようと思うが。
ほぼ同じような処理で使えるようにしたいので、今何のソルバーを使おうとしてるのかを明確にどこかに表示しないと間違って違うソルバーのページに飛んでしまったときに問題が見つからない等のトラブルでイライラしてしまうだろう。
ファイル管理もソルバーごとにフォルダを作った方がいいだろう。
その方がユーザーも管理しやすいであろうしいいと思うのだが、「グラフ」などの共通の問題に対して何回もアップロードさせるかどうかはちょっと考える余地がありそうだ。ソルバーの入力形式に依存するのでその辺も考慮しなければならないがそこまで共通の書式を取れることは少ないだろうなぁ。
それはさておき、なんにせよ実際にオンラインソルバーを動かすときも今と配置を結構変えなければならない。左の方にソルバーのリストを置いておき、使用するソルバーのページに飛んでもらって問題を解く形式にしようと思うが。
ほぼ同じような処理で使えるようにしたいので、今何のソルバーを使おうとしてるのかを明確にどこかに表示しないと間違って違うソルバーのページに飛んでしまったときに問題が見つからない等のトラブルでイライラしてしまうだろう。
ファイル管理もソルバーごとにフォルダを作った方がいいだろう。
その方がユーザーも管理しやすいであろうしいいと思うのだが、「グラフ」などの共通の問題に対して何回もアップロードさせるかどうかはちょっと考える余地がありそうだ。ソルバーの入力形式に依存するのでその辺も考慮しなければならないがそこまで共通の書式を取れることは少ないだろうなぁ。
2008年1月24日木曜日
登録:
投稿 (Atom)