Google MAPS APIで円を描きたい
によれば、経度1度と緯度1度あたりの距離は、異なる（当たり前か）。現在、x-y軸方向に同一倍率で路線図を描いている。つまり、xyどちらかが圧縮された路線図になってしまっている。七面倒臭いけどxy両方の倍率を用意して、それぞれ別個に単位当たりの長さを算出、xy別々に掛け算をしないといけない、ということか。
これも当然なんだろうけど、北緯・東経が変われば、単位当たりの長さも変わる。これは参った。単位当たりの長さが一定ならば、北緯・東経さえわかってれば、緯度・経度の差に倍率掛けるだけである基準点に対する絶対位置を一意に決められる。でも単位当たりの長さが変わるのであれば、

経度１度あたりの長さ(m) = (π * ER * (1 – e2)) / (180 * (1 – e2 sin2(θ))3/2)
緯度１度あたりの長さ(m) = (π * ER * cos(θ)) / (180 * (1 – e2 sin2(θ))1/2)

こんなの積分できないっす。。
θはほとんど変動しないと考えて、2点の単位当たりの長さの平均で近似しようかねぇ。まずは誤差がどのくらいになるかの調査をしなければいかん。

Tweet

六帖webアプリ
kickzone/TrainNavi2 · GitHub
DBを整備したら千代田線の行先表示の「代々木上原」の文字がでかくてそれがずっと動き回って怖いので、「代」の1文字だけ表示するモードを作成した。
次は拡大縮小とスクロール。仕事と並行して作業していたので2倍の労力が必要になった。もう疲れたので、平日はしばらく大きな更新はやめる。集中力もガタ落ち、勉強も身が入らずよくない。日曜日まで待とう。

Tweet

六帖webアプリ
kickzone/TrainNavi2 · GitHub
祝日なのでゆっくり仕事しながらちょこちょこと行先表示を実装、と思ったら、夜に仕事がどっと来て涙目。行先表示まで実装はできた。これで、ある程度見た目がよくなった。
列車の行先名を普通の順序で並べる（相模大野）か、逆順で並べる（野大模相）かの境目を、線路が右下45度の直線より下になるかどうか、にした。
野大模相＼相模大野
文字は逆に、右上45度の直線より下になるかどうかが分かれ目。実装をけちって、駅停車時の状態の2駅間の表示を基準に、線路上はその中間になるようにしたら、藤沢や片瀬江ノ島あたりの線路がちょうどそのくらいの角度だったので、意図せず駅名が反転アニメーションするようになった。これはこれで面白いかも。
ところどころ連絡する列車の参照が取れてないのかDBが間違ってるのか、行先表示が間違っているところがある。次回はこのデバッグからか。

Tweet

javascriptで ^ という演算子はべき乗には使えない。XORの意味しかない。
Math.pow(底、指数)
で計算するしかない。二次元ベクトルの長さを求めるには
var nrmp1p2 = Math.sqrt(Math.pow(p1p2.x, 2) + Math.pow(p1p2.y, 2));
と書く必要がある。面倒。。関数を作った方がよさそうだ。

Tweet

六帖webアプリ
kickzone/TrainNavi2 · GitHub
用事を済ませてからデバッグ。一応、動作するようになった。今回のデバッグで、よーく覚えておかなければいけないことは、
・EaselJSでテキストオブジェクトを扱う際は、オブジェクト自体の大きさに気を付けること。点と点を結んだ直線と比べると、同じ座標にオブジェクトを置いても、getMeasuredWidth()/2, getMeasuredHeight()/2の分だけ、右下にずれる。これは、四角形などのShapeにも言えること。
・さらに、右下、ということに気が付いてなかった。そう、パソコンのXY軸は、ふつーの数学で使うXY座標軸とは違う。Y軸が180度反転している。ここでハマった。左90度回転のベクトルを作ろうと思ったら、通常の座標系でいう、右90度回転と同じ計算をしなければいけない。ベクトルの計算例で作成したコードを載せておきます。

//ベクトルの長さを計算
function norm(p){
return Math.sqrt(Math.pow(p.x, 2) + Math.pow(p.y, 2));
}
//p1p2, p3p2の角の二等分線を単位ベクトルで得る
function calcBisectUnitVector(p1, p2, p3)
{
//単位ベクトル同士を足すと出来上がり
var p1p2 = {x: p2.x - p1.x, y: p2.y - p1.y};
var nrmp1p2 = norm(p1p2);
var p3p2 = {x: p2.x - p3.x, y: p2.y - p3.y};
var nrmp3p2 = norm(p3p2);
var bisect = {x: p1p2.x/nrmp1p2 + p3p2.x/nrmp3p2, y: p1p2.y/nrmp1p2 + p3p2.y/nrmp3p2};
if(bisect.x == 0 && bisect.y == 0){
//1直線上に3点があった場合、打ち消しあって0になってしまう
//このときはp1p2の法線をリターン
return calcNormalUnitVector(p1, p2);
}
var nrmBisect = norm(bisect);
bisect.x /= nrmBisect;
bisect.y /= nrmBisect;
//p1p2の左側に二等分線が来るようにしたい
//p1p2と外積をとって、正なら反転させる
var cp = p1p2.x * bisect.y - p1p2.y * bisect.x;
if(cp > 0){
bisect.x = -bisect.x;
bisect.y = -bisect.y;
}
return bisect;
}
//p1p2の法線単位ベクトルを得る
//左90度回転
function calcNormalUnitVector(p1, p2)
{
//(x, y)の左90度回転ベクトルは(-y, x)
//しかしながら、PCの座標系はyが反転しているので、(y, -x)にしないといけない
var normalVec = {x: p2.y - p1.y, y: p1.x - p2.x};
var nrmNormal = norm(normalVec);
normalVec.x /= nrmNormal;
normalVec.y /= nrmNormal;
return normalVec;
}

前回のTrainNaviと比べると、JSONをやめて、サーバーとの通信の冗長性をひたすらなくしたことで、ローカルでさえ10秒ほどかかっていたローディングが、無料サーバー経由でもほんの1秒ほどで済むようになった。自分でもびっくり。一方、描画はのろい。行先表示もまだ未実装だというのに、15fpsでもCPU使用率が20%台をキープしている。非常に簡単なオブジェクトしか描画してないんだから、もっと軽くできるはずだ。例えば列車はテキストじゃなくてShapeにした方がいいかも。キャッシュ機能も使うべきかもしれない。

今後の予定：（優先順）

• 行先表示
• 拡大縮小、スクロール
• DB拡充
• 駅名表示（どこに表示するかが問題）
• パッケージファイルの読み込み
• 動作速度の改善

追加したい機能（優先順）

• スクロールに合わせた画面表示をする。画面にないオブジェクトを削除して動作を軽くする。スクロールして画面内に入ってきたところではじめて表示する。
• 通過点のエディット機能、ベジェ曲線で完璧な線路を引くためのGUI作成。ベジェ曲線 – diary 六帖
• GoogleMapと連携する。地図上を列車が走る。
• スキン機能。あらゆる路線図を作れるようにする。
• ターゲットとなる列車を決めて、強調表示する。今どのあたりを走っているかが分かる。
• 駅をクリックしたら情報を表示する。あと何分で電車が来るとか、目的地を決めたらそこまでかかる時間とか。
• 列車をクリックしたら情報を表示する。現在速度とか表定速度とか、次はどこに止まるかとか。
• 運賃を表示できるようにする。FareMap(自作)の機能を全部移植する。
• 時刻表を自動生成する。
• この際、NAVITIMEみたいな最短経路・最安経路生成機能も付けてしまう。

Tweet