JP2021148476A - 案内装置、ナビゲーションシステム、および、案内プログラム - Google Patents

Abstract

【課題】経路案内のために参照されるユーザの生活圏情報を、高精度に求めること。【解決手段】案内装置２は、ユーザが使用する車両についての生活圏の初期位置情報を取得して生活圏経路ＤＢ２３に登録する登録受付部２１と、登録受付部２１が初期位置情報を登録した後の所定期間内における車両の行動実績を取得し、その行動実績を初期位置情報に反映させることにより生活圏の推定範囲を求める行動範囲推定部２２と、を有する。行動範囲推定部２２は、車両の現在地の位置データを時系列に記録した位置履歴データを車両の行動実績として取得し、位置履歴データの各位置データを包含しつつ、範囲がなるべく小さくなるような生活圏の推定範囲を求める。【選択図】 図１

Description

本発明は、案内装置、ナビゲーションシステム、および、案内プログラムに関わる。

現在地から目的地までの経路を案内するカーナビゲーションシステムが普及している。ドライバは、現在地および目的地に加え、最短距離で到着したい旨や、通行料金を安く済ませたい旨などの各種の付加条件を入力することで、各ドライバに合った経路が検索される。

さらに、特許文献１には、車両通行止めなど一般には通行できない道路であっても、その付近に居住している居住者は通行可能であるときには、その居住者に限りその道路を案内する経路探索装置が記載されている。

国際公開第２００６／０６２００４号

特許文献１などのように、特定のユーザだけに特別な道路を案内する場合、どのユーザにどの道路を案内するかという情報の開示範囲を定義することが重要となる。特許文献１では、「通行が許可されている居住者」という許可情報を根拠とした明確な定義がなされている。

一方、許可情報に限らず、居住者の生活圏という範囲情報に基づいて、特別な道路を案内する場合を検討する。例えば、先月うちの地域に転入してきたユーザＡにだけ、地元の人が使う農道や私道などの生活道路を使わせてもよい、などの要望がある。
しかし、生活圏は転入してきた居住者が実際にしばらく生活してから判明するものである。例えば、ユーザＡがＸ市に転入してきたからといって、そのままＸ市全体を生活圏としてしまうと、精度が低くなる場合がある。ユーザＡがＸ市東部の自宅から、Ｙ市内の会社に車で出勤する場合、ユーザＡが使用しないＸ市の西部が生活圏に含まれてしまったり、ユーザＡが毎日出勤するＹ市内が生活圏から除外されてしまったりする。

そこで、本発明は、経路案内のために参照されるユーザの生活圏情報を、高精度に求めることを、主な課題とする。

前記課題を解決するために、本発明の案内装置は、以下の特徴を有する。
本発明は、ユーザが使用する車両についての生活圏の初期位置情報を取得して生活圏データベースに登録する登録受付部と、
前記登録受付部が前記初期位置情報を登録した後の所定期間内における車両の行動実績を取得し、その行動実績を前記初期位置情報に反映させることにより生活圏の推定範囲を求める行動範囲推定部と、を有することを特徴とする。
その他の手段は、後記する。

本発明によれば、経路案内のために参照されるユーザの生活圏情報を、高精度に求めることができる。

本発明の一実施形態に関するナビゲーションシステムの構成図である。 本発明の一実施形態に関する車載装置の動作を示すフローチャートである。 本発明の一実施形態に関する行動範囲推定部の処理を示す説明図である。 本発明の一実施形態に関する一般ルートの一例を示す平面図である。 本発明の一実施形態に関する図４と同じ地図上の生活者利用ルートの一例を示す平面図である。 本発明の一実施形態に関するユーザごとの生活圏を示す平面図である。 本発明の一実施形態に関する図６の生活圏を考慮した案内部の案内内容を示すテーブルである。 本発明の一実施形態に関する図７とは別の案内内容を示すテーブルである。

以下、本実施形態について図面を参照して詳細に説明する。

図１は、ナビゲーションシステムの構成図である。
ナビゲーションシステムは、車載装置１と、案内装置２とがネットワークで接続されて構成される。なお、車載装置１と案内装置２とは、別々の筐体としてもよいし、車載装置１の内部に案内装置２の機能を組み込んでもよい。
車載装置１および案内装置２は、それぞれＣＰＵ（Central Processing Unit）と、メモリと、ハードディスクなどの記憶手段（記憶部）と、ネットワークインタフェースとを有するコンピュータとして構成される。
このコンピュータは、ＣＰＵが、メモリ上に読み込んだプログラム（アプリケーションや、その略のアプリとも呼ばれる）を実行することにより、各処理部により構成される制御部（制御手段）を動作させる。

車載装置１は、各ユーザの車両に搭載されるカーナビゲーション端末などである。車載装置１は、ユーザ登録部１１と、行動実績格納部１２と、車両制御部１３と、入力部１４と、表示部１６とを有する。
案内装置２は、自動車メーカなどが会員に交通案内を提供する交通情報サービスのサーバである。例えば、本出願人は、自車のユーザなどを対象として、インターナビ（Internavi、登録商標）という交通情報サービスを提供している。
案内装置２は、登録受付部２１と、行動範囲推定部２２と、生活圏経路ＤＢ２３と、検索受付部２４と、一般経路ＤＢ２５と、案内部２６とを有する。

以下、図１の各構成要素について、図２のフローチャートに沿って説明する。
図２は、車載装置１の動作を示すフローチャートである。
まず、ユーザ登録（Ｓ１１）について説明する。車載装置１のユーザ登録部１１は、ユーザの登録用情報の入力を受け、その登録用情報を登録受付部２１に送信する。登録用情報は、各ユーザを区別するためユーザ識別情報と、各ユーザの生活圏の初期位置情報とを含める。ユーザ識別情報は、例えば、ユーザＩＤ単体でもよいし、ユーザ名、車両種別、ユーザの個人情報などを一緒に登録しても良い。
また、生活圏の初期位置情報とは、以下の（１）または（２）である。
（１）地図上の１箇所を示す座標情報。例えば、以下の座標情報。
・自車の居住地（駐車場の住所）などの住所の座標情報
・自車の位置情報が所定の期間（例えば数日）以上移動せずに位置している座標の座標情報
・所定の時間帯（昼間、夜間）に所定の期間にわたって（例えば数日、数週間以上）位置している際の座標情報
（２）地図上の領域を示す推定範囲情報。例えば、地図上でユーザから範囲選択された生活圏の推定範囲情報。
そして、登録受付部２１は、受信した登録用情報をもとに、生活圏経路ＤＢ２３に新規ユーザの登録を行う。

次に、生活圏の行動実績を蓄積する処理（Ｓ１２）を説明する。
車両制御部１３は、自車の運転実績を行動実績格納部１２に蓄積する。運転実績は、例えば、ＧＰＳ（Global Positioning System, Global Positioning Satellite）により取得した現在地の位置データを時系列に記録した位置履歴データである。
または、車両制御部１３は、カーナビゲーションシステムの検索履歴データ（現在地と目的地との組み合わせデータ）を、行動実績格納部１２に蓄積してもよい。つまり、本実施形態では、実際に行動した運転実績だけでなく、行動を予定した検索履歴を「行動実績」に含める。

行動範囲推定部２２は、行動実績格納部１２から新規ユーザの運転実績を受信すると、その運転実績と、Ｓ１１で登録された登録用情報とから、新規ユーザの生活圏（行動範囲）を推定する（詳細は図３）。生活圏を推定可能な程度の運転実績の分量としては、例えば、２週間分のデータである。推定の結果は、生活圏経路ＤＢ２３に書き出される。
以上のＳ１１およびＳ１２が、経路検索の前準備となる処理である。

そして、経路の検索を要求する処理（Ｓ１３）を説明する。
入力部１４は、目的地を含む経路の検索条件の入力をドライバから受け付ける。登録受付部２１は、入力部１４から通知された検索条件に現在地を追加し、案内部２６に対して検索条件に適合する経路の検索を指示する。

ここで、案内部２６は、検索条件に含まれる車載装置１（車両）の現在地が、その車両のドライバにとっての生活圏内か否かを判定する（Ｓ２１）。この判定には、生活圏経路ＤＢ２３から読み込んだ、行動範囲推定部２２による生活圏の推定範囲情報が参照される。Ｓ２１でYesならＳ２３に進み、NoならＳ２２に進む。

Ｓ２２では、案内部２６は、一般経路ＤＢ２５を参照して、検索条件に適合する経路が現在混雑中か否かを判定する。なお、一般経路ＤＢ２５とは、一般の（不特定多数の）ドライバが利用可能な道路交通情報通信システム（VICS：Vehicle Information and Communication System、登録商標）が提供する情報を格納するデータベースであり、例えば、道路ごとの渋滞情報、工事情報などが格納される。Ｓ２２でYesならＳ２４に進み、NoならＳ２３に進む。
なお、Ｓ２２の判定処理を省略し、案内部２６は、Ｓ２１でYesならＳ２３に進み、NoならＳ２４に進むように制御してもよい。

Ｓ２３では、案内部２６は、Ｓ１３の検索要求に対する検索結果として、生活圏経路ＤＢ２３から読み取った生活者利用ルートを、車載装置１の表示部１６を介してドライバに案内させる。
ここで、「生活者利用ルート」とは、生活圏内での運転実績が豊富な地元のドライバ（生活ドライバ）が、渋滞回避のために使う利用頻度の高い抜け道などのあまり知られていないルートである。なお、Ｓ１２で説明した運転実績の蓄積処理と同様に、生活者利用ルートも生活圏経路ＤＢ２３に格納される生活ドライバの運転実績から求めることができる。換言すると、生活圏経路ＤＢ２３には、ドライバごとに、生活圏の推定範囲情報に加えて、その生活圏内の生活者利用ルートが対応づけられている。または、生活ドライバから生活者利用ルートを入力させ、その生活者利用ルートを生活圏経路ＤＢ２３に登録してもよい。
これにより、検索要求したドライバ（生活圏内に最近転入してきた転入ドライバ）は、生活者利用ルートを知ることで、円滑な運転を実現できる。

Ｓ２４では、案内部２６は、Ｓ１３の検索要求に対する検索結果として、一般経路ＤＢ２５から読み取った一般ルートを、車載装置１の表示部１６を介してドライバに案内させる。
ここで、「一般ルート」とは、一般のドライバが利用可能なルートである。一般のドライバには、現在地を生活圏としておらず、たまたま遠出したドライバ（遠出ドライバ）も含まれる。なお、生活者利用ルートと一般ルートとが偶然に重複する場合は、案内部２６は、生活者利用ルートを除外した（または重複区間をなるべく小さくした）ルートをＳ２４で案内する。

これにより、遠出ドライバは、生活者利用ルートを走行しないことで、現在地を生活圏とする地元の住民（生活ドライバ、転入ドライバ）に対して、日常生活の運転を邪魔しないように、無意識的に気を使うことができる。つまり、生活者利用ルートを知らせるドライバを絞り込むことにより、道路全体として交通量が適度に分散されたスムーズな案内を実現できる。
以上、図１および図２を参照して、ナビゲーションシステムの概要を説明した。以下、図３からは各処理の詳細を説明する。

図３は、行動範囲推定部２２の処理（Ｓ１２）を示す説明図である。図３の上から順に、状態１０１→状態１０２→状態１０３の順に時間が経過する。
状態１０１は、Ｓ１１のユーザ登録が行われた時点を示す。登録受付部２１は、新規ユーザから登録用情報として市Ａ１１内の右側（東側）に位置する住所Ｘに転入してきたことを受ける。登録受付部２１は、その市Ａ１１全体を生活圏の初期範囲Ａ１３として生活圏経路ＤＢ２３に登録する。

状態１０２は、Ｓ１２の行動実績が蓄積された時点を示し、例えば、状態１０１から２週間後である。行動範囲推定部２２は、住所Ｘよりも右側（東側）に位置する会社ＹへのルートＲ２１と、住所Ｘよりもやや左側（西側）に位置する商店ＺへのルートＲ２２とを、利用頻度の高い運転実績のルートとして取得する。なお、会社Ｙは市Ａ１１に隣接する市Ａ１２（別の市）である。
状態１０３は、行動範囲推定部２２が、ルートＲ２１、Ｒ２２を包含しつつ、範囲がなるべく小さくなるように、生活圏の初期範囲Ａ１３を生活圏の推定範囲Ａ１４に修正したものである。この修正では、生活圏の初期範囲Ａ１３から市Ａ１２の左側（西側）が加わり、市Ａ１１の左側（西側）が除外される。

なお、行動範囲推定部２２は、生活圏の初期位置情報を含むように新規ユーザの生活圏（行動範囲）を新規に推定してもよいし、与えられた新規ユーザの生活圏の初期範囲情報を修正してよい。このように、新規ユーザの運転実績（ルートＲ２１、Ｒ２２）を生活圏に反映させる処理は、以下のように具体化される。
（１）所在頻度が高い地点及びルートを全て包含するように、各地点を頂点とした多角形によって推定範囲を求める。
（２）所在頻度が高い地点及びルートを全て包含するような円形によって推定範囲を求める。
（３）所在頻度が高い各地点のうち東西に最も突出した地点間の距離と南北に最も突出した地点間の距離を長辺短辺の長さとした四角形により推定範囲を求める。

図４は、現在地Ｘから目的地Ｙまでの検索要求に対して、Ｓ２４で案内される一般ルートの一例を示す平面図である。この地図上で、基幹道路Ｘ１１，Ｘ１４，Ｙ１１は道路幅が広めの実線で図示し、生活道路Ｘ１２，Ｘ１３，Ｙ１２，Ｙ１３は道路幅が細めの破線で図示する。
案内部２６は、基幹道路Ｘ１１→Ｙ１１を通過する一般ルートＲ２３を遠出ドライバに案内する。この一般ルートＲ２３は、なるべく基幹道路を通過するように、かつ、なるべく交差点での右左折の回数が少なくなるようにして選択された。しかし、この一般ルートＲ２３は、混んでいることが多い。

図５は、図４と同じ地図上の現在地Ｘから目的地Ｙまでの検索要求に対して、Ｓ２３で案内される生活者利用ルートの一例を示す平面図である。
案内部２６は、基幹道路Ｘ１１→生活道路Ｙ１３→Ｘ１３→Ｙ１２→基幹道路Ｘ１４→Ｙ１１を通過する生活者利用ルートＲ２１を転入ドライバに案内する。この生活者利用ルートＲ２１は、交差点での右左折の回数が多いものの、一般ルートＲ２３との重複区間が少ないので、道路は空いており便利である。
なお、案内部２６は、現在地から目的地までの経路として、生活ドライバの運転実績に存在している場合には、そのうちの最も頻度が高く利用する道路を生活者利用ルートとして求めることが望ましい。

以下、図６〜図８は、同じ地域（市Ａ３１）でも、ユーザごとに案内するルートが異なることを示す説明図である。
図６は、ユーザごとの生活圏を示す平面図である。以下のドライバごとの情報が、生活圏経路ＤＢ２３に登録されている。
・ユーザＩＤ「Ｕ１」の生活ドライバは、市Ａ３１全体を生活圏とし、地点Ａ→地点Ｂの生活者利用ルートＲ３１と、地点Ａ→地点Ｃの生活者利用ルートＲ３２と、地点Ｄ→地点Ｃの生活者利用ルートＲ３３とを頻繁に使用している。
・ユーザＩＤ「Ｕ２」のドライバは、市Ａ３１左側（東側）を生活圏Ａ３２とする。
・ユーザＩＤ「Ｕ３」のドライバは、市Ａ３１右側（西側）を生活圏Ａ３３とする。
・ユーザＩＤ「Ｕ４」のドライバは、市Ａ３１の外側を生活圏Ａ３４とする。

図７は、図６の生活圏を考慮した案内部２６の案内内容を示すテーブルである。このテーブルの第１列（ユーザ）および第２列（生活圏）の組み合わせは、図６で示したとおりである。
テーブルの第３列（生活者利用ルートＲ３１）〜第５列（生活者利用ルートＲ３３）は、各ルートをドライバに案内するか否か（除外するか）を示す。第１行のユーザＩＤ「Ｕ１」の生活ドライバは、生活者利用ルートＲ３１〜Ｒ３３を頻繁に利用しており、案内される側ではない。

第２行のユーザＩＤ「Ｕ２」のドライバに着目すると、その生活圏Ａ３２には、地点Ａ→Ｂの生活者利用ルートＲ３１の全部と、地点Ａ→Ｃの生活者利用ルートＲ３２の一部が含まれている。
図７では、案内部２６は、現在地から目的地までの生活者利用ルートの全部が検索したユーザの生活圏に含まれている場合、その生活者利用ルートをユーザに案内することとする。よって、ユーザＩＤ「Ｕ２」の転入ドライバに対して案内される生活者利用ルートは「Ｒ３１」だけとなり、残りのルート「Ｒ３２，Ｒ３３」は案内から除外される。
同様に、案内部２６は、ユーザＩＤ「Ｕ３」のドライバに生活者利用ルートＲ３３を案内する。これにより、生活圏外のドライバに対しては生活者利用ルートが案内されないので、生活圏内の生活ドライバの生活に支障が出ないようにできる。

図８は、図７とは別の案内内容を示すテーブルである。
図８では、案内部２６は、現在地から目的地までの生活者利用ルートの一部が検索したユーザの生活圏に含まれている場合、その生活者利用ルートをユーザに案内することとする。
よって、図７と比較すると、ユーザＩＤ「Ｕ２」のドライバに案内される生活者利用ルートにＲ３２が加わる。同様に、ユーザＩＤ「Ｕ３」のドライバに案内される生活者利用ルートにＲ３２が加わる。

以上説明した本実施形態では、行動範囲推定部２２が車載装置１から通知される運転実績に基づき、生活圏の推定範囲情報を修正してから生活圏経路ＤＢ２３に格納する。これにより、生活圏をベースとした経路案内の精度も向上する。
さらに、案内部２６は、現在地を生活圏とする転入ドライバには生活者利用ルートを案内しつつ、現在地を生活圏としない遠出ドライバには一般ルートを案内する。これにより、転入ドライバには便利な道を提供しつつ、その便利な道を過剰に案内しないことで、生活ドライバに迷惑をかけずに済む。

１ 車載装置
２ 案内装置
１１ ユーザ登録部
１２ 行動実績格納部
１３ 車両制御部
１４ 入力部
１６ 表示部
２１ 登録受付部
２２ 行動範囲推定部
２３ 生活圏経路ＤＢ（生活圏データベース）
２４ 検索受付部
２５ 一般経路ＤＢ（一般データベース）
２６ 案内部

Claims (8)

1. ユーザが使用する車両についての生活圏の初期位置情報を取得して生活圏データベースに登録する登録受付部と、
   前記登録受付部が前記初期位置情報を登録した後の所定期間内における車両の行動実績を取得し、その行動実績を前記初期位置情報に反映させることにより生活圏の推定範囲を求める行動範囲推定部と、を有することを特徴とする
   案内装置。
2. 前記行動範囲推定部は、車両の現在地の位置データを時系列に記録した位置履歴データを車両の行動実績として取得し、位置履歴データの各位置データを包含しつつ、範囲がなるべく小さくなるような生活圏の推定範囲を求めることを特徴とする
   請求項１に記載の案内装置。
3. 第１ユーザの現在地および目的地を含む経路の検索要求を受け付ける検索受付部と、
   前記生活圏データベースを参照して、前記第１ユーザの現在地が前記第１ユーザの生活圏の推定範囲に含まれるか否かの生活圏判定処理を行い、
   前記生活圏判定処理により生活圏内であると判定した場合、検索要求された経路の一部を生活圏内とする第２ユーザの行動実績から、現在地から目的地までの経路を生活者利用ルートとして求め、その生活者利用ルートを前記第１ユーザに案内する処理を行う案内部と、を有することを特徴とする
   請求項１に記載の案内装置。
4. 前記案内部は、前記第２ユーザの行動実績から、現在地から目的地までの経路が前記第２ユーザの行動実績に複数存在している場合には、そのうちの最も頻度が高く利用する道路を前記生活者利用ルートとして求めることを特徴とする
   請求項３に記載の案内装置。
5. 前記案内部は、前記生活圏判定処理により生活圏外であると判定した場合、前記生活圏データベースとは別の不特定のユーザに利用可能な一般データベースから求めた一般ルートを、前記第１ユーザに案内することを特徴とする
   請求項３に記載の案内装置。
6. 前記案内部は、前記生活圏判定処理により生活圏外であると判定した場合、かつ、前記一般ルートおよび前記生活者利用ルートの重複区間が混雑している場合には、前記第１ユーザに案内する前記一般ルートから前記生活者利用ルートとの重複区間を除外することを特徴とする
   請求項５に記載の案内装置。
7. ユーザが使用する車両についての生活圏の初期位置情報を取得して生活圏データベースに登録する登録受付部と、
   前記登録受付部が前記初期位置情報を登録した後の所定期間内における車両の行動実績を取得し、その行動実績を前記初期位置情報に反映させることにより生活圏の推定範囲を求める行動範囲推定部と、を有する案内装置と、
   ユーザが使用する車両に搭載され、前記初期位置情報および車両の行動実績を前記案内装置に通知する車載装置と、を有することを特徴とする
   ナビゲーションシステム。
8. コンピュータを、
   ユーザが使用する車両についての生活圏の初期位置情報を取得して生活圏データベースに登録する登録受付部と、
   前記登録受付部が前記初期位置情報を登録した後の所定期間内における車両の行動実績を取得し、その行動実績を前記初期位置情報に反映させることにより生活圏の推定範囲を求める行動範囲推定部として機能させるための
   案内プログラム。

Images