(57)【要約】【課題】道幅情報をリアルタイムに更新して、本当に快適に通行可能な道路をルートとして決定して案内することができるナビゲーション装置、サーバ、および、道幅情報更新方法を提供する。【解決手段】ルート検索を行うナビゲーション装置において、走行中に道路の有効幅員を検出する道路有効幅員検出部１５を備え、道路の有効幅員をルート検索に使用する道幅コストに換算し、候補となるルート毎のコストを算出して、当該コストに基づいて、前記ルートのいずれかを最適なルートに決定してルート案内を行うとともに、検出された有効幅員が所定値未満である場合に、記憶されている有効幅員データを更新するようにしたので、より有効なルート検索およびルート案内を行うことができる。【選択図】図１
2014202560.tif 000002
【特許請求の範囲】
【請求項１】
車両の現在地と地図データとに基づいて前記車両の現在地から目的地までのルート検索を行う、前記車両に搭載または設置されたナビゲーション装置において、
前記車両の走行中に、当該走行中の道路の有効幅員を検出する道路有効幅員検出部と、
少なくとも有効幅員データと、当該有効幅員データと道幅コストとの対応表とを記憶する記憶部と、
前記記憶部に記憶されている対応表に基づいて、前記有効幅員を道幅コストに換算し、候補となるルート毎にコストを算出して、当該コストに基づいて、前記ルートのいずれかを最適なルートとして決定してルート案内を行う処理部とを備え、
前記処理部は、前記道路有効幅員検出部を用いて取得した有効幅員が所定値未満である場合に、前記記憶部に記憶されている有効幅員データを更新する
ことを特徴とするナビゲーション装置。
【請求項２】
前記記憶部には、前記車両の車幅と、当該車両を利用するユーザの道幅に関する好みとが予め記憶されており、
前記処理部は、前記記憶部に記憶されている前記車両の車幅と前記ユーザの道幅に関する好みとに基づいて、前記有効幅員を前記道幅コストに換算する
ことを特徴とする請求項１記載のナビゲーション装置。
【請求項３】
情報の送受信を行うことが可能なサーバと通信可能な通信部をさらに備え、
前記処理部は、
前記道路有効幅員検出部を用いて取得した有効幅員が所定値未満である場合に、前記記憶部に記憶されている有効幅員データを更新するとともに、当該有効幅員データを前記通信部を介して前記サーバに送信し、
前記ルート検索の際には、前記通信部を介して前記サーバから前記有効幅員データを取得して利用するとともに、前記記憶部に記憶されている有効幅員データを更新する
ことを特徴とする請求項１記載のナビゲーション装置。
【請求項４】
前記処理部は、前記サーバから、前記車両が通過する予定の日時における有効幅員予測データおよび当該有効幅員予測データの信頼度を取得し、当該信頼度に基づいて、前記有効幅員予測データを前記道幅コストに換算して、前記ルート案内を行う
ことを特徴とする請求項３記載のナビゲーション装置。
【請求項５】
車両に搭載または設置されたユーザ端末と通信を行い、当該ユーザ端末から前記車両の現在地および目的地を取得し、前記車両の現在地と地図データとに基づいて前記車両の現在地から目的地までのルート検索を行うナビゲーション機能を有するサーバにおいて、
前記ユーザ端末から少なくとも前記車両が走行中の道路の有効幅員を受信するサーバ通信部と、
少なくとも有効幅員データと、当該有効幅員データと道幅コストとの対応表とを記憶するサーバ記憶部と、
前記ユーザ端末から受信した有効幅員が所定値未満である場合に、前記サーバ記憶部に記憶されている有効幅員データを更新し、前記サーバ記憶部に記憶されている対応表に基づいて、前記有効幅員を前記道幅コストに換算し、候補となるルート毎にコストを算出して、当該コストに基づいて、前記ルートのいずれかを最適なルートとして決定して、前記ユーザ端末に対してルート案内を行うサーバ処理部とを備えた
ことを特徴とするサーバ。
【請求項６】
少なくとも気象情報およびイベント情報を含む周辺情報を取得する周辺情報取得部をさらに備え、
前記サーバ処理部は、
前記ユーザ端末から受信した有効幅員を、日時および周辺状況毎に分類して各平均値および各標準偏差を算出し、それらの組み合わせにより、ルート検索条件における有効幅員予測データおよび当該有効幅員予測データの信頼度を求め、
当該有効幅員予測データの信頼度に基づいて、前記車両が通過する予定の日時における有効幅員予測データを前記道幅コストに換算して、前記ルート案内を行う
ことを特徴とする請求項５記載のサーバ。
【請求項７】
前記サーバ処理部は、
前記有効幅員予測データまたは当該有効幅員予測データの信頼度が更新される毎に前記ルート検索を行い、
前記車両が一定時間内に通過予定の分岐点においてルート変更がある場合に限り、前記ユーザ端末に対して前記ルート案内を行う
ことを特徴とする請求項６記載のサーバ。
【請求項８】
車両の現在地と地図データとに基づいて前記車両の現在地から目的地までのルート検索を行うナビゲーション装置の道幅情報更新方法であって、
道路有効幅員検出部が、前記車両の走行中に、当該走行中の道路の有効幅員を検出するステップと、
処理部が、前記道路有効幅員検出部を用いて取得した有効幅員が所定値未満である場合に、記憶部に記憶されている有効幅員データを更新するステップと、
前記処理部が、前記記憶部に記憶されている有効幅員データと、当該有効幅員データと道幅コストとの対応表とに基づいて、前記有効幅員を前記道幅コストに換算し、候補となるルート毎にコストを算出して、当該コストに基づいて、前記ルートのいずれかを最適なルートとして決定してルート案内を行うステップと
を備えたことを特徴とする道幅情報更新方法。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明は、目的地までのルート検索を行う際の道幅情報をリアルタイムに更新する車両用のナビゲーション装置、サーバ、および、道幅情報更新方法に関するものである。
【背景技術】
【０００２】
一般的に、自動車等の車両に搭載されるナビゲーション装置は、自車位置および地図データに基づいて、設定された目的地までのルート検索を行い、運転者等のユーザに対して表示や音声によるルート案内を行う。この際、地図データに含まれる道幅なども考慮した上で、最適なルートを提示するルート案内が行われている。
【０００３】
例えば、特許文献１には、設定された目的地までのルートを探索してルート案内を行う車載用ナビゲーション装置において、探索したルート毎のコストを算出して、そのコストに基づいて最適なルートを決定すること、および、そのコスト算出の際に、道路属性コスト、道幅コスト、車線数コスト、分岐コスト、信号機コスト、距離コストなどを使用することが記載されている。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２００５−７７３００号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
しかしながら、例えば特許文献１に示すような従来のナビゲーション装置では、路上駐車している車両の有無や、対向車、通行人、その他イベントなどにより、実際には実効的な道幅が減少していて、快適に通行するには道幅が十分ではない道路であっても、最適なルートとして決定され案内されてしまうことがある、という課題があった。
【０００６】
この発明は、上記のような課題を解決するためになされたものであり、道幅情報をリアルタイムに更新して、本当に快適に通行可能な道路をルートとして決定して案内することができるナビゲーション装置、サーバ、および、道路情報更新方法を提供することを目的とする。
【課題を解決するための手段】
【０００７】
上記目的を達成するため、この発明は、車両の現在地と地図データとに基づいて前記車両の現在地から目的地までのルート検索を行う、前記車両に搭載または設置されたナビゲーション装置において、前記車両の走行中に、当該走行中の道路の有効幅員を検出する道路有効幅員検出部と、少なくとも有効幅員データと、当該有効幅員データと道幅コストとの対応表とを記憶する記憶部と、前記記憶部に記憶されている対応表に基づいて、前記有効幅員を道幅コストに換算し、候補となるルート毎にコストを算出して、当該コストに基づいて、前記ルートのいずれかを最適なルートとして決定してルート案内を行う処理部とを備え、前記処理部は、前記道路有効幅員検出部を用いて取得した有効幅員が所定値未満である場合に、前記記憶部に記憶されている有効幅員データを更新することを特徴とする。
【発明の効果】
【０００８】
この発明によれば、多数のユーザが走行中に計測した道幅（有効幅員データ）に基づいて、道幅情報をリアルタイムに更新することにより、実際に有効な道幅情報を用いることができるので、本当に快適に通行可能な道路をルートとして決定して案内することができ、より有効なルート検索およびルート案内を行うことができる。
【図面の簡単な説明】
【０００９】
【図１】実施の形態１におけるユーザ端末とサーバの構成を示すブロック図である。
【図２】カメラを車両に搭載した設置状態を車両側面から見た概略図である。
【図３】有効幅員データと道幅コストとの対応表の一例を示す表である。
【図４】実施の形態１におけるユーザ端末が有効幅員データを収集する処理を示すフローチャートである。
【図５】実施の形態１におけるユーザ端末が有効幅員データを利用してルート検索する処理を示すフローチャートである。
【図６】実施の形態２におけるユーザ端末とサーバの構成を示すブロック図である。
【図７】実施の形態２におけるサーバが有効幅員を予測する処理を示すフローチャートである。
【図８】予測データの信頼度が高い場合と低い場合を考慮した、有効幅員予測データと道幅コストとの対応表の一例を示す表である。
【図９】実施の形態２におけるユーザ端末が有効幅員データを利用してルート検索する処理を示すフローチャートである。
【図１０】実施の形態３におけるサーバが有効幅員データを利用してルート検索するとともにユーザ端末へ通知を行う処理を示すフローチャートである。
【図１１】実施の形態４におけるナビゲーションシステムの概要を示す図である。
【発明を実施するための形態】
【００１０】
以下、この発明の実施の形態について、図面を参照しながら詳細に説明する。
実施の形態１．
図１は、この発明の実施の形態１におけるユーザ端末とサーバの構成を示すブロック図である。この実施の形態１では、ユーザ端末１０が、自動車等の車両の現在地と地図データとに基づいて、車両の現在地から目的地までのルート検索を行うナビゲーション装置として機能し、サーバ２０は、複数のユーザ端末１０と通信を行い、情報の送受信を行う。
【００１１】
ナビゲーション装置であるユーザ端末１０は、入力部１１、表示部１２、通信部１３、自車位置検出部１４、道路有効幅員検出部１５、記憶部１６、中央演算処理部１７を備えている。このユーザ端末１０は、自動車等の車両に搭載または持ち込んで設置されて使用されるものである。
【００１２】
入力部１１は、ユーザからの手動による入力を受け付けるものであり、ユーザ端末１０に設けられたハードウェアのスイッチ、キー、ボタンや、表示部１２と一体型のタッチセンサ、あるいは、ハンドルや等に設置されたリモコン等、いずれの形態のものであってもよい。
【００１３】
表示部１２は、例えばＬＣＤ（Ｌｉｑｕｉｄ  Ｃｒｙｓｔａｌ  Ｄｉｓｐｌａｙ）や有機ＥＬディスプレイなど、中央演算処理部１７からの指示を受けて、ユーザに情報を提示する。また、上述のように、表示一体型のタッチパネルであって、例えばＬＣＤとタッチセンサから構成されていてもよい。
【００１４】
通信部１３は、サーバ２０と通信を行い、情報の送受信を行う。
自車位置検出部１４は、例えばＧＰＳ（Ｇｌｏｂａｌ  Ｐｏｓｉｔｉｏｎｉｎｇ  Ｓｙｓｔｅｍ）等を用いて、自車の現在位置を検出する。
【００１５】
道路有効幅員検出部１５は、例えば図２に示すように、車両内の天井に設置されたカメラ１（例えばＣＣＤカメラ等）により、車両の前方を撮影して、現在通行している（走行中の）道路の有効幅員を検出する。
記憶部１６は、地図データ、自車の車幅情報、設定道幅情報、有効幅員データ、道幅コスト、および、有効幅員データと道幅コストとの対応表等、各種情報を記憶している。
【００１６】
中央演算処理部１７は、自車位置検出部１４により検出された自車位置と、記憶部１６に記憶されている地図データに基づいて、入力部１１を介して設定された目的地までのルート検索を行うとともに、道路有効幅員検出部１５からの信号によって有効幅員を計測し、記憶部１６に記憶されている情報を用いて、有効幅員データを道幅コストに換算して、検索したルート毎のコストを算出し、当該コストに基づいて、検索したルートのいずれかを最適なルートに決定してルート案内を行う。
【００１７】
また、こうして中央演算処理部１７で取得された有効幅員データを記憶部１６に記憶することにより、ユーザ端末１０内の有効幅員データを更新する。
そして、更新された有効幅員データを、通信部１３を介してサーバ２０に送信することによりアップロードする。
また、サーバ２０から最新の有効幅員データを取得して、自身の記憶部１６に記憶されている有効幅員データを更新する。
【００１８】
サーバ２０は、サーバ通信部２１、サーバ記憶部２２、サーバ中央演算処理部２３を備えている。
サーバ通信部２１は、複数のユーザ端末１０と通信を行い、情報の送受信を行う。
サーバ記憶部２２は、少なくとも地図データおよび有効幅員データを記憶している。
【００１９】
サーバ中央演算処理部２３は、サーバ通信部２１を介して複数のユーザ端末１０から受信した有効幅員データを取得して、サーバ記憶部２２の有効幅員データを更新するとともに、ユーザ端末１０からの要求に基づいて、サーバ記憶部２２に記憶されている最新の有効幅員データをユーザ端末１０に送信する。
【００２０】
図３は、ユーザ端末１０の記憶部１６に記憶されている、有効幅員データと道幅コストとの対応表の一例を示す表である。この表に示すα、β、γはそれぞれ、ユーザの道幅に関する好みにより予め設定される設定道幅情報であり、この実施の形態１では、α＝５０ｃｍ、β＝１００ｃｍ、γ＝１５０ｃｍが設定されているものとする。
すなわち、車両の車幅と、当該車両を利用するユーザの道幅に関する好みについては、予め設定されており、記憶部１６に記憶されている。
【００２１】
また、道幅コストについては、例えば特許文献１にも記載されているように、ナビゲーション装置におけるルート検索の際に利用される公知の技術であるので、ここでは詳しい説明を省略するが、通常、計算したコストの合計が最も小さいルートが最適なルートとして決定される。
【００２２】
そして、例えば図３に示すケース１において、「道幅コスト＝１０００」のように、突出して大きな道幅コストをかけた道路は、他に選択の余地がない場合を除き、最適なルートとして案内されることはない。
【００２３】
ケース１は、道幅が「車幅＋α」未満の場合には、その道は狭いから極力通行したくない、というユーザの好みを意味しており、各ユーザは、自らそのαの値を決めて設定すればよい。すなわち、例えばユーザが、車幅＋５０ｃｍ未満の道幅の場合には、狭いから極力通行したくない、と思っている場合、α＝５０ｃｍに設定すればよい。
【００２４】
ケース２は、道幅が「車幅＋α」以上、「車幅＋β」未満の場合には、道幅コストが「大」のものとして、そのコストを「１００」に設定したことを示している。
ケース３は、道幅が「車幅＋β」以上、「車幅＋γ」未満の場合には、道幅コストが「小」のものとして、そのコストを「５０」に設定したことを示している。
【００２５】
ケース４は、道幅が「車幅＋γ」以上の場合には、道幅コスト「なし」、すなわち、「道幅コスト＝０」に設定し、この道幅であれば、ルート検索の際に避ける必要がないことを意味している。すなわち、例えばユーザが、車幅＋１５０ｃｍ以上の道幅の場合には、広いから道幅コスト０（ゼロ）として問題ない、と思っている場合、γ＝１５０ｃｍに設定すればよい。
【００２６】
そして、ユーザ端末１０の中央演算処理部１７は、図３に示す対応表を参照して、車両の車幅とユーザの道幅に関する好み（α、β、γ）とに基づいて、有効幅員を道幅コストに換算する。
【００２７】
図４は、この実施の形態１におけるユーザ端末１０が有効幅員データを収集する処理を示すフローチャートである。
この処理は、ナビゲーション装置の電源がオフされたり、エンジンが停止されたりしない限り、常に行われている。ここでは、電源オフやエンジン停止等の終了命令がないものとして説明する。
【００２８】
まず、自車が、ルート検索の対象となりうる道を走行中か否かを判断する（ステップＳＴ１）。例えば、自車の現在位置が駐車場内である場合など（ステップＳＴ１のＮＯの場合）には、ルート探索の対象となりうる道に出るまでこの判断を繰り返す。ルート探索の対象となりうる道を走行中の場合（ステップＳＴ１のＹＥＳの場合）には、道路有効幅員検出部１５からの信号を用いて走行中の道路の有効幅員を計測する（ステップＳＴ２）。
【００２９】
そして、計測された有効幅員が、所定値（ここでは「車幅＋γ」とする）未満であるか否かを、中央演算処理部１７が判断する（ステップＳＴ３）。計測された有効幅員が、所定値（「車幅＋γ」）以上である場合（ステップＳＴ３のＮＯの場合）には、図３のケース４に示すとおり、道幅コストが０（ゼロ）であり、道幅を減少させるような問題は発生していないと判断できるので、ステップＳＴ１に戻って処理を行う。
【００３０】
一方、ステップＳＴ２で計測された有効幅員が、所定値（「車幅＋γ」）未満である場合（ステップＳＴ３のＹＥＳの場合）には、ユーザ端末１０内の記憶部１６に、その有効幅員データを記憶する（ステップＳＴ４）。
ここで、具体例を示して説明する。例えば、自車の車幅が１８０ｃｍであり、前述のとおり、α＝５０ｃｍ、β＝１００ｃｍ、γ＝１５０ｃｍに設定されているものとする。
【００３１】
そして、現在走行中の道路が、通常であれば（地図データによれば）有効幅員が５００ｃｍである場合、何も走行を妨げるような要因がない場合には、ステップＳＴ２において、カメラ１により撮影された映像により道路有効幅員検出部１５が計測した有効幅員も、５００ｃｍとなる。この場合、ステップＳＴ３の判断では、計測された有効幅員（５００ｃｍ）は、所定値（「車幅（１８０ｃｍ）＋γ（１５０ｃｍ）」）以上であるので（ステップＳＴ３のＮＯの場合）、ステップＳＴ１に戻る。
【００３２】
しかし、例えば駐車中の車両があり、ステップＳＴ２において計測された有効幅員が３００ｃｍであったとすると、その有効幅員（３００ｃｍ）は、所定値（「車幅（１８０ｃｍ）＋γ（１５０ｃｍ）」）未満であるので（ステップＳＴ３のＹＥＳの場合）、記憶部１６に、その道路に対して有効幅員データ（３００ｃｍ）を記憶する（ステップＳＴ４）。
【００３３】
その後、通信が可能な場合（ステップＳＴ５のＹＥＳの場合）には、ステップＳＴ４で記憶部１６に記憶した有効幅員データを、通信部１３を介して送信することによりサーバ２０にもアップロードする（ステップＳＴ６）。
【００３４】
なお、サーバ２０との通信が頻繁に行われ、通信負荷が上がり過ぎないようにするために、通信間隔（例えば、１０分毎など）が予め設定されていたり、通信可能な場所が通信ポイントとして予め設定されたりしているものとする。そして、ステップＳＴ５の判断の際に、前回の通信から１０分以上経過しているか、とか、通信ポイントを通過してから所定の距離以内にいるか、ということにより、通信可能か否かを判断する。
【００３５】
また、ステップＳＴ５において、通信が可能でないと判断された場合（ステップＳＴ５のＮＯの場合）には、ステップＳＴ１に戻って処理を行う。そして、通信が可能であると判断されたタイミングで（ステップＳＴ５のＹＥＳの場合）、アップロードされていなかった有効幅員データがまとめてサーバ２０にアップロードされる（ステップＳＴ６）。
【００３６】
図５は、この実施の形態１におけるユーザ端末１０が有効幅員データを利用してルート検索する処理を示すフローチャートである。
まず初めに、通信可能か否かを判断する（ステップＳＴ１１）。そして、通信可能である場合（ステップＳＴ１１のＹＥＳの場合）、通信部１３を介してサーバ２０より最新の有効幅員データを取得する（ステップＳＴ１２）。そして、取得した有効幅員データで、ユーザ端末１０の記憶部１６に記憶されている有効幅員データを更新する（ステップＳＴ１３）。
【００３７】
その後、通常のルート検索と同様に、有効幅員データを道幅コストに換算して、ルート検索を行う（ステップＳＴ１４）。なお、コスト計算や、コストの合計値が最小になるルートを最適なルートとするルート案内については、ここでは説明を省略する。
一方、通信可能でない場合（ステップＳＴ１１のＮＯの場合）には、ユーザ端末１０の記憶部１６に記憶されている有効幅員データを用いて、ルート検索が行われる。
【００３８】
サーバ２０から最新の有効幅員データを取得してルート検索を行う場合には、例えば目の前の車両が大型トラックである場合など、カメラ１で撮影された映像からは実際の道路有効幅員を検出できなかった場合であっても、他車が取得した有効幅員がアップロードされた最新結果を用いることができるので、より有効なルート検索、ルート案内を行うことができる。
そして、目的地に到着したり、ユーザによりルート案内終了の指示が行われたり、といった、ルート案内終了の条件を満たす場合（ステップＳＴ１５のＹＥＳの場合）には、処理を終了する。
【００３９】
一方、ルート案内終了の条件を満たしていない場合（ステップＳＴ１５のＮＯの場合）には、案内どおりのルートから外れるなど、ルート再検索の条件を満たす状態になるまでは（ステップＳＴ１６のＮＯの場合）、ルート案内終了の条件を満たすまでステップＳＴ１５およびＳＴ１６のチェックを繰り返す。
また、途中で案内ルートから外れるなど、ルート再検索の条件を満たす状態になった場合（ステップＳＴ１６のＹＥＳの場合）には、ステップＳＴ１１に戻って処理を行う。
【００４０】
以上のように、この実施の形態１によれば、多数のユーザが走行中に計測した道幅や、サーバから取得した道幅（有効幅員データ）に基づいて、道幅情報を更新することにより、実際に有効な道幅情報を用いることができるので、本当に快適に通行可能な道路をルートとして決定して案内することができ、より有効なルート検索およびルート案内を行うことができる。
【００４１】
なお、この実施の形態１では、ユーザ端末がナビゲーション機能を備え、ルート案内を行うものとして説明したが、サーバがナビゲーション機能を有し、ユーザ端末から少なくとも有効幅員データを受信し、さらにサーバが図３に示すような対応表を記憶しており、当該対応表に基づいて、ルート検索に使用する道路の有効幅員を道幅コストに換算して、検索したルート毎のコストを算出し、検索したルートのいずれかを最適なルートに決定して、ユーザ端末に対してルート案内を行うようにしてもよい。
【００４２】
実施の形態２．
図６は、この発明の実施の形態２におけるユーザ端末とサーバの構成を示すブロック図である。なお、実施の形態１で説明したものと同様の構成には、同一の符号を付して重複した説明を省略する。この実施の形態２においても、ユーザ端末１０が、自動車等の車両の現在地と地図データとに基づいて、車両の現在地から目的地までのルート検索を行うナビゲーション装置として機能し、サーバ３０は、複数のユーザ端末１０と通信を行い、情報の送受信を行うものであるが、以下に示す実施の形態２では、実施の形態１と比べると、サーバ３０が周辺情報取得部３１を備えている。
【００４３】
周辺情報取得部３１は、気象情報、工事情報、イベント情報、災害情報等の、周辺情報を取得する。
サーバ記憶部３２は、地図データ、有効幅員データに加え、周辺情報取得部３１が取得した気象情報、工事情報、イベント情報、災害情報等も記憶されている。
【００４４】
また、サーバ中央演算処理部３３は、サーバ通信部２１を介して複数のユーザ端末１０から受信した有効幅員データを取得して、サーバ記憶部３２の有効幅員データを更新するとともに、有効幅員を予測する。
【００４５】
この実施の形態２においても、ユーザ端末１０が有効幅員データを収集する処理については、実施の形態１における図４のフローチャートと同じ処理である。
図７は、この実施の形態２におけるサーバ３０が有効幅員を予測する処理を示すフローチャートである。
【００４６】
サーバ中央演算処理部３３は、通信部２１を介して複数のユーザ端末１０から取得した有効幅員データ（対向車、通行人、路上駐車、その他占拠物によって道幅が減少する場合も含めた道幅の実態）を、時刻、曜日、祝休日、季節などの条件や、気象、災害、工事、イベントの有無などの周辺状況の条件毎に分類して、平均値および標準偏差を算出する（ステップＳＴ２１）。
【００４７】
次に、ルート検索の条件（例えば、時刻Ａ、曜日Ｂ、季節Ｃ、気象Ｄ、・・・）における有効幅員の予測値を、下式のように、予め求めた各条件における有効幅員の平均値に重み係数をつけて平均をとることにより算出する（ステップＳＴ２２）。
【００４８】
「時刻Ａ、曜日Ｂ、季節Ｃ、気象Ｄ、・・・における有効幅員予測値」＝（「時刻Ａの平均値」×「時刻Ａの重み係数」＋「曜日Ｂの平均値」×「曜日Ｂの重み係数」＋「季節Ｃの平均値」×「季節Ｃの重み係数」＋「気象Ｄの平均値」×「気象Ｄの重み係数」＋・・・）／（「時刻Ａの重み係数」＋「曜日Ｂの重み係数」＋「季節Ｃの重み係数」＋「気象Ｄの重み係数」＋・・・）
ここで、各係数の重み係数とは、道路幅員にもたらす影響度が高い条件ほど大きくとるべき数値であり、経験等により決める。
【００４９】
そして、ルート検索の条件（例えば、時刻Ａ、曜日Ｂ、季節Ｃ、気象Ｄ、・・・）における有効幅員の偏差値を、下式のように、予め求めた各条件における標準偏差に重み係数をつけて平均をとることにより算出する（ステップＳＴ２３）。
「時刻Ａ、曜日Ｂ、季節Ｃ、気象Ｄ、・・・における有効幅員の偏差値」＝（「時刻Ａの標準偏差」×「時刻Ａの重み係数」＋「曜日Ｂの標準偏差」×「曜日Ｂの重み係数」＋「季節Ｃの標準偏差」×「季節Ｃの重み係数」＋「気象Ｄの標準偏差」×「気象Ｄの重み係数」＋・・・）／（「時刻Ａの重み係数」＋「曜日Ｂの重み係数」＋「季節Ｃの重み係数」＋「気象Ｄの重み係数」＋・・・）
【００５０】
この際、「偏差値」が大きいものについては、予測データの信頼度は低いと考えられるため、有効幅員予測データから道幅コストに換算する際には、偏差値の大きさを考慮して行うことが望ましい。
すなわち、偏差値から、有効幅員予測データの信頼度を求めることができる。ここでは図示や詳細な説明は省略するが、例えば、偏差値が０、１０、２０の場合、それぞれについて、信頼度は１００％、８０％、５０％、などといったように、予め偏差値と信頼度とを対応付けた表や関係式を設定しておき、その表や関係式に基づいて偏差値から信頼度を求めるようにすればよい。
【００５１】
図８は、予測データの信頼度が高い場合と低い場合を考慮した、有効幅員予測データと道幅コストとの対応表の一例を示す表である。この表に示すように、予測データの信頼度が高い場合、すなわち、偏差値が小さい場合には、道幅コストへの換算は図３に示す表と同じであるが、予測データの信頼度が低い場合、すなわち、偏差値が大きい場合には、ケース１の道幅コストのみ異なる値を採用する。
【００５２】
これは、偏差値が大きい場合、有効幅員予測データの信頼度が低いにもかかわらず、その道を利用しないように、不要な迂回ルートを案内してしまうため、そのようなことを防止するための措置である。
【００５３】
なお、偏差値が大きい／小さいとは、例えば偏差値が２０以上か２０未満か、など、ユーザの設定した値によって判断するようにすればよい。また、ここでは偏差値が大きい／小さい（信頼度：低／高）の２種類のみの場合分けとしたが、３種類以上に場合分けして道幅コストが細かく異なるようにしてもよいことは言う間でもない。
【００５４】
図９は、この実施の形態２におけるユーザ端末１０が有効幅員データを利用してルート検索する処理を示すフローチャートである。
ユーザ端末１０は、通信部１３を介してサーバ３０から、およその通過予定時刻における有効幅員予測データを取得する（ステップＳＴ３１）。この際、予測データの信頼度についても同時に取得するものとする。
【００５５】
次に、取得した有効幅員予測データを、信頼度に基づいて道幅コストに換算して、ルート検索を行う（ステップＳＴ３２）。
そして、目的地に到着したり、ユーザによりルート案内終了の指示が行われたり、といった、ルート案内終了の条件を満たす場合（ステップＳＴ３３のＹＥＳの場合）には、処理を終了する。
【００５６】
一方、ルート案内終了の条件を満たしていない場合（ステップＳＴ３３のＮＯの場合）には、案内どおりのルートから外れるなど、ルート再検索の条件を満たす状態になるまでは（ステップＳＴ３４のＮＯの場合）、ルート案内終了の条件を満たすまでステップＳＴ３３およびＳＴ３４のチェックを繰り返す。
また、途中で案内ルートから外れるなど、ルート再検索の条件を満たす状態になった場合（ステップＳＴ３４のＹＥＳの場合）には、ステップＳＴ３１に戻って処理を行う。
【００５７】
以上のように、この実施の形態２によれば、実施の形態１における効果に加えて、日時情報および周辺情報も考慮した道幅情報を用いることができるので、より有効なルート検索およびルート案内を行うことができる。
【００５８】
なお、この実施の形態２においても、実施の形態１同様、ユーザ端末がナビゲーション機能を備え、ルート案内を行うものとして説明したが、サーバがナビゲーション機能を有し、ユーザ端末から少なくとも有効幅員データを受信し、さらにサーバが図８に示すような対応表を記憶しており、当該対応表に基づいて、ルート検索に使用する道路の有効幅員を道幅コストに換算して、検索したルート毎のコストを算出し、検索したルートのいずれかを最適なルートに決定して、ユーザ端末に対してルート案内を行うようにしてもよい。
【００５９】
実施の形態３．
この発明の実施の形態３におけるユーザ端末とサーバの構成としては、実施の形態２における図６のブロック図と同じであるため、図示を省略するが、以下に示す実施の形態３では、実施の形態１，２と比べると、サーバ３０がナビゲーション機能を備える。すなわち、図３や図８に示すような、有効幅員データと道幅コストとの対応表についても、ユーザ端末１０の記憶部１６ではなく、サーバ記憶部３２が記憶しており、サーバ中央演算処理部３３が、道幅コスト換算やルート検索も行う。
【００６０】
この実施の形態３においても、サーバ３０が有効幅員を予測する処理については、実施の形態２における図７のフローチャートと同じ処理である。
また、予測データの信頼度が高い場合と低い場合を考慮した、有効幅員予測データと道幅コストとの対応表についても、実施の形態２における図８に示した一例と同じ表を用いるものとする。
【００６１】
図１０は、この実施の形態３におけるサーバ３０が有効幅員データを利用してルート検索するとともにユーザ端末１０へ通知を行う処理を示すフローチャートである。
まず、図７に示すフローチャートのステップＳＴ２３において決定した有効幅員予測データを、信頼度に基づいて道幅コストに換算して、ルート検索を行い（ステップＳＴ４１）、最適なルートをユーザ端末１０へ通知する（ステップＳＴ４２）。
【００６２】
そして、目的地に到着したり、ユーザによりルート案内終了の指示が行われたり、といった、ルート案内終了の条件を満たす場合（ステップＳＴ４３のＹＥＳの場合）には、処理を終了する。
一方、ルート案内終了の条件を満たしていない場合（ステップＳＴ４３のＮＯの場合）には、有効幅員予測データまたは信頼度に変更があるか否かを判定する（ステップＳＴ４４）。
【００６３】
このステップＳＴ４４の判定を行うのは、天候の変化により気象情報が変わったり、渋滞等により通過予定時刻が変わったり、また、サーバ３０は複数のユーザ端末１０からデータを受け取ることが可能であるため、最新のデータが変更されるなど、有効幅員予測データや信頼度が途中で変更される可能性があるからである。
【００６４】
そして、これらのデータに変更がない場合（ステップＳＴ４４のＮＯの場合）には、ステップＳＴ４３およびＳＴ４４のチェックを繰り返す。
一方、有効幅員予測データまたは信頼度に変更があった場合（ステップＳＴ４４のＹＥＳの場合）には、再度、有効幅員予測データを信頼度に基づいて道幅コストに換算して、ルート検索を行う（ステップＳＴ４５）。
【００６５】
ここで、ユーザ端末１０に対して、ステップＳＴ４２で通知済みのルートと、ステップＳＴ４５において新たに検索されたルートが、一定時間内にユーザが通過予定の地点で分岐するか否かを判断する（ステップＳＴ４６）。これは、状況の変化により最適なルートが変わったからといって、すぐに通知するのではなく、ある程度ユーザの車両がその分岐点に近づいてから通知するためである。
【００６６】
そして、一定時間内にユーザが通過予定の地点で分岐すると判断された場合（ステップＳＴ４６のＹＥＳの場合）には、新ルートをユーザ端末１０に通知する（ステップＳＴ４７）。
そして再び、目的地に到着したり、ユーザによりルート案内終了の指示が行われたり、といった、ルート案内終了の条件を満たすか否かを判断し（ステップＳＴ４８）、ルート案内終了の条件を満たす場合（ステップＳＴ４８のＹＥＳの場合）には、処理を終了する。
【００６７】
一方、ルート案内終了の条件を満たしていない場合（ステップＳＴ４８のＮＯの場合）には、有効幅員予測データまたは信頼度に変更があるか否かを判定し、それらのデータに変更がない場合（ステップＳＴ４９のＮＯの場合）には、ステップＳＴ４６〜ＳＴ４８のチェックおよび処理を繰り返す。
【００６８】
また、有効幅員予測データまたは信頼度に変更があった場合（ステップＳＴ４９のＹＥＳの場合）には、ステップＳＴ４５の処理に戻って、再度、ステップＳＴ４５以降の処理を繰り返す。
なお、ステップＳＴ４６において、一定時間内にはユーザが通過予定の地点で分岐しないと判断された場合（ステップＳＴ４６のＮＯの場合）には、ステップＳＴ４７の処理を行わずにステップＳＴ４８の判断を行う。
【００６９】
以上のように、この実施の形態３によれば、有効幅員予測データまたは信頼度が更新される度にルート検索を行い、車両が一定時間内に通過予定の分岐点においてルート変更がある場合に限り、ルートを提示し直す（ユーザ端末に対してルート案内を行う）ので、実施の形態１，２における効果に加えて、よりリアルタイムに有効なルート検索およびルート案内を行うことができる。
【００７０】
実施の形態４．
以上の実施の形態１〜３では、この発明におけるユーザ端末またはサーバが、車両のナビゲーション機能を有するものとして説明したが、スマートフォン、タブレットＰＣ、携帯電話等の携帯情報端末等にインストールされるナビゲーション機能や道幅情報更新機能のアプリケーション等に適用したり、携帯情報端末等とサーバとが連携してナビゲーション機能や道幅情報更新機能のアプリケーションを実行する場合にも適用することができる。
【００７１】
図１１は、この発明の実施の形態４におけるナビゲーションシステムの概要を示す図である。このナビゲーションシステムは、ユーザ端末１００が、スマートフォンなどの携帯情報端末１０１およびサーバ１０２の少なくとも一方と連携してナビゲーション処理を行ったり、スマートフォンなどの携帯情報端末１０１およびサーバ１０２の少なくとも一方がナビゲーション処理を行い、ユーザ端末１００にルート案内を提示させる等、様々な形態をとることができる。以下、当該ナビゲーションシステムの構成態様について説明する。
【００７２】
実施の形態１〜３では、この発明のナビゲーション機能を、ユーザ端末１０またはサーバ２０，３０がすべて備えるものとして説明したが、この実施の形態４におけるナビゲーションシステムでは、サーバ１０２がナビゲーション処理を行い、そのルート検索結果を携帯情報端末１０１を介してユーザ端末１００に提示させることによりユーザに提供する場合、および、携帯情報端末１０１がサーバ１０２と連携してナビゲーション処理を行い、そのルート検索結果をユーザ端末１００に提示させることによりユーザに提供する場合について説明する。
【００７３】
まず、サーバ１０２がナビゲーション処理を行い、そのルート検索結果を携帯情報端末１０１を介してユーザ端末１００に提示させる場合について説明する。
この構成においては、ユーザ端末１００が携帯情報端末１０１を経由してサーバ１０２と通信する場合が考えられる。サーバ１０２は、上記実施の形態１〜３で説明したナビゲーション装置として機能する。また、ユーザ端末１００は、携帯情報端末１０１とサーバ１０２によるルート検索結果をユーザに提供するための出力部（表示部）を少なくとも備える出力装置（表示装置）として機能する。
【００７４】
この場合、ユーザ端末１００は基本的に通信機能および出力機能（表示機能）のみを有し、サーバ１０２によるルート検索結果を受信してユーザに提供する。
すなわち、サーバ１０２がナビゲーション装置であり、このナビゲーション装置であるサーバ１０２が、ユーザにより入力された目的地に基づいたルート検索結果をユーザ端末１００に提示させる。
このように構成しても、実施の形態１〜３と同様な効果を得ることができる。
【００７５】
また、携帯情報端末１０１がサーバ１０２と連携してナビゲーション処理を行い、そのルート検索結果をユーザ端末１００がユーザに提供する場合について説明する。
この構成においても、ユーザ端末１００が携帯情報端末１０１を経由してサーバ１０２と通信する場合が考えられ、携帯情報端末１０１のアプリケーションが、サーバ１０２と連携してナビゲーション処理を行う。また、ユーザ端末１００は、携帯情報端末１０１とサーバ１０２によるルート検索結果をユーザに提供するための出力部（表示部）を少なくとも備える出力装置（表示装置）として機能する。
【００７６】
この場合にも、ユーザ端末１００は基本的に通信機能および出力機能（表示機能）のみを有し、携帯情報端末１０１とサーバ１０２との連携によるルート検索結果を受信してユーザに提供する。
すなわち、携帯情報端末１０１のアプリケーションにより、ユーザにより入力された目的地に基づいたルート検索結果を出力装置（表示装置）であるユーザ端末１００に提示させる。
このように構成しても、実施の形態１〜３と同様な効果を得ることができる。
【００７７】
なお、上記の実施の形態１〜４では、車両の前方を撮影するＣＣＤカメラ等により道路有効幅員を検出するものとして説明したが、車両の後方を撮影するバックカメラを備えている車は多いので、そのバックカメラ映像も用いるようにしてもよい。バックカメラ映像においては、高い位置にある被写体も遠くの地面も画面上部に写る。そのため、静止画面では、画面上の位置だけでは被写体が存在する高さを知ることができない。
【００７８】
しかし、例えば車両が前進している場合、すべての被写体（被写体自身は静止しているとする）は遠近法における消失点へ向かって移動する動画となり、それらが画面上を移動する速さは、被写体が存在している高さにより異なる。
【００７９】
これを応用し、画面両端から消失点へ向かって移動してく映像が、自車が通ってきた平面と同じ高さで両道路端に平面が続いている場合に想定される動きと異なる動きをしたことを検知することで、自車の右後方または左後方に、自車が通ってきた平面と異なる高さに構造物が存在することを知ることができる。また、この方法によれば、自車の右後方または左後方に、すれ違った車両等の移動体が進入してきたことも検知可能である。
【００８０】
このように、バックカメラ映像も用いるようにすれば、より詳細な道幅情報を取得することができるので、より有効なルート検索およびルート案内を行うことができる。
【００８１】
なお、本願発明はその発明の範囲内において、各実施の形態の自由な組み合わせ、あるいは各実施の形態の任意の構成要素の変形、もしくは各実施の形態において任意の構成要素の省略が可能である。
【符号の説明】
【００８２】
１  カメラ、１０，１００  ユーザ端末、１１  入力部、１２  表示部、１３  通信部、１４  自車位置検出部、１５  道路有効幅員検出部、１６  記憶部、１７  中央演算処理部、２０，３０，１０２  サーバ、２１  サーバ通信部、２２，３２  サーバ記憶部、２３，３３  サーバ中央演算処理部、３１  周辺情報取得部、１０１  携帯情報端末。
【図１】
2014202560.tif 000003
【図２】
2014202560.tif 000004
【図３】
2014202560.tif 000005
【図４】
2014202560.tif 000006
【図５】
2014202560.tif 000007
【図６】
2014202560.tif 000008
【図７】
2014202560.tif 000009
【図８】
2014202560.tif 000010
【図９】
2014202560.tif 000011
【図１０】
2014202560.tif 000012
【図１１】
2014202560.tif 000013