GrandMap Navi Routing編(2)

　マップネット社のMio 168専用ナビゲーションソフトウェア「グランマップ・ナビ」、そのルーティング機能の評価、及び要望事項などを述べる。まず、前回述べた様に、ルーティング機能に経由地点が指定できるようにして欲しい。
　この機能の追加は、専用カーナビ装置ではVICSにより、ある程度リアルタイムで、交通渋滞や道路工事などの交通規制を回避することが可能だが、PDAではVICSから情報を得ることが、制度上出来ないし、ATISもパソコンやPDAのサービスから、携帯電話へてシフトしている。
　したがって、PDAでのナビによって、自動化によるリルート処理を行うよりは、マニュアルで事前にこれらを回避する為には、経由地点を設定する必要があるわけだ。また、地元の抜け道などを利用する場合にも、経由地点の設定は不可欠だろうし、長距離ドライブであれば、レストポイントとしても経由地点を設定できないと困る。
　また、現在のβ1では、実際にGPSによってナビゲーションを行った場合、GPSデータの保存機能が無いが、これも是非とも追加して欲しい。音声ガイドファイルには、GPSデータを保存するといったアナウンスもあるので、機能追加の計画はあるようだが、早期の実装をお願いしたい。加えて、ホームポジションを含んだ、ユーザのPOI保存機能も、不可欠だろう。
　これも、POI用と思われるピンのアイコンが、複数収録されているので、今後実装を行う予定なのだと想像する。同時に、ルート検索データも、保存が可能になっていると良いだろう。現在のβ1では、いきなりテスト走行や、実走行の実行で、ルート検索が行われるが、単独でルート検索が行えて、検索条件を変更し、複数のルートを地図上へ表示させ、これをユーザがどのルートを使用するか、選べるようになっていれば、使いやすくなると思う。
　また、可能であれば、POIデータやルートデータを、汎用のCSVファイルなどでエクスポートが可能であれば、母艦のパソコン上で、他の電子地図ソフトへインポートし、データ管理なども可能になるので、更に良い。また、市販の電子地図ソフトでも、POIなどのポイントデータを、CSVファイルでエクスポート可能なソフトも多いので、これがインポート可能になっていると、より便利に使用可能だ。

　さて、グランマップ・ナビβ1の不具合点をいくつか示しておく。当然、現在のβ1は、バグ出しという意味もあるので、これらのバグは次のβ2で、是非とも修正して欲しい。まず、ソフト本体ではなく、マップデータの不具合点だ。マップデータは、住友電工による電子地図データは、「拡張全国デジタル道路地図データベース」であるが、この作成年度がコピーライトには明示されていない。このマップデータが古いのか、間違っているのか不明だが、現実の道路交通規制と、ノード情報に含まれる、交通規制データ（あるいはノードの接合点）に誤りがある。
　上記の画面キャプチャ上段（左）は、ナビゲーション開始のサブメニューで、「OK」はGPSによるナビ開始となり、「テスト走行」は、ルーティング・シミュレーションだ。今回はルーティング・シミュレーションにて確認したのだが、最初の交差点で、直進をしている（キャプチャ上段の中）。この交差点の拡大した地図が、キャプチャ上段（右）であり、この交差点は左折のみで、直進は出来ない。
　一般的な交差点なのだが、三次元的には一目瞭然で、二次元的にみると、横浜環状二号線の高架道路と、側道、旧道が複雑に交差しているように見える。この部分は、出発ポイントから側道への接合ポイントのノード情報に、左折のみの情報が欠落しているのだ。
　画面下段（左）は、筆者宅より、横浜駅西口を指定し、ルーティングを行い、そのルーティング・シミュレーションを行った時のキャプチャだ。画面右上の地図が描画されていないが、通常はスクロールして描画される。問題は、交差点からのルーティング経路だ。未描画のエリア・エッジを横浜駅に向かって、一直線に描かれている。無論、道路は無い。
　スクロールして、未描画部分が描画された後も、道路の無い部分をルート表示されている（キャプチャ下段の中）。ちなみに、赤の点直線は横浜駅を示している。そして、その赤の点線とルート経路が重なり合い、道無き道を、シミュレーションの矢印は進み続ける。
　何度やっても、この現象は発生するのだが、これは戸部の交差点部分のノードポイントが、ちょうどマップデータのつなぎ目になってしまっており、偶然にも目的地の横浜駅西口のポイントも、データの切れ目に重なってしまった為に発生したと思われるが、ノード属性の欠落があるのかもしれない。いずれにしても、もともとの住友電工の元データか、グランマップ・ナビへのフォーマット変換、あるいはオーサリング時点で欠落したと思われる。
　実際、ロード・ネットワーク・データは、道路のポリラインと、そのポリラインが結合するノードから構成されるのだが、ポリラインに含まれる情報（道路幅、走行方向、制限速度、長さ等）と、そのポリラインがノードで結合される部分は、交通規制（右折、左折、直進等）情報が含まれる。このノードのチェックは、想像以上に手間の掛かる作業で、GISツールを用いて、全てのノードが正しく接続されているかをチェックしなければならない。
　見た目では、ノードが接続されているにも関わらず、論理的には非結合になっている場合、そのノードが開放されてしまい、ルーティングアルゴリズムによっては、今回のような結果になることも予想される。グランマップ・ナビに搭載されているルーティングエンジンの検索速度は、高速な検索なのだが、どうやら実際のポリライン（道路）との、ベリファイチェックが行われていないのではないかと思われる。

　次の画面キャプチャ上段（左）は、最終的に空中走行をした後、目的地の横浜駅西口へ到着直前のときのもの。実際に、筆者の愛車も、空を飛んでくれれば、渋滞を回避できるのだが。もっとも、そうなればナビは要らない。画面キャプチャ上段（中）は、何故かルート検索を筆者の近所を何度もシュミレーションしていたら、急に地図上へナスカ（NAZCA）の地上絵の様な、複数のポリライン直線（NAZCA滑走路）が表示されるようになった。
　ルーティング・シミュレーションが終了後に、その直線をたどっていくと、交差点に何本もの太さの異なるポリライン直線が、集まっていた（画面キャプチャ上段の右）。また、別のポリライン直線をトレースして行き、隣のエリアへスクロールすると、ポリライン直線が一気に全て消える。しかし、元のエリアへ戻ると、再び複数のポリライン直線が再表示される。
　どうも、筆者の住まいのエリアは、このナスカの滑走路直線が、ルート検索を行うと、自動的に表示されるようになってしまったらしい。これは、ルーティングエンジンのデバッグ用なのか、あるいはノード未処理部分の発見用なのか、バグなのか筆者には判断できない。バグではなく、デバッグ用のフラグがオンになってしまったとするならば、オフにしたいものだ。
　β1という評価バージョンではあるが、オリジナルの状態に戻すには、やはりMMCでの配布ではなく、CD-ROMからのオリジナルコピーが出来るとありがたい。画面キャプチャ下段（左）は、NAZCA滑走路が表示されているが、一応バードビュー表示モードに切り替えてみたところ。
　鳥瞰図というと、やはり道路の幅なども、遠近法を計算して、手前を広くし、遠くを狭くしないと、上部を間引いて表示しただけのように見える。凝っているのは、一応空の状況が、時間帯によって、昼間と夜に切り替わる。鳥瞰図への切り替えは、画面下のアイコンで切り替えるのだが、この機能のためにアイコンを二つ使用する必要はないだろう。アイコンのトグル表示切替にすれば、一つのアイコン表示で済むと思う。
　画面キャプチャ下段（中）は、NAZCA滑走路直線の集中点の例で、地図をこの状態で拡大すると、収束点には必ず交差点(ノード）が存在している。最後に、実際の走行時の画面キャプチャ（下段の右）を示しておく。「-（X）-」のカーソル点が、GPSによって取得された位置データで、矢印アイコンは道路上に表示されている。
　このことから、グランマップ・ナビには、マップマッチング機能が装備されていることがわかるだろう。実際、どの程度の範囲まで、GPSによる位置データと、道路上のポイントが離れていても、マップマッチを行ってくれるのかは、不明であるが、バイクや徒歩などでの使用を想定すると、設定でマップマッチングのオン・オフが可能になっていると、応用範囲が広がるのではないかと思う。
　以上、マップネット社のグランマップ・ナビβ1バージョンを評価してみたレポートである。正直、まだ全体としての完成度は低いが、各基本処理ルーチンは凝った設計になっている。また、メニューのデザインなども良いのだが、問題は、メニューの構造だ。これは、決して使いやすいメニューダイアグラムになっているとは言えない。
　ユーザが、ワンアクションでも少ないタップや操作によって、地図の表示やナビゲーションの開始を行えるのか、またPDA初心者が感性によって容易に操作できるような、メニューダイアグラムに改良すべきだと思うが、いかがだろうか。β2での改良を期待し、β1のレポートを終了する。