JP2022037505A - ナビゲーション装置、プログラム - Google Patents

Abstract

【課題】ユーザが１つ以上の避難場所候補から避難場所を選択できるナビゲーション装置及びプログラムを提供する。【解決手段】出発地から目的地までのルートを検索するナビゲーション装置１０であって、ユーザ情報を記憶する記憶部と、災害が発生した領域に関する災害情報を外部装置から受信する通信部１２と、前記ユーザ情報に基づいて前記領域に含まれない地点を避難場所候補として表示する表示制御部１９と、表示制御部が表示した避難場所候補から避難場所の選択を受け付ける操作受付部１７と、を有する。【選択図】図５

Description

本発明は、ナビゲーション装置、及び、プログラムに関する。

目的地までのルートを検索し、ユーザを目的地まで案内するナビゲーション装置が知られている。ナビゲーション装置を災害発生時に活用すれば、ユーザが適切な避難場所に避難することが可能になると考えられる。

このようなナビゲーション装置において、被災場所を通過しないルートを生成する技術が考案されている（例えば、特許文献１参照。）。特許文献１には、災害時において避難場所まで安全に行くことができるルートを出力する避難ルート装置が開示されている。

特開２０１３－１９５０９５号公報

しかしながら、従来の技術は、ユーザが１つ以上の避難場所候補から避難場所を選択できないという問題があった。災害時にユーザが把握できる避難場所は、自治体などが予め決めている施設に限られる場合が多く、避難場所が満員だったり、避難場所までのルートが渋滞したりするおそれがある。しかし、自治体などが予め決めている避難場所は数が多くないので、ユーザが代替の避難場所を検討することが困難であった。

図１は、自治体が指定する避難場所１０２とユーザの自宅１０１の位置を説明する地図の一例である。ナビゲーション装置は自治体が指定する避難場所１０２を目的地、ユーザの自宅１０１を現在地として、ルートを検索する。また、自治体では水害発生時を想定したハザードマップを提供しており、図１でもハザードマップに基づく被災場所１０３が示されている。被災場所１０３の濃度の違いは災害レベルを表す。図１に示すように、ユーザが安全な避難場所１０２に移動するためルートに沿って移動した場合、自宅付近の被災場所１０３ａだけでなく、避難場所１０２の手前の被災場所１０３ｂも通過しなければならない。従来技術によりナビゲーション装置が被災場所１０３を避けたルートを検索できるとしても、そもそも避難場所候補の数が少ないので避難場所が満員だったり、避難場所までのルートが渋滞したりするおそれがある。

本発明は、上記課題に鑑み、ユーザが１つ以上の避難場所候補から避難場所を選択できるナビゲーション装置を提供することを目的とする。

上記課題に鑑み、本発明は、出発地から目的地までのルートを検索するナビゲーション装置であって、ユーザ情報を記憶する記憶部と、災害が発生した領域に関する災害情報を外部装置から受信する通信部と、前記ユーザ情報に基づいて、前記災害が発生した領域に含まれない地点を避難場所候補として表示する表示制御部と、前記表示制御部が表示した前記避難場所候補から避難場所の選択を受け付ける操作受付部と、を有することを特徴とする。

ユーザが１つ以上の避難場所候補から避難場所を選択できるナビゲーション装置を提供することができる。

自治体が指定する避難場所とユーザの自宅の位置を説明する地図の一例である。 ナビゲーション装置が１つ以上の避難場所候補を出力する動作又は処理を説明する模式図である。 ナビゲーション装置の構成例を説明する図である。 ナビゲーション装置とサーバとを有するナビゲーションシステムの概略構成図である。 ナビゲーション装置が有する機能をブロック状に示す機能ブロック図の一例である。 災害マップを使用したルート検索を説明する図である。 災害マップを使用したルート検索を説明する図である。 避難場所候補の優先順位の決定方法を説明する図である。 ナビゲーション装置がディスプレイに表示する避難場所候補画面の一例である。 竜巻の場合の災害マップの一例を示す図である。 ナビゲーション装置が避難場所候補をディスプレイに表示する手順を示すフローチャート図の一例である。

以下、本発明を実施するための形態の一例について図面を参照しながら説明する。

＜ナビゲーション装置の動作又は処理の概略＞
まず、図２を参照して、本実施形態のナビゲーション装置の動作又は処理の概略を説明する。図２は、ナビゲーション装置１０が１つ以上の避難場所候補を出力する動作又は処理を説明する模式図である。なお、図２のナビゲーション装置１０は車両などの移動体に搭載されることが想定されるが、移動体に搭載されないで徒歩で移動するユーザがナビゲーション装置１０を有していてもよい。

(1) ナビゲーション装置１０は、スマートフォン等の情報処理端末４０と通信することができ、情報処理端末４０が予め保持している電話帳を情報処理端末４０から受信する。この電話帳には情報処理端末４０のユーザが使用する連絡先が登録されている。

(2) また、ナビゲーション装置１０は携帯電話網や無線ＬＡＮ等の通信ネットワークを介して外部装置６０から災害情報を受信できる。災害情報には、災害の種類、及び、災害が移動を制限する領域に関する災害マップが含まれる。

(3) ナビゲーション装置１０は、電話帳に登録されている連絡先の位置情報と災害マップを比較して、ユーザが災害による移動の制限を受けにくいルートで到達できる連絡先の位置情報を避難場所候補として出力する。

電話帳には一般に多くの連絡先が登録されているので、電話帳に登録されている連絡先から避難場所候補を決定することで、ナビゲーション装置１０は多くの避難場所候補をユーザに提示できる。また、電話帳に登録されている連絡先はユーザが行ったことがある場合も多いため、避難先として適切かどうかも判断しやすい。また、災害ごとに異なる災害マップが連絡先の位置情報と比較されるので、ナビゲーション装置１０は災害に応じて適切な避難場所候補を提示できる。

＜用語について＞
ユーザとはナビゲーション装置１０の利用者である。ナビゲーション装置１０が車載されている場合は、車両の乗員である。

避難場所とは、被災を避けるための場所である。避難場所候補は避難場所の候補である。

災害とは、異常な自然現象や人為的原因によって人間の社会生活や人命に及ぼす被害を言う。

移動が制限される領域に関する災害情報とは、主に被災場所に関する情報である。例えば災害により移動できない場所や移動に困難が伴う場所である。また、移動の制限とは移動できる限界や範囲が定められていること、又は、その限界や範囲を言う。制限には禁止が含まれる。

車両や二輪車に搭載されるナビゲーション装置１０をカーナビゲーション装置と呼ぶ場合がある。

電話帳とは、例えば、住所、施設名、氏名、又は、電話番号などの連絡先が登録された情報である。アドレスブックや連絡帳などと呼ばれてもよい。

＜構成例＞
図３は、ナビゲーション装置１０の構成例を説明する図である。まず、図３ではナビゲーション装置１０側でルート検索を行えるナビゲーション装置１０について説明する。ナビゲーション装置１０は少なくとも目的地までのルートを検索する機能を有している。また、付随して、目的地までのルートをディスプレイ２２に表示する機能も有する場合が多い。

ナビゲーション装置１０は出発地から目的地までのルートを検索して道路地図に設定し、ディスプレイ２２に表示された電子地図３０１にルートと現在地を表示したり、ルートに基づいて進路変更の手前で音声案内を出力したり、アニメーションなどで適切な進路を案内したりする。この他、ＡＶ(Audio Visual)の再生機能、インターネットとの通信機能等を有していてよい。ナビゲーション装置１０は、チューナー、ＰＮＤ（Portable Navigation Device）、又は、カーオーディオなどと呼ばれる場合もある。

なお、ナビゲーション機能を有さずに、主にＡＶ機能と通信機能を有する装置をディスプレイオーディオという。ディスプレイオーディオは、スマートフォンなどの端末装置との通信によりナビゲーションの機能を提供する。この場合、スマートフォンに搭載されるアプリがナビ画面を作成し、このナビ画面をディスプレイオーディオが通信で取得して車載装置側のディスプレイ２２に表示する。スマートフォンで動作するこのようなアプリとしてCarPlay（登録商標）やAndroid Auto（登録商標）等が知られている。ナビゲーション装置１０はディスプレイオーディオでもよい。

また、ナビゲーション装置１０は、汎用的な情報処理端末である場合と車両に専用の専用端末の場合がある。汎用的な情報処理端末とは、例えば、スマートフォン、タブレット端末、携帯電話、ＰＤＡ（Personal Digital Assistant）、ノートＰＣ、及び、ウェアラブルＰＣ（例えば、腕時計型、サングラス型など）などがある。これらの装置は、普段は情報処理端末として利用されるが、ナビゲーションのためのアプリケーションソフトウェアを実行すると、専用端末と同様、ルート検索及びルート案内等を行う。専用端末は、上記のナビゲーション装置１０、チューナー、又は、カーオーディオの他、ＰＮＤ（Portable Navigation Device）等を言う。

ナビゲーション装置１０は、汎用的な情報処理端末とナビゲーション専用端末のどちらの場合でも、車載された状態と携帯可能な状態の切り替えが可能であってもよい。つまり、ナビゲーション装置１０は、車両に脱着可能であってよい。

本実施形態では、ナビゲーション装置１０と別に、ユーザがスマートフォン等の情報処理端末４０を携帯して乗車し、ナビゲーション装置１０が情報処理端末４０と通信する。ナビゲーション装置１０と情報処理端末４０はBluetooth（登録商標）などの無線通信方式で予めペアリングされている。したがって、ナビゲーション装置１０と情報処理端末４０とが通信可能な距離に近づくと通信を開始できる。また、ユーザの操作等に応じてナビゲーション装置１０のアプリが情報処理システム側のアプリに電話帳を要求すると、ナビゲーション装置１０が図２にて説明した電話帳を受信できる。

また、本実施形態では、ナビゲーション装置１０とスマートフォン等の情報処理端末４０とが別体の場合を説明するが、ナビゲーション装置１０が汎用的な情報処理端末４０により実現されていてもよい。なお、ナビゲーション装置１０が汎用的な情報処理端末４０により実現される場合、ルート検索は図４にて説明するようにクラウド（サーバ）側で行われる場合が多い。このナビゲーション装置１０と汎用的な情報処理端末４０が一体の形態は歩行者ナビで使用される形態である。

また、ナビゲーション装置１０とスマートフォン等の情報処理端末４０とが別体の場合、及び、ナビゲーション装置１０が汎用的な情報処理端末４０により実現されている場合のいずれにおいても、ナビゲーション装置１０及び情報処理端末４０の少なくとも一方は外部装置６０から災害情報を受信できる。外部装置６０については図４にて説明する。

図４はナビゲーション装置１０とサーバ５０とを有するナビゲーションシステム１００の概略構成図である。図４の形態ではルート検索等をサーバ５０が行う。図４の形態においても、ナビゲーション装置１０とスマートフォン等の情報処理端末４０とが別体の場合、及び、ナビゲーション装置１０が汎用的な情報処理端末４０により実現されている場合がありうる。

ナビゲーション装置１０は基地局９（アクセスポイント）及びネットワークＮを介してサーバ５０と通信する。サーバ５０はナビゲーションに関する機能を各ナビゲーション装置１０に提供する。例えば、車両８が現在地を送信するとサーバ５０がナビ画面を作成して車両８に送信し、車両８が出発地と目的地を送信するとルートを検索して車両８に送信する。なお、電子地図を描画するための地図ＤＢ、道路の構造を表す道路構造ＤＢをサーバ５０が車両８に送信し、車両側でルート検索してもよい。

外部装置６０は、災害情報をナビゲーション装置１０に提供する例えばアクラウド上のサーバ装置である。災害情報を提供する公共機関としてはＶＩＣＳ（登録商標。Vehicle Information and Communication System）が知られている。例えば、所定以上の雨量の領域をメッシュ単位で提供する。ナビゲーション装置１０はナビ画面上に該当降雨エリアを重ねて表示する。

あるいは、外部装置６０は例えば、インターネット上で災害情報を提供する商用サイトでもよい。この場合、予め登録されている商用サイトのＵＲＬにナビゲーション装置１０が接続してもよいし、ユーザがナビゲーション装置１０を操作してナビゲーション装置１０を商用サイトに接続させてもよい。サーバ５０と外部装置６０が一体でもよいし、サーバ５０とは別に外部装置６０が存在してもよい。

また、本実施形態で使用される情報処理端末４０をユーザが操作して情報処理端末４０を外部装置６０に接続させてもよい。情報処理端末４０は受信した災害情報をナビゲーション装置１０に送信する。したがって、ナビゲーション装置１０が災害情報を受信する流れとしては、
(1) 外部装置６０ → ナビゲーション装置１０
(2) 外部装置６０ → 情報処理端末４０ → ナビゲーション装置１０
の２つがある。

＜機能について＞
図５は、ナビゲーション装置１０が有する機能をブロック状に示す機能ブロック図の一例である。ナビゲーション装置１０は、第一通信部１１、第二通信部１２、連絡先抽出部１３、位置検出部１４、ルート検索部１５、ルート案内部１６、操作受付部１７、ナビ画面作成部１８、及び、表示制御部１９を有している。

ナビゲーション装置１０が有するこれらの各機能は、ナビゲーション装置１０が有する情報処理装置の一般的なハードウェア（ＣＰＵ、ＲＡＭ、補助記憶装置、入出力Ｉ/Ｆ、ディスプレイ２２、キーボード、タッチパネル、通信装置等）を、補助記憶装置からＲＡＭに展開されたプログラムを実行するＣＰＵが制御することにより実現される機能又は手段である。

ユーザが携帯する情報処理端末（情報処理装置ともいう）がナビゲーション装置１０として動作する場合、このプログラムはナビゲーションようアプリケーションソフトに相当する。

また、ナビゲーション装置１０は補助記憶装置やＲＡＭ等により形成される道路構造ＤＢ２４、地図ＤＢ２５、及び、目的地ＤＢ２３を有している。まず、これらデータベースについて説明する。

表１は道路構造ＤＢ２４の構成を模式的に示す。道路構造ＤＢ２４は、車両が通行可能な道路の構造を表すデータであって、表１（ａ）のノードテーブルと表１（ｂ）のリンクテーブルとが相互に連携したデータ構造を有する。

ノードテーブルには、ノードを識別するためのノードＩＤとノードの座標（緯度・経度）、交差点の有無、一時停止の有無等が登録されている。ノードとは道路網表現上の結節点である。ノードは例えば交差点、分岐点、合流点、屈曲点などである。ノードＩＤが分かればノードに繋がっているリンクがリンクテーブルから判明するので、ナビゲーション装置１０はノードテーブルとリンクテーブルを相互に参照することで道路の構造を辿ることができる。なお、ノードテーブルには、この他、横断歩道の有無、接続されているリンク数などが登録されてよく、表１に示す情報には限られない。

また、リンクテーブルにはリンクを識別するためのリンクＩＤ、リンクの始点ノード、リンクの終点ノード、リンク長、道路種別、及び、交通法規などが登録されている。リンクとはノードとノードを結ぶ道路を表し、リンクはノード同士を結ぶ線分となる。道路種別は、例えば一般道、高速道路、専用道路、私道などである。交通法規は、当該リンクで定められている（禁止又は制限されている）車両の運転に関する交通規則又は交通ルールである。なお、リンクテーブルには、この他、車線数、幅員、周囲の施設情報などが登録されてよく、表１に示す情報には限られない。

表２は目的地ＤＢ２３の構成を模式的に示す。目的地ＤＢ２３にはユーザがナビゲーション装置１０に過去に設定した目的地（地点の一例）が登録されている。目的地は施設名でもよいし、住所でもよい。また、過去の全ての目的地が設定されていてもよいし、所定数以上の目的地は古いものから上書きされてもよい。目的地ＤＢ２３は記憶部の一例であり、目的地ＤＢ２３に記憶されている情報はユーザ情報の一例である。

地図ＤＢ２５は、電子地図３０１を描画するための地図データが記憶されている。電子地図３０１に表示される情報には、ベクトルデータやラスターデータで地図を描くためのデータが含まれている。地図データは経度・緯度などが既知のメッシュ状に区切られており、１つ以上のメッシュを結合して電子地図３０１が作成される。電子地図３０１に表示される情報には、都道府県などの区画、緑地や河川、道路や鉄道、記号や注記など多くの表示対象があるため、性質の似たものに分類し各分類ごとに描画できるようになっている。それぞれに分類された表示対象又は表示対象が描画された状態をレイヤーといい、電子地図３０１はいくつかのレイヤーを重ねることで描画される。

図５に戻って説明する。第一通信部１１は、情報処理端末４０と無線通信する。情報処理端末４０がナビゲーション装置１０にBluetooth（登録商標）で電話帳を送信するプロファイルにはＰＢＡＰ（Phone Book Access Profile）やＯＰＰ（Object Push Profile）がある。このようなプロファイルを使用してもよいし、専用の通信プロトコルで通信してもよい。なお、情報処理端末４０とナビゲーション装置１０はＵＳＢ（Universal Serial Bus）などの有線で通信してもよい。第一通信部１１が受信した電話帳は電話帳記憶部２６（記憶部の一例）に記憶される。なお、電話帳は予め電話帳記憶部２６に記憶されていてもよい。なお、電話帳はユーザ情報の一例である。

第二通信部１２は通信ネットワークを介して外部装置６０と通信する。通信ネットワークは、例えば、３Ｇ、４Ｇ、５Ｇなどの携帯電話網、又は、無線ＬＡＮなどである。あるいは、路車間通信や車車間通信で通信してもよい。第二通信部１２はユーザの操作に応じて、又は、定期的に外部装置６０に災害の有無を問い合わせて、災害が発生した場合、災害情報を受信する。外部装置６０からナビゲーション装置１０にプッシュ通知できる場合は、第二通信部１２から問い合わせしなくてよい。なお、第二通信部１２はユーザの現在地や進行方向を外部装置６０に通知して、ユーザに関係がある災害情報のみを受信してもよい。例えば、現在地から一定距離内で発生している災害、又は、現在の進行方向の前方で発生している災害などである。

連絡先抽出部１３は、電話帳から連絡先の位置情報を取得する。連絡先とは電話帳においてユーザが連絡を取れる相手の情報であるが、本実施形態では位置情報を特定できる情報であればよい。連絡先としては、例えば、住所、施設名、氏名、又は、電話番号などがある。住所は位置情報である（座標に変換できる）。施設名は施設用のＤＢをナビゲーション装置１０が検索することで位置情報に変換できる。氏名、電話番号についても位置情報に変換できる場合がある。氏名や電話番号が著名な施設のものである場合はインターネット上で住所を検索可能である。連絡先抽出部１３は、電話帳の１つのレコードごとに、住所があれば住所を、住所がない場合は施設名を、施設名がない場合は氏名を、氏名もない場合は電話番号を、抽出する。

操作受付部１７は、ナビゲーション装置１０に対する種々の操作を受け付ける。本実施形態では例えば避難場所候補を表示するメニューの押下を受け付ける。この他、ルート検索のための２つのＰＯＩ（例えば出発地と目的地）の入力、ルート案内の開始、再検索の指示、ナビ画面の拡大・縮尺の指示、及び、表示範囲変更などの指示を車両のユーザから受け付ける。なお、ユーザが過去に設定した目的地は目的地ＤＢ２３に登録される。

位置検出部１４は、定期的に及びユーザの操作に応じて、ＧＰＳ受信機が行う電波測位により、車両の現在地を緯度、経度、及び標高の座標として検出する。なお、位置検出部１４は、自律航法用センサを使って詳細な位置を推定し、更にマップマッチングにより車両の位置を道路上に補正する。

ルート検索部１５は、避難場所候補を表示するメニューが押下された場合、道路構造ＤＢ２４を用いて現在地から連絡先の位置情報又は過去の目的地までのルートを検索し、ルート情報を作成する。ルート検索には、リンク長や幅員、渋滞状況をコストに換算して、出発地から目的地までのコストの合計が最も少なくなるルートを選ぶダイクストラ法、ダイクストラ法にヒューリスティックコストを加えて検索するＡ*（エースター）法が知られている。また、決定したルートにおいて隣接するリンクのなす角が所定以上の場合、進行方向の変更が必要であると判断し、ルート情報において、進路変更の手前に案内ポイントを設定する。ルート検索部１５は、ルート検索で生成したルート情報をルート案内部１６、及び、ナビ画面作成部１８に送出する。

なお、ルート検索部１５は、現在地から連絡先の位置情報又は過去の目的地までのルートに優先順位を決定することが好ましい。例えば、距離、ルート安全性、及び、目的地の駐車場の多さなどに基づいて優先順位を決定する。

ルート案内部１６は、現在地（位置情報）とルート情報に基づいてルート案内を行う。すなわち、車両の現在地がルート情報に含まれる案内ポイントに到達すると、曲がり角などを指示する音声データをスピーカ２１から出力する。なお、音声データはＭＰ３などの形式でデータ化されていてもよいし、案内用のテキストデータに基づいて音声合成をおこなって作成してもよい。

ナビ画面作成部１８は、例えば車両の現在地の周囲を包含する電子地図３０１であって、ルートが強調表示された電子地図３０１を地図ＤＢ２５の地図データを用いて作成する。ナビ画面作成部１８は、更に車両の現在地を現在地マークなどで表示する。ナビ画面作成部１８は電子地図にメニューボタン等を加えてナビ画面を作成する。また、ナビ画面作成部１８は、大きな交差点など、拡大図が用意されている場所に車両が近づくと地図ＤＢ２５から地図データを取得して交差点等の拡大図を表示する。この他、ＡＶを操作する画面なども作成する。

表示制御部１９は、ルート検索部１５が検索した現在地から連絡先の位置情報又は過去の目的地までのルートにおける、連絡先の位置情報又は過去の目的地（すなわち避難場所候補）を優先順位にしたがって、ディスプレイ２２に表示する。ユーザは、１つ以上の避難場所候補の中から避難場所を選択する。選択された避難場所を操作受付部１７が受け付けて、該避難場所に移動するルートに基づく案内をルート案内部１６が開始する。

＜ルート検索＞
次に、図６、図７を用いて被災場所を避けるルート検索について説明する。図６は、災害マップを使用したルート検索を説明する図である。図６（ａ）は情報処理端末４０からナビゲーション装置１０に送信された電話帳を示す。図６（ａ）の電話帳は「青山公園」「赤井さん」「小川さん」「斉藤さん」「自治体避難場所」「高山小学校」「地方公園」という連絡先を有している。なお、各連絡先を押下すると詳細ページが表示され、詳細ページには住所、施設名、氏名、電話番号、及び、メールアドレスなども表示される。

電話帳にはユーザがよく行くか、又は、行ったことがある場所が登録されている。ナビゲーション装置１０はこのような場所を避難場所候補にするので、ユーザは避難先として適切かどうかも判断しやすい。また、個人差があるが、電話帳には多くの連絡先が登録されているため、ユーザはすいている避難場所候補、及び、駐車場が多い避難場所候補などを選択しやすくなる。

また、本実施形態では、ユーザが過去に目的地に設定したことがある場所も避難場所候補となる。この場所もユーザが行ったことがある場所なので、ナビゲーション装置１０はこのような場所を避難場所候補にすることで、ユーザが避難先として適切かどうかも判断しやすい。

ナビゲーション装置１０は、電話帳を情報処理端末４０から直接、受信する他、サーバからダウンロードしてもよい。

図６（ｂ）は水害の場合の災害マップ２１０を模式的に示す。災害マップ２１０は例えばメッシュごとに４つの頂点の座標と災害レベルを指定する情報である。メッシュのサイズは小さいほど詳細な災害マップ２１０となるが、通信容量が増大したり表示処理に負荷がかかったりするため、適宜、調整されている。なお、メッシュごとでなくリンクごとに災害レベルが指定されてもよい。

災害レベルは、例えば以下のようになる。
１．走行不可
２．走行可能（危険度大）
３．走行可能（危険度中）
４．走行可能（危険度小）
図６（ａ）の連絡先と図６（ｂ）の災害マップは、図６（ｃ）の地図の対応する位置に存在すると見なされる。ナビゲーション装置１０は走行不可の領域を避けたルートを検索できる。

なお、水害の場合の災害マップには静的なものとリアルタイムのものがある。本実施形態ではどちらが利用されてもよい。静的な災害マップとして各自治体が公開するハザードマップがある。

図７（ａ）は比較のために示した災害マップが含まれない場合の所定領域の地図である。現在地２０１と３つの避難場所候補Ａ～Ｃが示されている。災害が発生していない場合、ユーザが避難場所候補Ａに行くには、例えば、現在地２０１から避難場所候補Ａへのルート１が選択される。同様に、ユーザが避難場所候補Ｂに行くには、例えば、現在地２０１から避難場所候補Ｂへのルート２が選択される。ユーザが避難場所候補Ｃに行くには、例えば、現在地２０１から避難場所候補Ｃへのルート３が選択される。

図７（ｂ）は災害マップ２１０が含まれる所定領域の地図である。ルート検索部１５は図６（ｂ）の災害マップ２１０を地図に重ねてリンクごとに重なっている災害マップの災害レベルを特定する。リンクの両端のノードのどちらか一方が災害マップのメッシュに含まれる場合、該リンクが災害マップに重なっていると判断される。ルート検索部１５は、災害レベルが走行不可のリンクのコストを無限大にすることで、走行不可のリンクを通過しないルートを検索できる。その他の２～４の災害レベルはコストに反映せずにルートを検索してよい。これらの災害レベルは優先順位に反映されるからである。ただし、２～４の災害レベルを例えばユーザ操作でコストに反映してもよい。

ここでは説明を簡単にするため、災害マップ２１０の全てのメッシュが走行不可であるとする。図のような災害マップ２１０が得られている場合、ルート検索部１５は災害マップ２１０を通過しないルートを検索する。このため、ユーザが避難場所候補Ａに行くには、例えば、現在地２０１から避難場所候補Ａへのルート４が選択される。同様に、ユーザが避難場所候補Ｂに行くには、例えば、現在地２０１から避難場所候補Ｂへのルート５が選択される。ユーザが避難場所候補Ｃに行くには、例えば、現在地２０１から避難場所候補Ｃへのルート６が選択される。そして、ルート検索部１５は、走行できるルート４～６について災害レベル等に応じて優先順位を決定する。

なお、図１に示したように、現在地２０１がすでに災害マップに含まれる状況が生じうる。この状況が生じるのは、災害マップ２１０が静的なものであるため現状の現在地２０１は走行可能である場合、又は、災害マップ２１０がリアルタイムのものだが現状の現在地２０１の災害レベルは走行可能である場合である。つまり、実際には現在地２０１が走行可能である場合である（そうでないとユーザは車両で避難できない）。

このような場合、ルート検索部１５は、例えば、現在地２０１から走行不可の領域を抜けるまで、走行不可のメッシュを検索の対象に含める。すなわち、コストを無限大にしないで、通常のコストを使用する。こうすることで、現在地２０１がすでに走行不可のメッシュに含まれていても、ルート検索部１５が避難場所候補までのルートを検索できる。

＜優先順位の決定＞
次に、図８を参照して避難場所候補の優先順位の決定方法について説明する。図８は、避難場所候補の優先順位の決定方法を説明する図である。ルート４には災害レベルが２の災害マップのメッシュ２１１があり、ルート５，６には災害レベルが３の災害マップのメッシュ２１２がある。説明のため、優先順位を決定する要素を距離、ルート安全性、及び、目的地の駐車場の多さとする。ただし、優先順位はこれらの１つ以上を使用してよいし、これら以外の要素を使用してもよい。

ルート検索部１５は、距離、ルート安全性、及び、目的地の駐車場の多さにそれぞれに順位を付ける。

距離については短い方が好ましいので、短い順に順位を付ける。
１番 ルート５
２番 ルート６
３番 ルート４
ルート安全性については、各ルートが通過する各リンクの災害レベル（小さいほど危険性が高い）の値を合計し、大きい順に順位を付ける。
１番 ルート５、６
２番 －
３番 ルート４
目的地の駐車場の多さは、例えば、施設用のＤＢから取得する。多い順に順位を付ける。
１番 ルート５
２番 ルート６
３番 ルート４
ルートごとにこれらの順位を合計すると以下のようになる。
ルート５：１＋１＋１＝３点
ルート６：２＋１＋２＝５点
ルート４：３＋３＋３＝９点
以上から、ルート検索部１５は、ルート５，６，４の目的地である避難場所候補Ｂ、Ｃ、Ａに、この順番で優先順位を決定する。表示制御部１９は優先順位の昇順に避難場所候補を表示する。したがって、例えば、自治体が推奨する避難場所候補があっても、表示しないか、又は、低い優先順位で表示できる。

図９は、ナビゲーション装置１０がディスプレイ２２に表示する避難場所候補画面の一例である。避難場所候補画面は優先順位に対応づけられた各項目を有している。
・避難場所候補…電話帳の連絡先及び目的地ＤＢ２３の少なくとも一方に設定されている目的地の候補である。
・距離…現在地から各避難場所候補にユーザが移動するルートの道なりの距離（リンクの長さの合計）である。距離の項目は短いほど優先順位が高くなる。
・災害レベル…各ルートが通過する各リンクの災害レベルの合計値である。つまり、どの程度の距離でどの程度の災害レベルの被災場所を通過するかを表す。災害レベルの項目は大きいほど優先順位が高くなる。
・駐車場の多さ…避難場所候補の駐車場のパーキングロットの数である。

ユーザは優先順位を重んじながら、自分が重視する項目を参照して最終的な避難場所を決定できる。

＜水害以外の災害マップについて＞
水害以外の災害として、地震、火災、竜巻、噴火、停電、断水、積雪、及び、感染症などがある。ナビゲーション装置１０はこれらについても災害マップがあれば同様に優先順位を決定できる。

地震の場合の災害マップは震度マップでよい。例えば、震度５以上の領域の災害レベルを走行不可、震度４の領域の災害レベルを走行可能（危険度大）、震度３の領域の災害レベルを走行可能（危険度中）、震度２の領域の災害レベルを走行可能（危険度小）とする。ナビゲーション装置１０が外部装置６０から震度だけでなく土砂崩れが発生した特定の領域を受信できた場合は、走行不可として扱う。

次に、本実施形態の火災とは主に、森林や工場などの大規模な火災をいう。この場合は外部装置６０から災害マップが配信されないとしても、「○○工場で火災です」等の災害情報に基づいてルート検索部１５が災害マップを作成できる。「○○工場」を含む所定領域を走行不可と判断すればよい。

竜巻の場合の災害マップの一例を図１０に示す。竜巻の場合、予想進行方向２３０と風速が外部装置６０から災害マップとして送信される。災害マップは予想進行方向２３０に含まれる領域である。予想進行方向２３０の内側の災害レベルが走行不可であり、予想進行方向から離れるにつれて、大きくなる災害レベルの値が設定されている。

噴火の場合の災害マップは噴石が落下する場所、及び、マグマが流れる場所が外部装置６０から災害マップとして送信される。噴石が落下する場所、及び、マグマが流れる場所の災害レベルが走行不可であり、これらの場所から離れるにつれて、大きくなる災害レベルの値が設定されている。

停電の場合の災害マップは停電している領域が外部装置６０から送信される。停電している領域の災害レベルが走行不可であり、これら以外の場所は災害レベルを設定しなくてもよい。あるいは、停電の領域から離れるにつれて、大きくなる災害レベルの値が設定されていてもよい。

断水の場合の災害マップは断水している領域が外部装置６０から送信される。断水している領域の災害レベルは走行可（危険度小）である。

積雪の場合の災害マップは積雪量に応じたものである。各領域の積雪量が外部装置６０から送信される。例えば、積雪が１５ｃｍ以上の領域を走行不可、積雪が１０ｃｍ以上の領域を走行可能（危険度大）、積雪が５ｃｍ以上の領域を走行可能（危険度中）、積雪が１ｃｍ以上の領域を走行可能（危険度小）とする。

感染症の場合、災害マップは、病床の逼迫具合、療養者数、PCR（olymerase chain reaction）検査の陽性率、新規感染者の報告数、直近１週間とその前の１週間の比較、及び、感染経路不明割合を指標として、メッシュごとに指標を数値化したものである。例えば、各指標を１～５で数値化し、指標の合計をメッシュの数値とする。例えば、数値が閾値４以上の領域を走行不可、数値が閾値３以上の領域を走行可能（危険度大）、数値が閾値３以上の領域を走行可能（危険度中）、数値が閾値１以上の領域を走行可能（危険度小）とする（閾値４＞閾値３＞閾値２＞閾値１）。

なお、いずれの災害の場合も、ナビゲーション装置が災害マップを作成してよいし、災害レベルを設定するなど災害マップを修正してよい。

＜動作又は処理の手順＞
図１１は、ナビゲーション装置１０が避難場所候補をディスプレイ２２に表示する手順を示すフローチャート図の一例である。

ユーザはニュースなどで災害の発生を知ると避難場所に避難しようと行動を開始する。まず、操作受付部１７は避難場所候補を表示するメニューの押下を受け付ける（Ｓ１）。この操作に応じて、第二通信部１２は災害マップを外部装置６０から取得する（Ｓ２）。したがって、災害の発生時に災害マップを取得できる。災害マップがない場合は例えばハザードマップなどユーザが指定した災害マップを取得してもよい。ナビゲーション装置１０がユーザの操作で避難場所候補の表示処理を開始するのでなく、緊急地震速報などの災害情報が送信されたことを契機にナビゲーション装置１０が避難場所候補の表示処理を開始するとよい。

また、第一通信部１１は情報処理端末４０から電話帳を取得する（Ｓ３）。更に、ルート検索部１５は目的地ＤＢ２３から目的地を取得する（Ｓ４）。

ルート検索部１５は連絡先の位置情報又は過去の目的地を目的地に設定して、走行不可のリンクを避けるルートを検索する（Ｓ５）。

なお、ルートの全体が走行不可のリンクを回避するのでなく、災害マップの走行不可のメッシュに含まれない連絡先の位置情報又は過去の目的地を避難場所候補としてもよい。目的地としては安全な避難場所候補を小さい処理不可で得られる。この場合、ルート検索部１５は連絡先の位置情報又は過去の目的地が、災害マップの走行不可のメッシュに含まれるかどうかを判断すればよい。

ルート検索部１５は距離、ルート安全性、及び、駐車場の多さで避難場所候補の優先順位を決定する（Ｓ６）。表示制御部１９は優先順位にしたがって、避難場所候補を表示する（Ｓ７）。

＜主な効果＞
本実施形態では、避難場所候補に電話帳の連絡先を使用する。電話帳には一般に多くの連絡先が登録されているので、電話帳に登録されている連絡先から避難場所候補を決定することで、ナビゲーション装置１０は多くの避難場所候補をユーザに提示できる。また、電話帳に登録されている連絡先はユーザが行ったことがある場合も多いため、避難先として適切かどうかも判断しやすい。また、災害ごとに異なる災害マップが連絡先の位置情報と比較されるので、ナビゲーション装置１０は災害に応じて適切な避難場所候補を提示できる。

＜その他の適用例＞
以上、本発明を実施するための最良の形態について実施例を用いて説明したが、本発明はこうした実施例に何等限定されるものではなく、本発明の要旨を逸脱しない範囲内において種々の変形及び置換を加えることができる。

例えば、本実施形態では移動体として車両を例にして説明したが、移動体としては自転車、ドローン、飛行機、回転翼航空機、滑空機、飛行船、船、潜水艦、ロボット、などでもよい。

情報処理端末４０がナビゲーション装置１０として使用される場合、ナビゲーション装置１０は電話帳を予め保持している。

また、ナビゲーション装置１０は歩行者ナビにも使用できる。この場合、歩行者用の道路構造ＤＢを参照してルート検索される。災害マップは移動体で移動する場合と同じでよい。

また、図５などの構成例は、ナビゲーション装置１０の処理の理解を容易にするために、主な機能に応じて分割したものである。処理単位の分割の仕方や名称によって本願発明が制限されることはない。また、ナビゲーション装置１０の処理は、処理内容に応じて更に多くの処理単位に分割することもできる。また、１つの処理単位が更に多くの処理を含むように分割することもできる。

１０ ナビゲーション装置
２２ ディスプレイ
５０ サーバ
６０ 外部装置

Claims (12)

1. 出発地から目的地までのルートを検索するナビゲーション装置であって、
   ユーザ情報を記憶する記憶部と、
   災害が発生した領域に関する災害情報を外部装置から受信する通信部と、
   前記ユーザ情報に基づいて、前記災害が発生した領域に含まれない地点を避難場所候補として表示する表示制御部と、
   前記表示制御部が表示した前記避難場所候補から避難場所の選択を受け付ける操作受付部と、
   を有することを特徴とするナビゲーション装置。
2. 前記ユーザ情報は連絡先が登録された電話帳を含み、
   前記表示制御部は、前記連絡先の位置情報のうち前記領域に含まれない地点を避難場所候補として表示することを特徴とする請求項１に記載のナビゲーション装置。
3. 前記ユーザ情報は、過去に前記目的地に設定された地点を含み、
   前記表示制御部は、前記地点から過去に前記目的地に設定された場所のうち、前記領域に含まれない前記場所を前記避難場所候補として表示することを特徴とする請求項１に記載のナビゲーション装置。
4. 前記ユーザ情報は連絡先が登録された電話帳及び過去に前記目的地に設定された地点を含み、
   前記電話帳に含まれる前記連絡先の位置情報、又は、過去に前記目的地に設定された場所を前記目的地に設定し、前記領域を通過しないルートを検索するルート検索部を有し、
   前記表示制御部は、前記領域を通過しない前記ルートの目的地に設定された前記連絡先の位置情報、及び、過去に前記目的地に設定された場所の少なくとも一方を前記避難場所候補として表示することを特徴とする請求項２又は３に記載のナビゲーション装置。
5. 前記災害情報には災害レベルが含まれており、
   前記ルート検索部は、走行不可の前記災害レベルの領域を通過しない前記ルートを検索し、
   前記ルートが通過する走行不可でない前記災害レベルに基づいて前記連絡先の位置情報、及び、過去に前記目的地に設定された場所の少なくとも一方の優先順位を決定し、
   前記表示制御部は、前記優先順位にしたがって前記連絡先の位置情報、及び、過去に前記目的地に設定された場所の少なくとも一方を前記避難場所候補として表示することを特徴とする請求項４に記載のナビゲーション装置。
6. 前記ルート検索部は、更に、走行不可の前記災害レベルの領域を通過しない前記ルートの距離に基づいて前記連絡先の位置情報、及び、過去に前記目的地に設定された場所の少なくとも一方の優先順位を決定し、
   前記表示制御部は、前記優先順位にしたがって前記連絡先の位置情報、及び、過去に前記目的地に設定された場所の少なくとも一方を前記避難場所候補として表示することを特徴とする請求項５に記載のナビゲーション装置。
7. 前記ルート検索部は、更に、前記連絡先の位置情報、及び、過去に前記目的地に設定された場所の駐車場の多さの少なくとも一方で優先順位を決定し、
   前記表示制御部は、前記優先順位にしたがって前記連絡先の位置情報、及び、過去に前記目的地に設定された場所の少なくとも一方を前記避難場所候補として表示することを特徴とする請求項５又は６に記載のナビゲーション装置。
8. 前記表示制御部は、前記連絡先の位置情報、及び、過去に前記目的地に設定された場所の少なくとも一方と共に、前記ルート検索部が検索した前記ルートの距離、及び、前記ルートが通過する前記災害レベルの大きさを表示することを特徴とする請求項５又は６に記載のナビゲーション装置。
9. 前記災害は、水害、地震、火災、竜巻、噴火、停電、断水、積雪、又は、感染症であり、
   前記通信部は、前記災害に応じて、前記領域に関する前記災害情報を外部装置から受信することを特徴とする請求項１～８のいずれか１項に記載のナビゲーション装置。
10. ユーザの連絡先が登録された前記電話帳を外部から受信することを特徴とする請求項２に記載のナビゲーション装置。
11. 出発地から目的地までのルートを検索するナビゲーション装置であって、
    ユーザ情報を記憶する記憶部と、
    災害が発生した領域に関する災害情報を外部装置から受信する通信部と、
    前記ユーザ情報に基づいて前記領域に含まれない地点を避難場所候補として表示する表示制御部と、
    前記表示制御部が表示した前記避難場所候補から避難場所の選択を受け付ける操作受付部と、
    を有することを特徴とするナビゲーション装置。
12. 情報処理端末を、
    出発地から目的地までのルートを検索するルート検索部と、
    災害が発生した領域に関する災害情報を外部装置から受信する通信部と、
    記憶部が記憶するユーザ情報に基づいて、前記領域に含まれない地点を避難場所候補として表示する表示制御部と、
    前記表示制御部が表示した前記避難場所候補から避難場所の選択を受け付ける操作受付部、
    として機能させるためのプログラム。

Images