この記事は はるアイコン鯖アドベントカレンダー 20日目(大遅刻)の記事です。
現在 http://map.troidworks.com/ にて公開している「はるアイコン鯖ジョ◯ダン」こと「はるダン」。このWebサイトがいかにして誕生したのか、また、何を目指しているのかをつらつらと書いていきたいと思います。
はるアイコン鯖路線案内システムについてのお話
先のブログポストでも触れたとおり、はるアイコン鯖は非常に鉄道が発展したサーバとして有名です。
はるアイコン鯖の駅は至る所に設置されているため、様々な地形や施設が「◯◯駅近辺の」というように説明されます。説明する側は説明しやすいのですが、説明された側はまず駅がどこにあるかを探す必要があります。そして、同じ駅間を移動するにしても様々なルートが存在するので、それを選ぶ必要があります。長距離を移動する場合は特に、乗換回数が最小となる乗り方が必ずしも最短経路となるとは限らない状況が発生しているため、問題はさらに複雑となります。
そこで、かなり前から提案されていたのが、はるアイコン鯖内の鉄道についての乗換案内、通称「はるアイコン鯖ジョ◯ダン」プロジェクトでした。駅間の移動時間を計算し、必要に応じて機械的に最短経路を求めることができれば、2地点間の移動が非常に便利になること間違いありません。
駅の個数は200駅程度ですので、単純な探索でも充分実用的な速度を達成することができます。しかし、乗換ナビを作る上で障害となったのは、駅の個数や路線の多さではなく、駅や駅間の測量が遅々として進まないという問題でした。
はるアイコン鯖の測量情報
そこで、まずは測量情報フォーマットの統一を図ることとしました。路線と駅を区別するIDが必要となりますが、通し番号で振るのは困難です。そこで、路線にはアルファベット2文字の路線IDを、駅にはアルファベット2文字(後に3文字になりました)の駅IDをすべての駅・路線に振りました。たとえば、harutrak B線にはHB、千歳駅にはCTSなど(IATA航空会社/空港コードを参考にしました)。
駅コードは複数の駅によって共有されます。役場駅のコードHHHはharutrak A/B線の役場前駅においても、中央/南北新幹線の新役場駅においても同じです。
それぞれの路線における駅を区別するためには、駅コードと路線コードを結合して完全修飾駅コードとします。たとえば、先ほどの役場駅の例ですと、hatutrak A線の役場駅はHAHHH、中央新幹線の役場駅はSCHHHとなります。
後は、各駅において、以下の項目を埋めるだけです。
- 駅の座標
- 駅の名前
- 乗換対象の駅
- 共有している駅
- 直接接続している駅とそこまでの距離
- ポイント切替で接続している駅とそこまでの距離
ちなみに、駅間の距離は、計測を開始したい地点のレールの上で/survey begin、計測を完了したいレールの上で/survey endとやると自動計測してくれます。
このようにして計測された駅と路線の情報は、github:HaruIconSurvey で管理されています。
将来的には、はるアイコン鯖APIで公開される予定なようです。
乗換案内システム
そして、計測した測量情報をもとに乗り換え案内システムを構築しました。
プロトタイプ版ということで非常に簡素な見た目しかありません。
作ってみて気付いたのですが、どこで何を指しているのかめっちゃわかりにくいんですね、これ。 というわけで、もうひとつの問題と統合しようとしています。
もうひとつの問題: 路線図のレンダリング
はるアイコン鯖はほうっておくと新しい駅や路線がスポーンするサーバーです。
ですので、路線図も定期的に更新しなければなりません。 現状は人力で更新していますが、誰か暇な人が居ない限り更新されませんから、最新の鉄道事情は よくわからないままとなっています。
というわけで、はるアイコン鯖APIからの情報をもとに路線図を一定時間ごとに自動生成することができれば 誰も手を煩わせなくて良いんじゃねーの、となっています。
そういうことで、今のところ、以下のシステムの開発に注力しています。
路線図描画システム "Arls" について
Arls は Automatic Route-map Layout System の略ということです。 名前に深い意味はありませんが、「アールズ」と読んでください。名前に深い意味はありません。
Arls は Python で構成されるバックエンドシステムと、JavaScript で記述されるフロントエンドに分割されます。バックエンドシステムでは、はるアイコン鯖APIを定期的に叩いて路線図を取得し、駅の自動配置を行います。
一言に「駅の自動配置を行う」と言ってもかなり難しく、一つの研究領域となっているようです。このあたりを参考にしています: Theory of Computing Lab. - メトロマップの自動描画問題における多基準最適化の実装
APIから取得するデータのうち、路線図システムで使用するデータは路線ごとの各駅の座標と駅名、路線名、路線色などです。バックエンドシステムは、これらのデータから駅座標のレイアウトを決定し、JSONファイルに出力します。
乗換案内との結合
あとはフロントエンドシステムが予めレイアウトされた駅座標に基いて各路線の描画をCanvasに行います。フロントエンドシステムの描画は乗り換え案内システムと連動して、通常状態は普通の路線図を提示しますが、乗換ルートを提示する場合には乗換ルート以外の部分をグレーアウトします。
と、こんな感じで実装できればなぁ…と思っていますが、どうなることやら。transitive.jsなどが類似として挙げられますが、あくまでこちらは「路線図」なので、拡大率に応じたレイアウトの動的な変更等は行いません。
というわけで
めどが立っていないけど頑張ります。
今日は12/25、いろいろなアドベントカレンダーが終焉を迎えますね！
完走したカレンダーもそうでないカレンダーも、記事書くのに遅刻したぐらいでブチギレないであげて欲しいものです。
