(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公開特許公報(A)
(11)【公開番号】P2023153241
(43)【公開日】2023-10-17
(54)【発明の名称】情報処理装置、情報処理方法、およびプログラム
(51)【国際特許分類】
G01C 21/34 20060101AFI20231005BHJP
G08G 1/0968 20060101ALI20231005BHJP
G06Q 30/0202 20230101ALI20231005BHJP
【FI】
G01C21/34
G08G1/0968
G06Q30/0202
【審査請求】有
【請求項の数】18
【出願形態】OL
(21)【出願番号】P 2023131185
(22)【出願日】2023-08-10
(62)【分割の表示】P 2020523626の分割
【原出願日】2019-05-24
(31)【優先権主張番号】P 2018110262
(32)【優先日】2018-06-08
(33)【優先権主張国・地域又は機関】JP
(31)【優先権主張番号】P 2018146503
(32)【優先日】2018-08-03
(33)【優先権主張国・地域又は機関】JP
(31)【優先権主張番号】P 2019007599
(32)【優先日】2019-01-21
(33)【優先権主張国・地域又は機関】JP
(71)【出願人】
【識別番号】000002185
【氏名又は名称】ソニーグループ株式会社
(74)【代理人】
【識別番号】100121131
【弁理士】
【氏名又は名称】西川 孝
(74)【代理人】
【識別番号】100082131
【弁理士】
【氏名又は名称】稲本 義雄
(74)【代理人】
【識別番号】100168686
【弁理士】
【氏名又は名称】三浦 勇介
(72)【発明者】
【氏名】右田 隆仁
(72)【発明者】
【氏名】金盛 克俊
(57)【要約】
【課題】乗車率の向上に貢献する予測結果を提示することができるようにする。
【解決手段】情報処理装置は、営業車両の乗車需要予測データに基づく複数のルートのそれぞれのスコアに基づいて、おすすめのルートの探索結果を含む地図を表示させるように表示部を制御する表示制御部を備える。本技術は、例えば、タクシーの乗車需要の予測結果を表示する情報処理装置等に適用できる。
【選択図】
図4
【特許請求の範囲】
【請求項1】
営業車両の乗車需要予測データに基づく複数のルートのそれぞれのスコアに基づいて、おすすめのルートの探索結果を含む地図を表示させるように表示部を制御する表示制御部を備える
情報処理装置。
【請求項2】
前記表示制御部は、前記複数のルートのうち、通過する経路の前記スコアを合計した合計スコアが高いルートを、前記おすすめのルートとして、前記表示部に表示させる
請求項1に記載の情報処理装置。
【請求項3】
前記合計スコアは、乗車需要が予測される場所である乗車点毎の前記スコアを合計して算出される
請求項2に記載の情報処理装置。
【請求項4】
前記乗車点の前記スコアは、前記乗車点における、乗車があった日時、乗車があった回数、総乗車時間、平均乗車時間、及び、乗車距離が長距離となる乗車の割合のうち少なくとも1つに基づいて設定される
請求項3に記載の情報処理装置。
【請求項5】
前記通過する経路における道路の広さに基づいて、前記スコアが設定される
請求項2に記載の情報処理装置。
【請求項6】
前記合計スコアは、乗車需要のレベルに基づいて、前記営業車両の営業地域を分割したエリア毎の前記スコアを合計して算出される
請求項2に記載の情報処理装置。
【請求項7】
対向車線を横断する必要がある場所の前記スコアは、対向車線を横断する必要がない場所の前記スコアよりも低く設定される
請求項1に記載の情報処理装置。
【請求項8】
乗客の移動方向の予測結果と、目的地の方向とが近いほど、前記スコアが大きい
請求項1に記載の情報処理装置。
【請求項9】
前記表示制御部は、設定された目的地に向かうルートの中から、乗車需要が予測される場所を通過するルートを探索し、前記おすすめのルートとして、前記表示部に表示させる
請求項1に記載の情報処理装置。
【請求項10】
前記目的地は、ドライバが得意とするエリアまたは場所である
請求項9に記載の情報処理装置。
【請求項11】
前記ドライバが得意とするエリアは、前記ドライバが移動した時間が所定値以上のエリアである
請求項10に記載の情報処理装置。
【請求項12】
前記ドライバが得意とするエリアは、前記ドライバが乗客を乗せた時間が所定値以上のエリアである
請求項10に記載の情報処理装置。
【請求項13】
前記ドライバが得意とするエリアの表示単位は、市区町村であり、
前記ドライバが得意とする場所の表示単位は、乗車数が多い乗車位置である
請求項10に記載の情報処理装置。
【請求項14】
前記表示制御部は、現在地の周辺で、乗車需要が予測される場所を通過するルートを探索し、前記おすすめのルートとして、前記表示部に表示させる
請求項1に記載の情報処理装置。
【請求項15】
前記おすすめのルートを探索する際の所定のエリアの乗車需要を予測する予測時刻が、現在地からの距離に応じて変更される
請求項1に記載の情報処理装置。
【請求項16】
乗車需要の予測台数が、空車の前記営業車両の台数以上のルートを、前記おすすめのルートとして表示させる
請求項1に記載の情報処理装置。
【請求項17】
情報処理装置が、
営業車両の乗車需要予測データに基づく複数のルートのそれぞれのスコアに基づいて、おすすめのルートの探索結果を含む地図を表示させるように表示部を制御する
情報処理方法。
【請求項18】
コンピュータに、
営業車両の乗車需要予測データに基づく複数のルートのそれぞれのスコアに基づいて、おすすめのルートの探索結果を含む地図を表示させるように表示部を制御する
処理を実行させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【0001】
本技術は、情報処理装置、情報処理方法、およびプログラムに関し、特に、乗車率の向上に貢献する予測結果を提示することができるようにした情報処理装置、情報処理方法、およびプログラムに関する。
【背景技術】
【0002】
タクシー業界において、タクシーの需要を予測し、より効果的な営業を実施する取り組みが活発化してきている(例えば、特許文献1参照)。
【先行技術文献】
【特許文献】
【0003】
【発明の概要】
【発明が解決しようとする課題】
【0004】
タクシーの需要を予測するシステムにおいて乗車率を上げるためには、どのような予測結果を提示するかが重要である。
【0005】
本技術は、このような状況に鑑みてなされたものであり、乗車率の向上に貢献する予測結果を提示することができるようにするものである。
【課題を解決するための手段】
【0006】
本技術の一側面の情報処理装置は、営業車両の乗車需要予測データに基づく複数のルートのそれぞれのスコアに基づいて、おすすめのルートの探索結果を含む地図を表示させるように表示部を制御する表示制御部を備える。
【0007】
本技術の一側面の情報処理方法は、情報処理装置が、営業車両の乗車需要予測データに基づく複数のルートのそれぞれのスコアに基づいて、おすすめのルートの探索結果を含む地図を表示させるように表示部を制御する。
【0008】
本技術の一側面のプログラムは、コンピュータに、営業車両の乗車需要予測データに基づく複数のルートのそれぞれのスコアに基づいて、おすすめのルートの探索結果を含む地図を表示させるように表示部を制御する処理を実行させるためのものである。
【0009】
本技術の一側面においては、営業車両の乗車需要予測データに基づく複数のルートのそれぞれのスコアに基づいて、おすすめのルートの探索結果を含む地図が表示される。
【0010】
なお、プログラムは、伝送媒体を介して伝送することにより、又は、記録媒体に記録して、提供することができる。
【0011】
なお、本技術の一側面の情報処理装置は、コンピュータにプログラムを実行させることにより実現することができる。
【0012】
また、本技術の一側面の情報処理装置を実現するために、コンピュータに実行させるプログラムは、伝送媒体を介して伝送することにより、又は、記録媒体に記録して、提供することができる。
【0013】
情報処理装置は、独立した装置であっても良いし、1つの装置を構成している内部ブロックであっても良い。
【発明の効果】
【0014】
本技術の一側面によれば、乗車率の向上に貢献する予測結果を提示することができる。
【0015】
なお、ここに記載された効果は必ずしも限定されるものではなく、本開示中に記載されたいずれかの効果であってもよい。
【図面の簡単な説明】
【0016】
【
図1】本技術を適用した予測システムの一実施の形態の構成例を示すブロック図である。
【
図2】需要予測アプリによる需要予測画面の例を示す図である。
【
図3】予測システムの構成例を示すブロック図である。
【
図7】実車シーケンスデータ生成処理を説明するフローチャートである。
【
図8】学習予測処理を説明するフローチャートである。
【
図9】第1のクラスタリングの結果例を示す図である。
【
図10】第1のクラスタリングの結果例を示す図である。
【
図11】2段階クラスタリングの結果例を示す図である。
【
図12】未知エリアクラスタ分類処理を説明するフローチャートである。
【
図13】需要予測画面の第1表示例を示す図である。
【
図14】需要予測画面の第2表示例を示す図である。
【
図15】需要予測画面の第3表示例を示す図である。
【
図17】需要予測画面の第4表示例を示す図である。
【
図18】需要予測画面の第5表示例を示す図である。
【
図19】需要予測画面の第6表示例を示す図である。
【
図24】広域地図表示の場合の需要予測画面の例を示す図である。
【
図25】詳細地図表示の場合の需要予測画面の例を示す図である。
【
図26】詳細地図表示のその他の例を示す図である。
【
図27】音声案内制御処理を説明するフローチャートである。
【
図28】得意なエリアを抽出するヒートマップを説明する図である。
【
図29】おすすめルート提示画面の表示例を示す図である。
【
図30】ルート提示処理を説明するフローチャートである。
【
図31】乗車点のスコアの付与について説明する図である。
【
図32】乗車禁止地区を表示した需要予測画面の例を示す図である。
【
図33】付け場所を表示した需要予測画面の例を示す図である。
【
図34】終電の電車時刻を表示した需要予測画面の例を示す図である。
【
図35】逆引き乗車点表示機能が実行された需要予測画面の例を示す図である。
【
図36】逆引き乗車点表示機能が実行された需要予測画面の例を示す図である。
【
図37】配車/流し/付けを区別した需要予測画面の例を示す図である。
【
図38】平均乗車料金と信頼区間を表示した需要予測画面の例を示す図である。
【
図39】リアルタイムの空車台数を表示する需要予測画面の例を示す図である。
【
図40】リアルタイムの空車台数を表示する需要予測画面の例を示す図である。
【
図41】1日の営業評価情報を出力する評価画面の例を示す図である。
【
図43】距離や方角を考慮して付加情報を表示した需要予測画面の例を示す図である。
【
図44】進行方向に応じた情報を表示した需要予測画面の例を示す図である。
【
図45】本技術を適用したコンピュータの一実施の形態の構成例を示すブロック図である。
【発明を実施するための形態】
【0017】
以下、本技術を実施するための形態(以下、実施の形態という)について説明する。なお、説明は以下の順序で行う。
1.予測システムの構成例
2.需要予測アプリの画面例
3.ブロック図
4.実車シーケンスデータ生成処理
5.学習予測処理
6.未知エリアクラスタ分類処理
7.エリアARの結合表示
8.需要方向と頻度の表示
9.ピンポイント予測の表示
10.付け待ち時間予測の表示
11.ロング度予測の表示
12.乗車距離予測の表示
13.乗車料金予測の表示
14.乗車位置の学習
15.降車位置の学習
16.乗車位置の学習
17.音による乗車需要ガイド
18.おすすめルート提示処理
19.乗車禁止地区案内表示
20.付け場所表示
21.電車時刻表示
22.逆引き乗車点表示
23.配車/流し/付け待ちの需要予測分類表示
24.乗車料金予測の表示
25.リアルタイム空車台数の表示
26.1日の営業評価の表示
27.距離および方角を考慮した付加情報の表示
28.進行方向に応じた情報の表示
29.コンピュータ構成例
【0018】
<1.予測システムの構成例>
図1は、本技術を適用した予測システムの一実施の形態の構成例を示している。
【0019】
図1の予測システム1は、複数のタクシー11と、サーバ(情報処理装置)12とで構成され、タクシー11から取得されるデータに基づいて、タクシー11の営業地域における乗車の需要を予測するシステムである。
【0020】
タクシー11は、所定の営業地域を走行して、乗客を乗車させる営業車両である。タクシー11には、料金メータ21、車両管理装置22、および、端末装置23が、搭載されている。
【0021】
料金メータ21は、ドライバによる「実車」および「空車」の操作を受け付ける。「実車」とは、乗客を乗車させて走行している状態を表し、「空車」とは、乗客を乗車させずに走行している状態を表す。料金メータ21は、「実車」時には、走行した時間または距離の少なくとも一方に応じて料金(運賃)を計算し、所定の表示部に表示する。
【0022】
車両管理装置22は、タクシー11が走行した位置(経路)、「実車」または「空車」のステータスなどを所定の時間間隔で時系列に記録した車両動態ログデータを生成し、所定のネットワークを介して、サーバ12に送信する。「実車」または「空車」のステータスは、料金メータ21から取得される。
【0023】
端末装置23は、例えば、スマートフォンやタブレット端末等の情報処理装置で構成される。端末装置23には、サーバ12から送信されてくる乗車需要予測データを用いて、乗車の需要予測をディスプレイに表示するアプリケーションプログラム(以下、単に、需要予測アプリとも称する)が格納されている。
【0024】
需要予測アプリは、ドライバの操作によって、端末装置23上で起動され、実行される。需要予測アプリは、所定のネットワークを介して、サーバ12から送信されてくる乗車需要予測データを受信し、受信した乗車需要予測データに基づいて、地図上に乗車需要を予測した予測結果をディスプレイに表示する。乗車需要を予測した予測結果の具体的な表示例は、
図2等を参照して後述する。
【0025】
サーバ12は、ネットワークを介して、複数のタクシー11から、車両動態ログデータを取得する。そして、サーバ12は、取得した多数の車両動態ログデータを用いて、乗車需要予測データを生成し、複数のタクシー11それぞれへ、ネットワークを介して送信する。
【0026】
サーバ12、車両管理装置22、および、端末装置23を接続するネットワークは、例えば、所謂3G回線や4G回線等の移動体通信網、インターネット、公衆電話回線網、衛星通信網などで構成される。
【0027】
タクシー11のドライバは、需要予測アプリによって端末装置23のディスプレイに表示された、乗車需要予測を参考にしながら、乗客獲得のため、タクシー11を運転する。
【0028】
<2.需要予測アプリの画面例>
図2は、端末装置23において需要予測アプリによって表示された需要予測画面の例を示している。
【0029】
図2の需要予測画面には、地
図41が表示されるとともに、現在地マーク61、拡大縮小ボタン62、需要予測メッシュ63、設定ボタン64などが、地
図41の上に重畳表示されている。
【0030】
また、需要予測画面には、地
図41の表示領域とは異なる領域に、予測時刻設定領域42が設けられており、予測時刻設定領域42には、予測時刻表示71と、予測時刻変更ボタン72Aおよび72Bが含まれる。
【0031】
現在地マーク61は、タクシー11の現在地を表す。拡大縮小ボタン62は、地
図41の縮尺を拡大したり、縮小したりする場合に操作される。
【0032】
需要予測メッシュ63は、複数のエリアARを行列状に配置されて構成される。エリアARは、需要予測メッシュ63を格子状に分割した1つの領域を表す。なお、
図2の例では、地
図41上の一部の領域に、4x7の28個のエリアARが配置されているが、地
図41上の全ての領域にエリアARを重畳表示させてもよい。
【0033】
需要予測メッシュ63の各エリアARは、サーバ12から送信されてきた乗車需要予測データに基づいて、乗車需要の度合いに応じた色や濃度で表示されている。例えば、
図2において、濃度が濃いエリアARは、乗車需要が高いエリアARを表し、濃度が薄いエリアARは、乗車需要が低いエリアARを表す。
【0034】
設定ボタン64は、需要予測画面で表示可能な項目の選択や、表示の順番など、需要予測画面の表示に関する各種の設定を行う際に操作される。需要予測画面で表示可能な各項目の詳細は後述する。
【0035】
予測時刻設定領域42の予測時刻表示71は、需要予測メッシュ63が表示している需要予測の該当時刻を表示する。すなわち、需要予測メッシュ63には、予測時刻表示71に表示されている時刻の需要予測が表示される。予測時刻表示71をタップすると、現在の時刻にリセットされる。予測時刻変更ボタン72Aおよび72Bは、予測時刻表示71の予測時刻を所定単位(例えば、10分)で進めたり、戻したりする場合に操作される。
【0036】
以上のように、端末装置23の需要予測アプリは、サーバ12から送信されてくる乗車需要予測データを受信し、受信した乗車需要予測データに基づいて、地
図41上に乗車需要を予測した需要予測メッシュ63を、予測結果としてディスプレイに表示する。
【0037】
なお、
図2の例では、需要予測メッシュ63の各エリアARが、乗車需要の度合いに応じて、色や濃度が異なる表示で表示されることとしたが、後述する
図13に示されるように、乗車数の予測結果を併せて表示することもできる。
【0038】
<3.ブロック図>
次に、タクシー11に搭載された各装置、および、サーバ12の詳細構成について説明する。
【0039】
図3は、サーバ12、料金メータ21、車両管理装置22、および、端末装置23の構成例を示すブロック図である。
【0040】
料金メータ21は、ドライバによる「実車」または「空車」の操作を受け付け、「実車」または「空車」のステータスと、料金(運賃)を所定の表示部に表示する。料金メータ21は、「実車」または「空車」のステータスを、車両管理装置22に供給する。
【0041】
車両管理装置22は、位置検出部101、速度検出部102、制御部103、記憶部104、および、通信部105を備える。
【0042】
位置検出部101は、例えば、GPS (Global Positioning System)受信機等で構成され、測位衛星が放送する測位信号を受信してタクシー11の現在位置を検出する。また、位置検出部101は、ジャイロセンサ、地磁気センサ等を備え、タクシー11の進行方向を検出する。
【0043】
速度検出部102は、速度センサや加速度センサ等で構成され、タクシー11の移動速度を検出する。なお、速度検出部102は、タクシー11のホイールの回転速度を検出する速度センサから測定値を取得することにより、タクシー11の移動速度を検出してもよい。
【0044】
制御部103は、例えば、CPU(Central Processing Unit)、RAM(Random Access Memory)等で構成され、記憶部104に記憶されている動作制御プログラムを読み出し、動作制御プログラムにしたがって、車両管理装置22全体の動作を制御する。具体的には、制御部103は、料金メータ21、位置検出部101、および、速度検出部102のそれぞれから、一定時間間隔でデータを取得して、車両動態ログデータを生成し、記憶部104に記憶させる。また、制御部103は、記憶部104に記憶されている車両動態ログデータを、予め設定された所定のタイミングで、定期的または不定期に、通信部105を介して、サーバ12に送信する。
【0045】
記憶部104は、例えば、ハードディスク、ROM(Read Only Memory)、RAM、およびNVRAM(Non Volatile RAM)などで構成され、車両動態ログデータを記憶する。通信部105は、制御部103の制御に従い、サーバ12と所定の通信を行う。通信部105は、所定のネットワークを介したネットワーク通信を行うネットワークインタフェースで構成される。
【0046】
サーバ12は、制御部121、記憶部122、および、通信部123を備える。
【0047】
制御部121は、例えば、CPU、RAM等で構成され、記憶部122に記憶されている動作制御プログラムを読み出し、動作制御プログラムにしたがって、サーバ12全体の動作を制御する。
【0048】
制御部121は、機能的には、データ生成部131、学習部132、および、予測部133を少なくとも備え、機械学習により、地
図41上のエリアARごとの乗車需要を予測する。機械学習の手法は、例えば、k-means法、自己組織化マップ(SOM)、ニューラルネットワーク、HMM(隠れマルコフモデル)など、任意の手法を選択することができる。
【0049】
データ生成部131は、通信部123を介して複数のタクシー11の車両管理装置22それぞれから取得した車両動態ログデータを記憶部122に記憶させる。
【0050】
図4は、タクシー11の車両管理装置22によって生成され、サーバ12へ送信されてくる車両動態ログデータの例を示している。
【0051】
車両管理装置22は、所定の時間間隔(例えば、1分間隔)で、車両動態ログデータを生成し、蓄積する。
【0052】
車両動態ログデータとして生成される項目には、
図4に示されるように、タクシー11が所属する会社を識別する会社ID、タクシー11の車両を識別する無線ID、タクシー11に乗務しているドライバを識別する乗務員ID、ステータスの生成時刻を表すステータス時刻、タクシー11の位置情報である緯度および経度、タクシー11の走行速度および進行方向を示す方向および速度、並びに、「実車」または「空車」のステータスが含まれる。
【0053】
データ生成部131は、記憶部122に記憶された車両動態ログデータから、実車に関するデータである実車データを生成する。
【0054】
【0055】
実車データは、車両動態ログデータから、タクシー11の乗車に関する情報を抽出したデータであり、車両動態ログデータにおいて、ステータスが「空車」から「実車」となる乗車変化点と、「実車」から「空車」となる降車変化点の情報から生成される。
【0056】
実車データには、例えば、
図5に示されるように、ID、乗車時刻、出発地点、到着地点、乗車時間、乗車距離、および、運賃の各項目が含まれる。
【0057】
IDは、車両動態ログデータの会社ID、無線ID、および乗務員IDを結合したデータである。
【0058】
乗車時刻には、乗車変化点の「空車」のステータス時刻と、「実車」のステータス時刻との間の時刻が算出され、記録される。
【0059】
出発地点には、乗車変化点の「空車」の緯度および経度と、「実車」の緯度および経度との間の緯度および経度が算出され、記録される。
【0060】
到着地点には、降車変化点の「空車」の緯度および経度と、「実車」の緯度および経度との間の緯度および経度が算出され、記録される。
【0061】
乗車時間には、乗車時刻から、降車変化点の「空車」のステータス時刻と、「実車」のステータス時刻との間の時刻までの時間(単位は例えば、分)が算出され、記録される。
【0062】
乗車距離には、出発地点から到着地点までの距離(単位は例えば、km)が算出され、記録される。
【0063】
運賃は、乗車時間と乗車距離から、タクシー運賃の規定に従って算出され、記録される。
【0064】
なお、実車データの各項目の算出方法は、上述した方法に限定されず、それ以外の方法でもよい。例えば、ステータスが「実車」となっている最初と最後の車両動態ログデータから上記の各項目を算出してもよい。また、運賃や乗車距離の情報は、乗車変化点と降車変化点の位置から計算するのではなく、車両動態ログデータの一部として車両管理装置22から取得するようにしてもよい。
【0065】
データ生成部131は、多数のタクシー11の車両管理装置22の車両動態ログデータから生成された多数の実車データに基づいて、所定の時間単位(10分間)の乗車数を表す時系列データである実車シーケンスデータを、エリアARごとに生成する。例えば、データ生成部131は、10分ごとの乗車数をカウントした時系列データである実車シーケンスデータを、エリアARごとに生成する。
【0066】
図6は、タクシー11の営業地域を分割して得られる複数のエリアARのうち、エリア1223、エリア1224、および、エリア1225の3つのエリアARの実車シーケンスデータの例を示している。
【0067】
実車シーケンスデータの横軸は日付および時刻であり、縦軸は、乗車数を表す。
図6に示される実車シーケンスデータは8日間分のデータであるが、実車シーケンスデータの作成期間は、1週間、1か月、1年間等、任意の期間に設定することができる。例えば、実車シーケンスデータの作成期間を、1週間に設定すると曜日による変動を捉えることができ、数か月や1年間等の長期に設定すると、曜日による変動の他、年末年始やゴールデンウイーク、夏休み等の季節的な変動も捉えることができる。
【0068】
エリア1223の実車シーケンスデータ例で言えば、例えば、乗車時刻が2017年3月21日の10時から10時10分の間に含まれ、出発地点がエリア1223内に位置する実車データの数が、乗車数としてカウントされる。そのカウント結果が、2017年3月21日の10時から10時10分のエリア1223の実車シーケンスデータとなる。同様の処理が、取得された実車データの全期間で算出され、エリア1223の実車シーケンスデータが生成される。
【0069】
図3に戻り、学習部132は、多数のタクシー11の車両管理装置22から取得した実車データに基づいて生成された、多数かつ長期間の実車シーケンスデータを用いて、乗車需要を予測する予測器を学習により生成する。
【0070】
予測部133は、学習部132により生成された予測器を用いて、所定の時刻または時間帯の乗車需要を予測する。予測部133の予測結果は、乗車需要予測データとして、端末装置23に送信される。
【0071】
記憶部122は、車両管理装置22それぞれから取得した車両動態ログデータ、および、車両動態ログデータから生成された実車シーケンスデータを記憶する。車両動態ログデータから実車シーケンスデータを生成するための中間データである実車データも、記憶部122に記憶してもよい。
【0072】
通信部123は、制御部121の制御に従い、車両管理装置22および端末装置23と所定の通信を行う。通信部123は、所定のネットワークを介したネットワーク通信を行うネットワークインタフェースで構成される。
【0073】
端末装置23は、制御部141、操作部142、表示部143、通信部144、スピーカ145、および、マイクロホン146を備える。
【0074】
制御部141は、例えば、CPU、RAM等で構成され、図示せぬ記憶部に記憶されている動作制御プログラムにしたがって、端末装置23全体の動作を制御する。例えば、制御部141は、ユーザであるドライバの操作に基づいて、需要予測アプリを実行する。そして、制御部141は、表示部143を制御する表示制御部としても機能し、需要予測アプリの実行結果、例えば、
図2の需要予測画面などを、表示部143に表示させる。
【0075】
操作部142は、端末装置23に設けられた複数の操作ボタン、表示部143に重畳されたタッチパネル等で構成され、ユーザの操作を受け付け、受け付けた操作に対応する操作信号を制御部141に供給する。
【0076】
表示部143は、例えば、LCD(Liquid Crystal Display)等で構成され、
図2の需要予測画面など、所定の情報を表示する。
【0077】
通信部144は、制御部141の制御に従い、サーバ12と所定の通信を行う。通信部144は、所定のネットワークを介したネットワーク通信を行うネットワークインタフェースで構成される。
【0078】
スピーカ145は、電子音、効果音、メッセージの音声などの音を出力する。マイクロホン146は、ユーザが発する音声を検出したり、周囲音を収集する。
【0079】
サーバ12、料金メータ21、車両管理装置22、および、端末装置23は、以上のように構成されている。
【0080】
以下では、サーバ12、車両管理装置22、および、端末装置23のそれぞれが実行する処理の詳細について説明する。
【0081】
<4.実車シーケンスデータ生成処理>
初めに、
図7のフローチャートを参照して、サーバ12による実車シーケンスデータ生成処理について説明する。この処理は、例えば、定期的または不定期等の所定のタイミングで実行することができる。
【0082】
初めに、ステップS1において、サーバ12のデータ生成部131は、複数のタクシー11の車両管理装置22それぞれから、ネットワークを介して送信されてくる車両動態ログデータを取得(受信)する。なお、各車両管理装置22は、車両動態ログデータを任意のタイミングで個別にサーバ12へ送信することができ、同時である必要はない。
【0083】
ステップS2において、データ生成部131は、取得した車両動態ログデータから、実車データを生成する。実車データは、例えば、乗車時刻や出発地点などのように、車両動態ログデータの項目から算出されるデータと、運賃などのように、サーバ12側で追加される外部データとを含む。外部データとしては、その他、例えば、曜日や平日または休日などの日付に関連する日付関連情報、該当するエリアARでデータ取得日に行われたイベント等に関するイベント情報、天候の情報などを設けることができる。実車データとして外部データを付加することにより、例えば、曜日ごとや、イベントの有無、天候などに応じた状況毎の乗車需要を学習および予測することができる。
【0084】
ステップS3において、データ生成部131は、多数のタクシー11の車両管理装置22から生成された多数の実車データに基づいて、エリアARごとの実車シーケンスデータを生成し、記憶部122に記憶して、実車シーケンスデータ生成処理を終了する。
【0085】
<5.学習予測処理>
次に、
図8のフローチャートを参照して、生成されたエリアARごとの実車シーケンスデータを用いて乗車需要を学習および予測する学習予測処理について説明する。この処理も、例えば、定期的または不定期等の所定のタイミングで実行することができる。
【0086】
初めに、ステップS21において、サーバ12の学習部132は、タクシー11の営業地域を分割して得られる複数のエリアARのなかから、代表エリアを抽出する。学習部132は、複数のエリアARのなかから、予め決定した所定数だけ、エリアARを選択して、代表エリアとする。代表エリアは、ランダムに決定してもよいし、例えば、都心部のエリアARと郊外のエリアAR、駅に近いエリアARと駅が遠いエリアAR、または、駅が多いエリアARと駅が少ないエリアARなど、知見を持つユーザが、所定の基準で選択してもよい。
【0087】
ステップS22において、学習部132は、代表エリアとして抽出された各エリアARの実車シーケンスデータを用いて、2段階クラスタリングを実施する。より具体的には、学習部132は、第1のパラメータを用いて、抽出された複数の各エリアARをクラスタリングする第1のクラスタリングを実行し、第2のパラメータを用いて、抽出された複数の各エリアARをクラスタリングする第2のクラスタリングを実行する。
【0088】
例えば、学習部132は、第1のパラメータとして、エリアAR内における単位時間当たり(例えば、1日)の乗車数の平均と分散を用いて、第1のクラスタリングを実行し、第2のパラメータとして、エリアAR内における単位時間当たり(例えば、1日)の平均乗車数の波形を用いて、第2のクラスタリングを実行する。なお、クラスタリングの手法は、例えば、k-means法などを用いることができる。
【0089】
図9および
図10は、乗車数の平均と分散をパラメータとして、代表エリアである複数のエリアARをクラスタリングした第1のクラスタリングの結果例を示している。
【0090】
図9は、横軸を平均、縦軸を分散として、代表エリアとして抽出された複数のエリアARの分布を示している。
【0091】
図10は、代表エリアである複数のエリアARの実車シーケンスデータを、クラスタごとに示した図である。
図10の横軸は時刻(0時から24時)、縦軸は乗車数を表す。
【0092】
実車シーケンスデータは、基本的には、1日の各時間帯(朝、昼、夜など)ごとに同様の特徴が現れるため、クラスタリングは、実車シーケンスデータを基本単位(1日)毎に分割したデータを用いて行われている。
【0093】
図9および
図10では、代表エリアとして抽出された複数のエリアAR(の実車シーケンスデータ)が、6個のクラスタに分類されている。
【0094】
図11は、第1のクラスタリングのクラスタリング結果と、第2のクラスタリングのクラスタリング結果をまとめた、2段階クラスタリング結果の例を示している。
【0095】
図11において、横方向(列単位)が1段階目のクラスタリング結果を表し、縦方向(行単位)が2段階目のクラスタリング結果を表す。行列状に配置された各グラフの横軸および縦軸は
図10と同様である。
【0096】
図11において、列番号1、列番号2、列番号3、・・・・が、第1のクラスタリングによるクラスタリング結果であり、縦方向に並ぶ複数のエリアARが乗車数の平均と分散が類似するエリアARの集合(エリアAR群)となっている。一方、行番号A、行番号B、行番号C、・・・が、第2のクラスタリングによるクラスタリング結果であり、第1のクラスタリングのクラスタリング結果である各エリアAR群を、平均乗車数の波形が類似するエリアARでさらにクラスタリングした結果となっている。行列状の各グラフ内の数字は、そのクラスタに分類されたエリアARの数を表す。例えば、行番号Dおよび列番号2のクラスタD-2のグラフ内の数字「468」は、代表エリアのうち、468個のエリアARがクラスタD-2に分類されたことを表している。第1のパラメータとして用いた単位時間当たりの乗車数の平均と分散は、単位時間当たりの乗車数の大小と単位時間内の乗車数の変化の大きさを表し、第2のパラメータとして用いた単位時間当たりの平均乗車数の波形は、単位時間内の乗車数の時間による変化の傾向を表す。
【0097】
なお、2段階目のクラスタリングは、1段階目のクラスタリング結果毎に、個別に実行してもよいし、1段階目のクラスタリング結果とは別に、代表エリアとして抽出された複数のエリアAR全体で実行してもよい。
【0098】
本実施の形態では、例えば、タクシー11の営業地域が、4400個のエリアARに分割され、さらに4400個のうち、半分の2200個のエリアARを代表メッシュとして抽出し、2200個のエリアARに対して、2段階クラスタリングを実施することにより、44個のクラスタに分類されたこととする。
【0099】
次に、
図8のステップS23において、学習部132は、クラスタ毎に、クラスタに属する実車シーケンスデータを用いて、学習率などに代表される予測器の学習パラメータを調整して、ステップS24に進む。
【0100】
ステップS24において、学習部132は、調整された学習パラメータと、クラスタに属する1以上のエリアARの実車シーケンスデータを用いて、クラスタ毎に、乗車需要を予測する予測器を学習して、ステップS25に進む。
【0101】
ステップS25において、予測部133は、学習部132により生成された予測器を用いて、所定のエリアARにおける所定の時刻の乗車需要を予測する。例えば、クラスタC-4に属するエリアARの乗車需要を予測する場合、クラスタC-4の予測器を用いて、所定の時刻の乗車需要が予測される。
【0102】
ステップS21乃至S24の学習処理とステップS25の予測処理は、連続する処理として実行してもよいし、ステップS25の予測処理を、ステップS21乃至S24の処理とは異なるタイミングで実行してもよい。
【0103】
例えば、ステップS25の処理は、ステップS24の処理に続けて実行され、タクシー11の営業地域を構成する各エリアARの所定の時刻の乗車需要が算出され、記憶部122に記憶される。そして、端末装置23からの要求に応じて、記憶部122に記憶された需要の予測データが、乗車需要予測データとして、端末装置23に送信される。
【0104】
あるいはまた、端末装置23から、1以上のエリアARの所定の時刻の乗車需要の予測データが要求されたタイミングにおいて、ステップS25の処理が実行され、ステップS25の処理結果が、乗車需要予測データとして、端末装置23に送信される。
【0105】
乗車需要予測データを受信した端末装置23の需要予測アプリは、
図2に示したように、予測結果である各エリアARの乗車数に応じて、色や濃度を変えた需要予測メッシュ63を表示する。
【0106】
以上の学習予測処理によれば、営業地域を構成する4400個のエリアARのうち、代表エリアとして抽出された2200個のエリアARそれぞれが、所定のクラスタに分類され、分類結果に応じて、乗車需要を予測することができる。
【0107】
一方で、代表エリアとして抽出されなかった残りの2200個のエリアAR(以下、未知エリアARとも称する。)については、この段階では、どのクラスタに分類されるかが不明であり、乗車需要を予測することができない。
【0108】
<6.未知エリアクラスタ分類処理>
そこで次に、未知エリアARの乗車需要を予測するための処理について説明する。
【0109】
図12のフローチャートを参照して、未知エリアARが属するクラスタを判別する未知エリアクラスタ分類処理について説明する。この処理は、例えば、定期的または不定期等の所定のタイミングで実行することができる。
【0110】
初めに、ステップS41において、サーバ12の学習部132は、学習予測処理で分類された各クラスタの実車シーケンスデータの特徴(平均、分散、形状)を学習する。換言すれば、代表エリアとして抽出された2200個のエリアARの実車シーケンスデータと、クラスタとの関係が、学習器で学習される。
【0111】
ステップS42において、サーバ12の予測部133は、ステップS41の学習で得られたパラメータを用いた分類器に、未知エリアARの実車シーケンスデータを入力し、未知エリアARのクラスタを判別する。
【0112】
以上のように、未知エリアクラスタ分類処理によれば、代表エリアのクラスタリング結果と実車シーケンスデータとの関係を学習して生成した分類器を用いて、代表エリア以外の未知エリアARのクラスタリングを実行することができる。
【0113】
未知エリアARのクラスタが判別できると、判別されたクラスタの予測器を用いて、上述したステップS25の予測処理を実行することで、未知エリアARの乗車需要を予測することができる。
【0114】
したがって、
図8の学習予測処理および
図12の未知エリアクラスタ分類処理の両方を実行することで、タクシー11の営業地域を構成する4400個の全てのエリアARの乗車需要の予測が可能である。
【0115】
図8の学習予測処理では、ステップS21の処理である代表エリアの抽出を行うことで、学習するエリアARの数、換言すれば、実車シーケンスデータのデータ量を減らすことができるので、演算負荷を軽減し、乗車需要予測にかかるコストよび時間を削減することができる。
【0116】
また、ステップS22により、代表エリアとして抽出された各エリアARの実車シーケンスデータを用いて、2段階クラスタリングを実施することで、学習器の数を減らすことができ、乗車需要予測にかかるコストよび時間を削減することができる。具体的には、2段階クラスタリングを実施しない場合には、代表エリアとして抽出されたエリアAR数(2200個)の学習器が必要となるが、2段階クラスタリングを実施し、所定数のクラスタに分類できたことにより、学習に必要な学習器の数をクラスタ数(44個)とすることができる。
【0117】
各クラスタの学習器には、そのクラスタに分類された全てのエリアARの実車シーケンスデータを用いることができる。すなわち、例えば、エリア1223の乗車需要予測を学習する場合に、一般的には、そのエリア1223で取得された実車シーケンスデータのみを用いて学習が行われる。これに対して、本技術では、エリア1223が、例えば、クラスタD-2に分類され、クラスタD-2に属するエリアARが468個存在する場合に、エリア1223以外のエリアARを含めた468個のエリアARの実車シーケンスデータを用いて学習を行うことができる。したがって、1つの学習器に対して、1エリアARで取得できるデータ量よりも多いデータ量で学習を行うことができるので、予測精度を向上させることができる。
【0118】
そして、学習予測処理において代表エリアとして抽出されない未知エリアARについても、未知エリアクラスタ分類処理により、未知エリアARのクラスタを判別して、判別されたクラスタの予測器を用いて、未知エリアARの乗車需要を予測することができる。
【0119】
なお、上述したステップS23およびS24では、代表エリアとして抽出された各エリアARの実車シーケンスデータのみを用いて、学習パラメータの調整および予測器の学習を行ったが、営業地域に含まれる全ての未知エリアARについてクラスタが判別された後に、未知エリアARの実車シーケンスデータも加えて、学習パラメータの調整および予測器の学習を行ってもよい。
【0120】
したがって、
図1の予測システム1によれば、より効率的に学習し、予測することができる。また、少ないデータ量で、予測精度を向上させることができる。
【0121】
上述した学習予測処理および未知エリアクラスタ分類処理では、曜日、平日、または、休日などに関係なく、複数のタクシー11の車両管理装置22から取得される全ての車両動態ログデータから生成した実車シーケンスデータを用いて、クラスタ分類や学習を行った。
【0122】
しかしながら、実車シーケンスデータを、曜日、平日、休日、または、天候、などのカテゴリに分けて、カテゴリごとに、クラスタ分類や学習を行うようにしてもよい。これにより、曜日、平日、休日、天候、イベントの有無など、所定の条件ごとに乗車需要を予測し、予測結果をディスプレイに表示することができる。
【0123】
<7.エリアARの結合表示>
以下では、端末装置23の需要予測アプリが乗車需要の予測結果をディスプレイに表示する各種の表示例について説明する。
【0124】
図13は、需要予測アプリが表示する需要予測画面の第1表示例を示している。
【0125】
図2に示した需要予測画面では、需要予測メッシュ63は、同一の矩形サイズのエリアARを行列状に配置して構成されていた。また、予測結果である各エリアARの乗車数は、画面上に表示されていなかった。
【0126】
これに対して、
図13の需要予測メッシュ63では、予測結果である各エリアARの乗車数が、エリアAR内に表示されている。
【0127】
また、需要予測アプリは、隣接する複数のエリアARの乗車数が所定の閾値以下となる複数のエリアARについては、1つのエリアARに結合して、乗車数を表示している。
図13の第1表示例では、隣接する複数のエリアARの乗車数が10人以下となる複数のエリアARが、1つのエリアARとして結合して表示されている。具体的には、同一の矩形サイズで表示した場合の乗車数が、「4」、「2」、「2」、および、「1」となるような2×2のエリアARが、1つのエリアARに結合され、「9」として表示されている。なお、勿論、隣接の乗車数によっては、10以下であっても結合されない場合もある。
【0128】
予測される乗車数が、例えば、0、1、2など小さい場合に、需要を当てることは難しいため、需要予測アプリは、乗車数が一定以上の値となるようなエリアAR単位で、需要予測を表示することができる。これにより、予測の精度を向上させることができ、より有用な情報をドライバに提供することができる。
【0129】
なお、予測結果として表示する乗車数は、例えば、「10-13」のように、ある程度の幅を持たせた値でもよい。
【0130】
<8.需要方向と頻度の表示>
図14は、需要予測アプリが表示する需要予測画面の第2表示例を示している。
【0131】
図14では、各エリアARの乗車需要の度合いに応じた色や濃度の表示は省略されている。
【0132】
図14は、地
図41に重畳表示された需要予測メッシュ63の各エリアARのうち、ドライバが注目するエリアAR(以下、注目エリアARと称する。)について、さらに詳細な予測結果を表示する表示例を示している。
【0133】
ドライバが、地
図41に重畳表示された需要予測メッシュ63の各エリアARのなかから、所定のエリアARをタップ(タッチ)するなど、注目エリアARを指定する操作を行うと、需要予測アプリは、指定された注目エリアARに対して、
図14に示されるような表示を行う。
【0134】
図14では、ドライバにより指定された注目エリアARに対して、他のエリアARよりも太い幅の枠である注目エリア枠211が表示されている。そして、注目エリア枠211から外側に向かう矢印212-1乃至212-8が表示されている。矢印212-1乃至212-8それぞれを特に区別しない場合には、単に矢印212と称する。
【0135】
矢印212の方向は、注目エリアARで乗車する乗客の移動方向を表し、矢印212の長さは、注目エリアARで乗車し、矢印212の方向へ移動する乗客の平均的な移動距離を表す。また、矢印212の幅(矢の方向に垂直な方向の太さ)は、全方向に対する、その矢印212が示す方向の乗車の割合を表す。
【0136】
したがって、
図14の例では、注目エリアARで乗車する乗客は、乗車の割合としては、矢印212-3の方向へ移動する乗客が多く、矢印212-4の方向へ移動する乗客は、移動距離が長いことを示している。また例えば、注目エリアARで乗車する乗客のうち、矢印212-2や矢印212-6へ移動する乗客は少なく、移動距離も短いことを示している。
【0137】
ドライバは、例えば、いわゆる「流し」(タクシー11を走らせながら、乗客を探すこと)を行うエリアARを決定する際、需要予測メッシュ63の所定のエリアARを注目エリアARに設定し、矢印212を表示させることで、ドライバが帰る方向と同じ方向の乗客が多いエリアARを探す、などを行うことができる。
【0138】
各エリアARの乗客の移動方向は、車両動態ログデータの方向(進行方向)の情報も含めて学習することで予測することができる。
【0139】
なお、矢印212を表示する数、換言すれば、乗客の移動方向の予測数は、
図14に示した8以外の数であってもよい。また、全方向における矢印212の方向へ移動する乗客の割合は、矢印の幅で表す以外の方法、例えば、色の違いや数字の表記などで表してもよい。
【0140】
<9.ピンポイント予測の表示>
図15は、需要予測アプリが表示する需要予測画面の第3表示例を示している。
【0141】
図15も、ドライバが所定のエリアARを注目エリアARとして選択した場合に、さらに詳細な予測結果を表示する表示例を示している。
【0142】
営業地域を所定の単位で分割したエリアARのなかには、例えば、駅前やホテル前のタクシー乗り場など、乗車位置が決まっており、他と比較して乗車数が多い場所が存在することがある。
【0143】
そのような乗車数が多い乗車位置が注目エリアAR内に存在する場合、需要予測アプリは、注目エリアAR全体の乗車数とは別に、乗車数が多い乗車位置と、その乗車位置での乗車数をピンポイントで予測して表示することができる。以下では、注目エリアAR内で特定された、乗車数が多い乗車位置をピンポイント乗車位置と称する。
【0144】
図15では、注目エリアAR内の所定の位置に、ピンポイント乗車位置を表すピンポイント乗車位置マーク221が表示され、そのピンポイント乗車位置マーク221において予測される乗車数を表示する乗車数表示222が表示されている。
図15において、注目エリア枠211内に表示された「43」は、注目エリアAR全体としての乗車数であり、そのうち、乗車数表示222の「29」は、ピンポイント乗車位置マーク221のピンポイント乗車位置「品川駅高輪口タクシー乗り場」における乗車数を示している。このように、注目エリアARの乗車数に加えて、ピンポイント乗車位置と、そこで予測される乗車数を表示することにより、実車率を上げることができる。
【0145】
ピンポイント乗車位置は、エリアAR内において乗車位置が決まっている場所を一つ一つ調査するのではなく、実車データを用いて学習することで推定することができる。
【0146】
具体的には、
図16の左側の黒丸で示されるように、乗客の過去の乗車位置は、実車データの出発地点の情報から把握できる。乗客の過去の乗車位置を学習することにより、
図16の右側に示されるように、黒丸で示される乗車位置の推定値と、その乗車位置の確率(尤度)が算出される。乗車位置の確率は、0乃至1の範囲の数字で表され、
図16では、乗車位置の近傍に表示されている。需要予測アプリは、例えば、乗車位置の確率が所定の閾値(例えば、0.8)以上の乗車位置の推定値を、注目エリアAR内における、ピンポイント乗車位置として表示することができる。
【0147】
<10.付け待ち時間予測の表示>
図17は、需要予測アプリが表示する需要予測画面の第4表示例を示している。
【0148】
図17も、ドライバが所定のエリアARを注目エリアARとして選択した場合に、さらに詳細な予測結果を表示する表示例を示している。
【0149】
駅前やホテル前のタクシー乗り場など、乗車位置が決まっていて、乗車数が多い場所では、いわゆる「付け待ち」と呼ばれる、乗車位置で乗客を乗せるタクシー11の列に並んでタクシー11を待機させた状態で乗客を獲得する方法がある。付け待ちの不利な点は、例えば、タクシー乗り場でタクシー11の長い列ができている場合に、タクシー11の長い列の最後に並んでから、乗客を乗せるまでの時間がかかるということである。
【0150】
そこで、需要予測アプリは、乗車数が多い乗車位置(ピンポイント乗車位置)で、付け待ちが行われている場合に、付け待ちにかかる時間、換言すれば、乗車位置で待って乗客を乗せるまでに要する時間を表示することができる。
【0151】
具体的には、
図17に示されるように、注目エリアAR内のピンポイント乗車位置マーク221が付け待ちの場所である場合に、需要予測アプリは、ピンポイント乗車位置マーク221での乗車数表示222内に、付け待ち開始ボタン223を表示させる。需要予測アプリは、付け待ち開始ボタン223がタップ(タッチ)された場合、付け待ちを行った場合の付け待ちに要する時間(付け待ち時間)を示す付け待ち表示224を表示する。
図17の例では、付け待ち時間として「20分」が表示されている。
【0152】
例えば、ドライバは、ピンポイント乗車位置において、付け待ち表示224を表示させることにより、付け待ち時間を確認し、付け待ちする場所を選択することができる。付け待ち表示224に表示される付け待ち時間は、「15分-20分」のように、一定の幅を持った値でもよい。
【0153】
車両動態ログデータでは、ステータスが「空車」から「実車」となる乗車変化点と、その乗車変化点より少し前において、タクシー11がゆっくりと移動している状態を検出することができるので、タクシー11の付け待ち動作を検出することができる。例えば、乗車変化点の時刻より前の所定期間内または所定距離内における所定速度以下(時速5km/h以下)での走行を付け待ち動作として検出することができる。したがって、付け待ち動作を学習することにより、所定の乗車位置における付け待ち時間を予測することができる。
【0154】
<11.ロング度予測の表示>
図18は、需要予測アプリが表示する需要予測画面の第5表示例を示している。
【0155】
図18も、ドライバが所定のエリアARを注目エリアARとして選択した場合に、さらに詳細な予測結果を表示する表示例を示している。
【0156】
営業地域を所定の単位で分割したエリアARのなかには、例えば、羽田空港や成田空港を目的地とする場合など、乗車距離が長距離(所定の距離以上)となる乗車の割合が多いエリアARや乗車位置がある。ドライバが、長距離の乗客の可能性を判断できることが好ましい。
【0157】
そこで、需要予測アプリは、
図18に示されるように、注目エリアAR全体の乗車数とは別に、注目エリアARの長距離の乗客の割合を表示するロング表示241を行うことができる。
【0158】
ロング表示241では、注目エリアARの全乗車数のうち、乗車距離が長距離となる乗車の割合(比率)が、ロング度として表示される。また、ロング表示241では、乗車距離を複数の区分に分割し、分割した区分ごとの乗車の割合が、ロング区分として、棒グラフで表示される。
図18に示される「All」の棒グラフは、営業地域全体における区分ごとの乗車の割合を示し、「This」の棒グラフは、注目エリアARの区分ごとの乗車の割合を示している。
【0159】
ロング表示241は、
図18に示したように、注目エリアARについてのロング度およびロング区分を表示してもよいし、ピンポイント乗車位置マーク221に付随して表示させ、ピンポイント乗車位置についてのロング度およびロング区分を表示してもよい。
【0160】
図18のロング表示241の棒グラフは、ロング区分として、乗車距離を複数の区分に分割して、分割した区分(乗車距離)ごとの乗車の割合を示したが、乗車料金を複数の区分に分割して、分割した区分(乗車料金)ごとの乗車の割合を示してもよい。
【0161】
また、ロング表示241は、時間帯や天候ごとに乗車需要を予測して、所定の時間帯や天候に特化したロング度やロング区分を表示してもよい。
【0162】
ロング度やロング区分は、実車データの乗車距離と運賃の項目を含めて学習することで、予測することができる。
【0163】
<12.乗車距離予測の表示>
図19は、需要予測アプリが表示する需要予測画面の第6表示例を示している。
【0164】
図19も、ドライバが所定のエリアARを注目エリアARとして選択した場合に、さらに詳細な予測結果を表示する表示例を示している。
【0165】
需要予測アプリは、
図19に示されるように、所定のエリアARが注目エリアARとして選択された場合、注目エリアARで乗車する乗客の平均乗車距離とその信頼区間を表示する乗車距離表示251を行うことができる。信頼区間は、母集団の平均値(母平均)が所定の信頼度で含まれる範囲を表す。
【0166】
乗車距離表示251では、注目エリアARにおける乗車の平均乗車距離が、「2.4km」であり、例えば95%の信頼度における平均乗車距離の信頼区間が、「1.1kmから3.7km」であることが表示されている。信頼区間の信頼度は95%に限定されず、99%など任意に設定することができる。
【0167】
このように、注目エリアARの平均乗車距離およびその信頼区間を表示することにより、ドライバが、例えば、残りの勤務時間に適した乗車距離のエリアARを探したり、「流し」の経路として、乗車距離の長いエリアARを探したりすることができる。
【0168】
乗車距離表示251は、
図19に示したように、注目エリアARについて表示してもよいし、ピンポイント乗車位置マーク221に付随して表示させ、ピンポイント乗車位置についての平均乗車距離および信頼区間を表示してもよい。
【0169】
あるいはまた、平均乗車距離および信頼区間の代わりに、平均乗車料金(運賃)と信頼区間を示してもよい。
【0170】
あるいはまた、平均乗車距離および信頼区間の代わりに、平均乗車時間と信頼区間を示してもよい。
【0171】
また、乗車距離表示251は、時間帯や天候ごとに乗車需要を予測して、所定の時間帯や天候に特化した、平均乗車距離と信頼区間、平均乗車料金と信頼区間、または、平均乗車時間と信頼区間を表示してもよい。
【0172】
<13.乗車料金予測の表示>
タクシー11は、乗ってみないと乗車料金が確定しないため、利用を控える利用者も存在する。需要予測アプリは、現在地と目的地とから、乗車料金を予想して表示する機能を備える。
【0173】
図20は、需要予測アプリが表示する乗車料金予測画面の例を示している。
【0174】
需要予測アプリは、目的地までの移動に要する時間および料金を予測結果としてディスプレイに表示させるとともに、目的地までの移動経路を所定の単位に分割した分割単位ごとの、移動に要する時間および料金を、予測結果としてディスプレイに表示させる。
【0175】
図20の乗車料金予測画面において、個別表示261は、分割単位ごとの移動に要する時間および料金を示している。目的地表示262は、目的地までの移動に要する時間および料金を示している。
【0176】
乗車料金と移動時間の学習は、
図5に示した実車データをそのまま用いる場合には、出発地点と到着地点の両方が同じデータが必要となるため、学習が難しい。そこで、制御部121は、車両動態ログデータから、分割単位ごとの移動に要する時間および料金を学習する。そして、制御部121は、出発地点から到着地点までに含まれる各分割単位の時間および料金の総和を求めることにより、目的地までの移動に要する時間および料金を算出する。分割単位は、例えば、所定の距離、所定の時間、または、道路の区画(ブロック)などで区切られた単位、信号や交差点で区切られた単位、などの少なくとも1つまたは複数を用いて分割した単位とすることができる。
【0177】
分割単位ごとの移動時間および料金、並びに、目的地までの移動時間および料金は、例えば、「5分-10分」、「300円-500円」のように所定の幅を持たせた表示としてもよい。
【0178】
図13ないし
図20を参照して説明した各種の表示により、タクシー11のドライバは、より効率的な営業を行うことができる。すなわち、需要予測アプリは、乗車率の向上に貢献する予測結果を提示することができる。
【0179】
図13ないし
図20を参照して説明した各種の表示は、ドライバが、需要予測アプリの設定ボタン64を操作してディスプレイに表示させた設定画面において、表示のオンオフや、表示の順番などを適宜設定することができる。
【0180】
<14.乗車位置の学習>
次に、サーバ12が行う、乗車需要以外の学習および予測について説明する。
【0181】
図21は、ビル(建物)に対する乗車位置の学習を説明する図である。
【0182】
例えば、タクシー11の利用者(客)は、ビル271内の所定の位置から、スマートフォン等の端末で実行させた配車アプリ272を使ってタクシー11を手配し、ビル271の車寄せなど所定の位置273でタクシー11に乗車する。この場合、配車アプリ272は、タクシー11を手配したタイミングにおける利用者の位置情報を、端末内のGPS受信機から取得し、配車依頼時位置情報としてサーバ12に送信する。また、利用者がタクシー11に乗車したタイミングにおける利用者の位置情報である乗車時位置情報が、タクシー11の車両管理装置22から送信される車両動態ログデータから取得できる。
【0183】
サーバ12は、配車依頼時位置情報と乗車時位置情報との関係を学習する。これにより、利用者がビル271内の所定の位置からタクシー11を手配した場合に、ドライバがタクシー11をビル271のどこに着ければよいか、ビル271の乗車位置を学習することができる。サーバ12は、学習結果を乗車位置リストとして記憶部122に記憶する。需要予測アプリは、学習されたビル271の乗車位置を、地
図41上に表示することができる。また、利用者がビル271を目的地として指定した場合に、ドライバは、学習されたビル271の乗車位置を、降車位置とすることができる。
【0184】
また、サーバ12は、タクシー11の手配が実際に行われたビル271以外のビルについても、学習された配車依頼時位置情報と乗車時位置情報との関係から、ビルの乗車位置を類推して地
図41上に表示することができる。
【0185】
<15.降車位置の学習>
図21は、ビル(建物)に対する降車位置の学習を説明する図である。
【0186】
例えば、利用者は、所定の位置274でタクシー11を降車し、目的地である所定のビル271に移動する。利用者がタクシー11を降車したタイミングにおける利用者の位置情報である降車時位置情報が、タクシー11の車両管理装置22から送信される車両動態ログデータから取得できる。また、配車アプリ272は、利用者がタクシー11を降車後に移動したビル271の位置情報を、端末内のGPS受信機から取得し、移動後位置情報としてサーバ12に送信する。
【0187】
サーバ12は、降車時位置情報と移動後位置情報との関係を学習する。これにより、利用者がビル271を目的地として指定した場合に、ドライバは、利用者をどこで降ろせばよいか、ビル271の降車位置を学習することができる。サーバ12は、学習結果を降車位置リストとして記憶部122に記憶する。需要予測アプリは、学習されたビル271の降車位置を、地
図41上に表示することができる。また、利用者がビル271内の所定の位置から、配車アプリ272を使ってタクシー11を手配した場合に、ドライバは、学習されたビル271の降車位置を、乗車位置としても活用することができる。
【0188】
<16.乗車位置の学習>
図21および
図22を参照して説明した例では、学習した乗車位置を降車位置としても表示したり、学習した降車位置を乗車位置としても表示することを説明したが、一般に、ビル(建物)に対する乗車位置と降車位置は、タクシープールや車寄せ、玄関口などの場所であることが多く、一致するか、近くであることが多い。
【0189】
そこで、サーバ12は、
図23に示されるように、乗車時位置情報と降車時位置情報を学習し、ビル271に最適な乗車位置を学習し、乗車位置リストとして記憶部122に記憶する。需要予測アプリは、学習されたビル271の乗車位置を、地
図41上に表示することができる。
【0190】
<17.音による乗車需要ガイド>
次に、需要予測アプリが実行する、乗車需要の予測結果の音による案内について説明する。
【0191】
タクシー11のドライバは、運転中は、安全のため、需要予測アプリによって表示される需要予測画面を見ることはできない。そこで、需要予測アプリは、地図上に乗車需要を予測した予測結果をディスプレイに表示する他に、音によっても乗車需要の予測結果をドライバに通知する機能を備える。
【0192】
需要予測アプリは、需要予測画面に表示されている全ての予測結果を音で通知することはできないので、タクシー11の現在地(以下、自車位置とも称する)と、タクシー11の進行方向に対応した予測結果を音で通知する。
【0193】
また、需要予測アプリは、需要予測を表示する地
図41の縮尺に応じて、需要予測の表示方法と、音の通知方法を切り替える。
【0194】
以下では、需要予測を表示する地
図41の縮尺が高倍率、換言すれば、広域地図表示である場合の需要予測表示および音出力と、地
図41の縮尺が低倍率、換言すれば、詳細地図表示である場合の需要予測表示および音出力とを、順に、説明する。
【0195】
なお、需要予測アプリの音による通知には、「ピ、ピ、ピ」、「ポーン」、「ピンポン」のように、言語ではない音(効果音や電子音などとも呼ばれる)による通知と、単語や文章による音声(メッセージ)による通知の両方を含むが、以下では、簡単のため、効果音を単純に音と表現し、言葉による音出力を音声と表現して説明する。
【0196】
<広域地図表示における音通知例>
図24は、需要予測を表示する地
図41の縮尺が高倍率、換言すれば、広域地図表示の場合の需要予測画面の例を示している。
【0197】
図24の需要予測画面において、地
図41に重畳表示された需要予測メッシュ63の各エリアARのうち、エリア411が、乗車需要が高い場所として予測されたエリアARであるとする。
図24においては、エリア411以外の各エリアARの乗車需要の度合いに応じた色や濃度の表示は省略されている。
【0198】
タクシー11は、自車位置マーク421の場所を走行中であり、国道1号線の進行方向に、乗車需要が高い場所と予測されたエリア411が存在する。
【0199】
需要予測アプリは、進行方向に乗車需要が高いエリア411が存在していることを検出し、進行方向に乗車需要が高いエリア411が存在することを音または音声でドライバに通知する。例えば、需要予測アプリは、音声で「進行方向、近くに需要の高いところがあります。」と出力し、「ピピピ」と3連続の音を出力する。
【0200】
また、タクシー11が、国道1号線を走行し、自車位置マーク422の場所にいる場合、需要予測アプリは、例えば、音声で「進行方向、高需要です。」と出力し、「ピピピピ」と4連続の音を出力する。
【0201】
このように、需要予測アプリは、進行方向に乗車需要が高い場所であるエリア411が存在する場合、そのことを所定のタイミングで音または音声によりドライバに通知する。通知するタイミングは、例えば、需要予測メッシュ63のエリアAR単位に行うことができる。この場合、走行中のタクシー11が位置するエリアARが変更されるごとに、音または音声による通知が出力される。あるいは、需要予測アプリは、予め設定された時間ごと(例えば、1分間隔)や、予め設定された距離ごと(例えば、1kmごと)に通知するようにしてもよい。通知するタイミングは、設定ボタン64を操作して表示させる設定画面で変更することができる。
【0202】
需要予測アプリは、進行方向に検出された乗車需要が高いエリアARまでの距離(近さ)に応じて、音声メッセージの内容や、出力する音の種類を変更する。
【0203】
上述した例では、需要予測アプリは、自車位置が高需要エリアから遠い自車位置マーク421の場所では、需要予測アプリは、「進行方向、近くに需要の高いところがあります。」の音声を出力し、「ピピピ」と3連続の音を出力している。より近い場所では、需要予測アプリは、「進行方向、高需要です。」の音声を出力し、「ピピピピ」と4連続の音を出力している。すなわち、音声出力では、メッセージが「進行方向、近くに需要の高いところがあります。」から、「進行方向、高需要です。」に変更されている。音出力では、「ピピピ」の3連続の音から、「ピピピピ」と4連続の音となり、高需要エリアに近いほど、「ピ」という音の連続出力回数が増えていくように変更されている。効果音の連続回数を増やす他、例えば、「ピ」、「ピー」、「ピーー」のように、音の長さを変更したり、ボリュームが徐々に大きくなるようにしてもよい。また、音の回数、長さ、またはボリュームの少なくとも2つの組み合わせでもよい。
【0204】
また例えば、進行方向に交差点が存在し、高需要エリアが交差点を右折する方向である場合には、需要予測アプリは、「交差点右折方向、高需要です。」のように音声出力することができる。
【0205】
需要予測アプリが音または音声で高需要エリアを通知する乗車需要の度合いも、設定ボタン64を操作して表示させた設定画面で変更することができる。例えば、
図2に示したように、需要予測メッシュ63の各エリアARは、乗車需要の度合いに応じた色や濃度で表示されるが、
図2の需要予測画面で色や濃度で区別される乗車需要の度合いがレベル1乃至レベル5の5段階である場合に、乗車需要の度合いが最も高いレベル5のエリアARが進行方向に存在する場合に通知するように設定したり、レベル4以上のエリアARが進行方向に存在する場合に通知するように設定したりすることができる。
【0206】
高需要エリアの案内を音だけで行うか、音声だけで行うか、または、音と音声の両方で行うかについても、設定画面でドライバが設定することができる。需要予測アプリは、音または音声の少なくとも一方で、乗車需要の高い場所である所定のエリアARをドライバに通知する通知機能(通知部)を有する。
【0207】
なお、
図18では、乗車距離が長距離となる乗車の割合が多いエリアARや乗車位置がある場合に、乗車距離が長距離となる乗車の割合(比率)をロング度として表示するロング表示241について説明した。
【0208】
需要予測アプリは、広域地図表示の需要予測画面をディスプレイに表示している場合、ロング度が高いエリアARや乗車位置を音または音声でドライバに通知することもできる。
【0209】
例えば、需要予測アプリは、ロング度が所定の値以上であるエリアARが進行方向に存在する場合、音声で「近くにロングエリアがあります。」と出力するとともに、「ポーン」という、高需要エリアの通知とは異なる種類の音で出力する。
【0210】
<詳細地図表示における音通知例>
図25は、需要予測を表示する地
図41の縮尺が低倍率、換言すれば、詳細地図表示の場合の需要予測画面の例を示している。
【0211】
図25の詳細地図表示において、タクシー11は、自車位置マーク441の場所を走行している。
【0212】
詳細地図表示では、実車シーケンスデータを用いた学習の結果、ディスプレイに表示されている表示領域内で、乗車需要が所定レベルを超えた乗車位置が、それぞれ、円状の需要点451として表示される。なお、図が煩雑になるのを防止するため、
図25では、需要点451の一部の符号は省略されている。
【0213】
例えば、ディスプレイに表示されている表示領域内で学習された乗車位置のうち、乗車需要が高い上位30個の場所が、需要点451として表示される。ただし、所定の乗車位置が上位30個に含まれる場合であっても、乗車位置の総数が少ないために選択されたものは除外される。したがって、需要点451として表示される乗車位置は、予測される乗車需要が少なくとも所定の第1レベルThA以上であり、かつ、上位30個に含まれる乗車位置となる。
【0214】
図25の例では、需要点451として、濃度の濃い円で表示された需要点451Aと、濃度の薄い円で表示された需要点451Bと、需要点451Aおよび451Bと異なる模様で表示された需要点451Cとがある。
【0215】
需要点451Aと需要点451Bの濃度の違いは、予測される乗車需要の度合いを表す。すなわち、予測される乗車需要が、高い乗車需要を示す第2レベルThB以上である場合には、濃い濃度の需要点451Aで表示され、第1レベルThA以上、第2レベルThB未満である場合には、薄い濃度の需要点451Bで表示される。このように、乗車需要の大きさに応じて、需要点451の濃度を変えることで、例えば、需要点451が、他の需要点451と重ならずに単独で表示されている場合には、濃度の違いによって、ドライバは乗車需要の違いを認識することができる。また、需要点451が、他の需要点451と重なって表示されている場合には、需要点451の濃度が濃く見えるので、乗車需要が集積した場所も、ドライバに乗車需要の高い場所として認識させることができる。なお、需要点451Aと需要点451Bの2種類の濃度で区別するのではなく、乗車需要の度合いに応じて無段階に濃度を変更してもよい。
【0216】
異なる模様で表示された需要点451Cは、乗車需要が高い上位30個に選択された需要点451のうち、ロング度が所定の値以上の需要点451を表す。これにより、ドライバが、詳細地図表示において、ロング度が高い需要点451を認識することができる。
【0217】
図25では、図面の制約上、ロング度が高い需要点451Cと、それ以外の需要点451Aおよび451Bとを、模様の違いで表示するようにしたが、カラー表示が可能なディスプレイでは、需要点451Cと、需要点451Aおよび451Bとで、色を変えることで識別できるようにすることができる。
【0218】
上述した例では、詳細地図表示の表示領域内で上位30個までの乗車位置の場所を、需要点451として表示するようにしたが、需要点451を表示する個数は設定画面で変更することができる。例えば、設定画面で、上位30個、上位20個、上位10個のなかから、選択可能とされる。
【0219】
また、上述した例では、詳細地図表示の表示領域内で上位30個までの乗車位置を選択して表示したが、需要予測メッシュ63のエリアAR単位で上位30個を選択して表示してもよい。すなわち、需要点451を抽出する抽出単位は適宜設定することができる。
【0220】
次に、
図25のような詳細地図表示における音と音声による案内について説明する。
【0221】
タクシー11は、自車位置マーク441の場所から、所定の方向(例えば、品川駅方向)に向かって走行している。需要予測アプリは、進行方向の所定の距離以内に、需要点451が存在する場合に、音声で「進行方向、高需要です。」と出力する。また、需要予測アプリは、タクシー11が需要点451を通過するごとに、「ピ」と音を出力する。1個の需要点451に対して1回の音を出力する。
【0222】
詳細地図表示では、需要点451の通過に対して音が出力されるので、需要点451が多く表示されている道路では、「ピ」の音が連続的に発生する。これにより、ドライバは、現在通行している道路が、乗車需要が高い道路であることを認識することができ、乗車需要の多いエリアARや道路の認識向上に寄与し、ひいては、乗車率の向上に貢献する。各需要点451の乗車需要の度合いに応じて、「ピ」の音のボリュームの大きさを変更して出力するようにしてもよい。
【0223】
図25の例とは異なるが、タクシー11の進行方向に対して、需要点451が存在せず、進行方向と反対方向に需要点451が多く存在する場合には、需要予測アプリは、例えば、「反対方向に高需要ポイントがあります。」のような音声を出力する。また、進行方向に交差点が存在し、需要点451が多く存在する道路が交差点を右折する方向である場合には、需要予測アプリは、需要予測アプリは、「交差点右折方向、高需要です。」のように音声出力する。
【0224】
図26は、詳細地図表示のその他の表示例を示している。
【0225】
図26の詳細地図表示では、
図25の詳細地図表示に表示されていた需要点451の一部が、需要点451D乃至451Fに置き換えられている。
【0226】
車両動態ログデータには、
図4に示したように、タクシー11の進行方向も記録されているので、需要点451で乗車したタクシー11の進行方向も学習されている。需要点451におけるタクシー11の進行方向は、例えば、
図14の矢印212-1乃至212-8と同様に、8方向で学習されている。需要予測アプリは、各需要点451で乗車したタクシー11の8方向の進行方向のうち、50%以上の比率を占める進行方向が存在する場合に、その方向(以下、ドミナント方向と称する。)を表示することができる。
【0227】
需要点451Dは、ドミナント方向を示した需要点451を表す。需要点451Eは、同一のドミナント方向を有する需要点451Dが所定の範囲内に所定数以上存在する場合に表示される。すなわち、需要点451Eは、所定数以上の需要点451Dの集合を表す。
【0228】
需要点451Dは、例えば、
図26に示されるように、山型(V字型)の記号で表示され、角の指す方向がドミナント方向を表す。需要点451Eは、需要点451Dの記号をさらに拡大した記号で表される。なお、需要点451Dおよび需要点451Eは、例えば、矢印記号など、方向を示すことができるその他の記号で表示しもよい。
【0229】
需要点451Fは、ドミナント方向を有し、かつ、ロング度が高い需要点451を表す。換言すれば、ドミナント方向を有する需要点451Dが、
図25の需要点451Cのように、ロング度が高い需要点451である場合には、需要点451Fのように、模様または色を変えて表示することで、ロング度が高い需要点451であることも同時に表現されている。需要点451Eについてもロング度が高い場合には、同様に、模様または色を変えて表示される。
【0230】
詳細地図表示の各需要点451においてドミナント方向が存在する場合、そのドミナント方向を表示することで、ドライバが、例えば、いわゆる「流し」を行う際の走行方向の決定を手助けすることができ、乗車率の向上に貢献することができる。また、様々な方向があり得る交差点においても、交差点周辺のドミナント方向を参考にすることで、乗車需要の高い走行方向をドライバが決定することができる。
【0231】
図26の詳細地図表示における音および音声による通知方法は、
図25と同様であるので、説明は省略する。
【0232】
詳細地図表示においても、需要点451の案内を音だけで行うか、音声だけで行うか、または、音と音声の両方で行うかは、設定画面の設定値に応じて変更される。需要予測アプリは、音または音声の少なくとも一方で、乗車需要の高い場所である所定の需要点451をドライバに通知する通知機能(通知部)を有する。
【0233】
以上のように、需要予測アプリは、タクシー11の進行方向に対して、乗車需要の予測結果を、音や音声でドライバに通知することで、乗車率の向上に貢献することができる。
【0234】
需要予測画面が広域地図表示である場合(
図24)と、詳細地図表示である場合(
図25、
図26)とでは、乗車需要の表示方法も異なり、それに応じて、音および音声の通知方法も異なる。
【0235】
広域地図表示と詳細地図表示の切替えは、例えば、ドライバが、拡大縮小ボタン62の操作で行ったり、設定画面の設定を変更して行うことができる。あるいはまた、タッチパネル操作の代わりに、需要予測アプリが、ドライバが発する「広域表示」や「詳細表示」の音声指示を認識(音声認識)して、切替えてもよい。さらには、需要予測アプリが自動で切替えてもよい。例えば、需要予測アプリは、タクシー11の自車位置が、広域地図表示で案内した高需要エリアに進入したと判断された場合に詳細地図表示に変更し、高需要エリアから出たと判断された場合に広域地図表示に変更することができる。
【0236】
<音声案内制御処理>
上述した音および音声による乗車需要の予測の案内は、タクシー11が乗客を乗せていない空車時に必要となり、乗客を乗せている乗車時には必要がない。また、音および音声による通知は、乗客にとってはノイズとなる。そこで、需要予測アプリは、料金メータ21で検出される「実車」または「空車」のステータスを取得して、音および音声による案内のオンオフを、ステータスに連動して制御することができる。
【0237】
図27は、音声案内を制御する音声案内制御処理のフローチャートである。
【0238】
初めに、ステップS51において、需要予測アプリは、タクシー11(車両)のステータスが「実車」に変更されたかを判定する。
【0239】
ステップS51で、タクシー11のステータスが「実車」に変更されたと判定された場合、処理はステップS52に進み、需要予測アプリは、音声案内をオフに制御する。ステップS52の後、処理はステップS51に戻される。
【0240】
一方、ステップS51で、タクシー11のステータスが「実車」に変更されていないと判定された場合、処理はステップS53に進み、需要予測アプリは、タクシー11のステータスが「空車」に変更されたかを判定する。
【0241】
ステップS53で、タクシー11のステータスが「空車」に変更されたと判定された場合、処理はステップS54に進み、需要予測アプリは、音声案内をオンに制御する。ステップS54の後、処理はステップS51に戻される。
【0242】
一方、ステップS53で、タクシー11のステータスが「空車」に変更されていないと判定された場合も、処理はステップS51に戻される。
【0243】
図27の音声案内制御処理は、需要予測アプリが起動されたときや、設定画面において音声案内がオンに設定されたときに開始され、需要予測アプリが終了されるまで繰り返される。
【0244】
以上のように、需要予測アプリは、料金メータ21で検出される「実車」または「空車」のステータスに連動して、音声案内のオンオフを制御することができる。「実車」または「空車」のステータスに連動した制御により、ドライバが必要なときにのみ、自動で(ドライバの操作なしで)音声案内を実行することができる。
【0245】
なお、
図27の音声案内制御処理は、進行方向の乗車需要を音声メッセージで出力する音声案内の通知制御処理の例であるが、音による通知、および、音と音声の両方による通知も同様に制御される。「実車」または「空車」のステータスは、需要予測アプリが料金メータ21から直接取得してもよいし、車両管理装置22を介して間接的に取得してもよい。
【0246】
<その他の音声出力>
需要予測アプリは、上述した乗車需要を音および音声で通知する他、次のような情報も音声でドライバに通知することができる。
【0247】
例えば、需要予測アプリは、電車の運行停止情報や運行再開情報を、リアルタイムにサーバ12から取得して、音声(メッセージ)として出力することができる。これにより、ドライバは、電車の運行情報に応じて乗車需要が高まるエリアに迅速に移動することができる。
【0248】
需要予測アプリは、例えば、タクシー11の営業地域で開催されているイベントの終了タイミングや開始タイミングを、リアルタイムにサーバ12から取得して、音声(メッセージ)として出力することができる。これにより、ドライバは、イベントの終了や開始に応じて乗車需要が高まるエリアに迅速に移動することができる。
【0249】
需要予測アプリは、例えば、タクシー11の営業地域の天気情報、特に、突然の天気変化に関する情報を、リアルタイムにサーバ12から取得して、音声(メッセージ)として出力することができる。これにより、ドライバは、天気変化に応じて乗車需要が高まるエリアに迅速に移動することができる。
【0250】
サーバ12は、電車の運行情報や、イベント情報、天気情報などを、提携している情報提供会社のサーバから取得し、各端末装置23の需要予測アプリに送信する。
【0251】
<18.おすすめルート提示処理>
上述した実施の形態では、需要予測アプリが端末装置23のディスプレイに表示した乗車需要予測の表示や音声出力に基づいて、ドライバ自身がタクシー11の移動方向を決定し、タクシー11を運転する例について説明した。
【0252】
以下では、需要予測アプリが、サーバ12から送信されてきた乗車需要予測データに基づいて、乗車需要が高い経路を探索し、おすすめルートを提示するおすすめルート提示機能について説明する。
【0253】
需要予測アプリは、自車位置に基づいて、任意の方法で設定された目的地までの経路を探索するナビゲーション機能(ナビゲーション処理部)を有する。また、需要予測アプリは、車に搭載される一般的なナビゲーションシステム(以下、カーナビゲーションシステムと称する。)の機能に加え、乗車需要が高い場所として予測された場所を考慮して、目的地までの経路を探索する機能を有する。なお、目的地は、所定のピンポイントの場所であってもよいし、需要予測メッシュ63で分割された1つ以上のエリアARのような目的エリアであってもよい。以下では、乗車需要が高い場所として予測された場所を、乗車点と称して説明する。乗車点は、上述した説明では乗車位置や需要点などと称した場所と同一である。
【0254】
需要予測アプリのおすすめルート提示機能は、タクシー11が乗客を乗せていない状態である空車時、いわゆる「流し」の際に利用される。おすすめルート提示機能を利用することにより、乗客を短時間で捕まえることができ、空車時間や空車状態の運転距離を短くすることができる。また、タクシー業務を始めてからの期間が短い新人ドライバは、得意なエリア(地域)が決まっていなく、乗車需要が高い場所の知見がないため、特に有用である。タクシー業務を始めてからの期間が長いベテランドライバや、平均以上の売上を獲得するドライバにも、得意なエリアと不得意なエリアがあるので、不得意なエリアを運転している場合には、乗客を短時間で捕まえることができ、空車時間や空車状態の運転距離を短くすることができる。ルート探索時の目的地を、得意なエリアや場所とすることで、高需要の経路(乗車点)を通って、乗客を乗せつつ、所望のエリアまたは場所に戻ることも可能となる。おすすめルート提示機能を利用して高需要の経路(乗車点)を通る回数を重ねることにより、不得意なエリアを克服し、得意エリアを広げることができる。
【0255】
得意なエリアは、設定画面等において、ドライバに予め登録(設定)させてもよいし、ドライバの車両動態ログデータや実車データを用いて需要予測アプリが決定(自動登録)してもよい。得意な場所は、例えば、ドライバの営業所や、ドライバが頻繁に利用するピンポイント乗車位置、例えば、ドライバが頻繁に利用するタクシー乗り場などの「付け待ち」が行われる場所とすることができる。
【0256】
需要予測アプリがデータを用いて得意なエリアを決定する場合、需要予測アプリは、例えば、
図28に示されるように、XY平面に分布した営業地域に対して、Z軸方向を累積時間とするヒートマップを作成し、所定の閾値、例えば、総時間の70%に相当する時間値以上の領域を、ドライバの得意エリアとして抽出することができる。得意エリアは、閾値以上として抽出された1以上のエリア全てでもよいし、累積時間が最大の1個、または、累積時間が上位の複数個でもよい。得意エリアの表示単位は、抽出された領域そのままでもよいし、ドライバが認識し易くするため、抽出された領域のなかで面積最大の市区町村としたり、累積時間が最大の地点が存在する市区町村を表示単位としてもよい。
【0257】
Z軸方向の累積時間を計算する元のデータを、車両動態ログデータとした場合には、そのドライバが移動した時間の多いエリアを得意エリアとすることができる。また、Z軸方向の累積時間を計算する元のデータを、ステータスが「実車」である車両動態ログデータのみを用いた場合には、そのドライバが乗客を乗せた時間の多いエリアを得意エリアとすることができる。Z軸方向の累積時間を計算する元のデータを、実車データとした場合には、そのドライバが乗客を乗せた場所の多いエリアを得意エリアとすることができる。
【0258】
図29は、需要予測アプリにおいておすすめルート提示機能が実行された状態である、おすすめルート提示画面の表示例を示している。
【0259】
図29のおすすめルート提示画面は、例えば、ドライバが、
図2等の需要予測画面の画面上に表示されたおすすめルート探索ボタン等をタップすることにより、おすすめルートが探索された後に表示される。
【0260】
図29のおすすめルート提示画面には、需要予測メッシュ63が重畳された地
図41が表示されている。需要予測メッシュ63の各エリアARは、
図2を参照して説明したように、乗車需要の度合いに応じて、色や濃度で分類されて表示されているが、
図29の例では、図を見やすくするため、色または濃度による表示が省略されている。乗車需要の度合いに応じた色または濃度による表示が省略されている点は、後述する
図32乃至
図44についても同様である。
【0261】
地
図41上には、おすすめルートのルート探索結果501が表示されている。また、地
図41上には、地
図41の縮尺を低倍率にする際に操作される詳細ボタン511、地
図41の縮尺を高倍率にする際に操作される広域ボタン512、全画面表示に切り替える際に操作される全画面表示ボタン513なども表示されている。
【0262】
地
図41の下方には、予測時刻表示部502が配置されている。予測時刻表示部502には、おすすめルートの探索を行った際の需要予測の予測時刻が表示されるとともに、
図2の予測時刻設定領域42と同様に、需要予測の予測時刻の変更が可能である。
【0263】
地
図41および予測時刻表示部502の右側には、おすすめルート情報提示部503が配置されている。おすすめルート情報提示部503には、おすすめルート提示画面であることを示す「おすすめルート」の文字が最上段に表示されている。
【0264】
おすすめルート情報提示部503には、「<行き先モード>」が表示されており、地
図41上に表示されたルート探索結果501が、複数の探索モードのうち、“行き先モード”で探索されたことを表している。需要予測アプリは、需要点を考慮したルート探索のモードとして、“行き先モード”、“すぐ乗せるモード”、および、“近くの乗車点モード”の、3つの探索モードを有している。
【0265】
“行き先モード”は、目的地を設定して、目的地までの複数のルートのなかから、需要点を通過するルートを探索するモードである。目的地は、ドライバが設定してもよいし、ドライバの得意エリアを目的地(目的エリア)としてもよい。例えば、“行き先モード”は、タクシー11の現在地が得意エリア以外の場所であり、得意エリアに戻りながら、乗客を捕まえたいような場合に好適である。
【0266】
“すぐ乗せるモード”は、特定の目的地はなく、現在地から、需要点を通過するルートを探索するモードである。“すぐ乗せるモード”は、タクシー11の現在地が得意エリア内にいる場合に利用することができる。
【0267】
“近くの乗車点モード”は、特定の目的地はなく、現在地の周辺で、評価値が高い需要点を通過するルートを探索するモードである。“近くの乗車点モード”は、タクシー11の現在地が得意エリア内にいる場合、得意エリア外にいる場合のどちらにも利用することができる。
【0268】
おすすめルート情報提示部503の「<行き先モード>」の下方には、“行き先モード”のルート探索の目的地が世田谷区であることを表す「エリア「世田谷区」に戻ります」が表示されている。
【0269】
さらに、おすすめルート情報提示部503には、「おすすめ度 98点」、「乗車点数108か所」、「需要予測レベル計6レベル」の情報が表示されている。「おすすめ度 98点」は、地
図41上に表示されたルート探索結果501のおすすめ度が98点であることを表す。おすすめ度は、100点満点とした場合の点数でもよいし、数値が大きいほどおすすめ度合いが大きいことを表す点数表示でもよい。「乗車点数108か所」は、地
図41上に表示されたルート探索結果501のルートが、108か所の乗車点を通過するルートであることを表す。
図2の需要予測画面では、色や濃度で区別される各エリアARの乗車需要の度合いがレベル1乃至レベル5の5段階で表示される例を説明したが、「需要予測レベル計6レベル」は、地
図41上に表示されたルート探索結果501が通過する1以上のエリアARの乗車需要のレベルを合計すると、6レベルになることを表す。
【0270】
図30のフローチャートを参照して、需要点を考慮したおすすめルートを探索してドライバに提示するおすすめルート提示処理を説明する。
【0271】
この処理は、例えば、
図2等の需要予測画面の画面上に表示されたおすすめルート探索ボタン等をタップすることにより、開始される。なお、おすすめルート提示処理に用いられる乗車需要予測データは、サーバ12から定期的に送信されてくるデータを用いることができる他、必要に応じてサーバ12に要求することで取得することができる。
【0272】
初めに、ステップS71において、需要予測アプリは、探索モードが指定されたかを判定する。探索モードは、例えば、ルート探索ボタン押下後に表示されるモード選択画面において、“行き先モード”、“すぐ乗せるモード”、または、“近くの乗車点モード”のいずれかの探索モードボタンを選択することで、指定することができる。あるいはまた、自車位置が得意エリア以外にある場合には、“行き先モード”が選択され、自車位置が得意エリア内にある場合には、“すぐ乗せるモード”または“近くの乗車点モード”が選択されるように予め設定してもよい。
【0273】
探索モードが指定されたと判定されるまでステップS71の処理が繰り返され、探索モードが指定されたと判定された場合、処理がステップS72に進められる。
【0274】
そして、ステップS72において、需要予測アプリは、指定された探索モードが“行き先モード”、“すぐ乗せるモード”、または、“近くの乗車点モード”のいずれであるかを判定する。
【0275】
ステップS72で、指定された探索モードが“行き先モード”であると判定された場合、処理はステップS73に進み、ステップS73乃至S75の処理が実行される。指定された探索モードが“すぐ乗せるモード”であると判定された場合、処理はステップS76に進み、ステップS76およびS77の処理が実行される。指定された探索モードが“近くの乗車点モード”であると判定された場合、処理はステップS78に進み、ステップS78乃至S80の処理が実行される。
【0276】
指定された探索モードが“行き先モード”であると判定された場合のステップS73では、需要予測アプリは、行き先(目的地)を得意エリアに設定する。行き先は、デフォルトで、予め登録されている得意エリアに設定されるが、ドライバの操作によって変更することも可能である。
【0277】
ステップS74において、需要予測アプリは、ダイクストラ法やA*アルゴリズム等の探索経路アルゴリズムを用いて、自車位置と行き先とに基づいて、複数(所定数)のルートを検索する。この処理は、一般的なカーナビの機能と同様の処理である。
【0278】
ステップS75において、需要予測アプリは、検索された各ルートの合計スコアSUMscoreを計算する。
【0279】
ルートの合計スコアSUMscoreは、例えば、スコアSc=エリアARの乗車需要レベル[1-5]×乗車点[0,1]×方向一致度[cosθ]を、探索されたルートが通過するエリアAR毎に算出し、自車位置から行き先までの各エリアARのスコアScを合計することで算出することができる。エリアARの乗車需要レベル[1-5]は、そのエリアARの乗車需要の度合いを表し、レベル1乃至5のいずれかの値となる。乗車点[0,1]は、そのエリアARに乗車点が存在する場合には、“1”、存在しない場合には“0”となる。方向一致度[cosθ]は、自車位置から行き先までの方向に対する自車位置からエリアARの方向の角度(cosθ)であり、方向が一致するほど、1に近い値となる。上述したスコアScの計算式に用いる需要予測については、自車位置からの距離、例えば、エリアARの通過数などに応じて、エリアARの予測時刻が順次更新される。例えば、1つのエリアARを500m×500mとし、30km/hで10分運行すると仮定すると、10分で5km進むので、10エリアの移動ごとにエリアARの予測時刻を10分進め、ルートの需要予測が更新される。なお、上述したスコアScの計算式の乗車点[0,1]を、そのエリアARに存在する乗車点の個数などとしてもよい。
【0280】
ルートの合計スコアSUMscoreは、上述したエリアAR単位ではなく、ルート上に存在する乗車点ごとにスコアScを算出してもよい。また、探索されたルートの一部の経路において、方向が行き先に対して逆方向となるような場合には、スコアScの加算を行わないようにしたり、スコアScの減算を行うようにしてもよい。
【0281】
ルートの合計スコアSUMscoreは、上述した例に限らず、需要予測のレベルが高く、乗車点が多いルートの合計スコアSUMscoreが大きくなるような任意の計算方法を採用することができる。
【0282】
また、ルートの合計スコアSUMscoreには、その他の観点を付加してスコアScまたは合計スコアSUMscoreを計算してもよい。例えば、乗車点のロング度に応じた係数またはスコアScを付加して、ロング度が高いほど、合計スコアSUMscoreまたはスコアScが大きくなるようにしてもよい。あるいはまた、探索されたルートにおいて通過する経路が大通りであるか、または、狭い道路であるかなどに応じて、係数またはスコアScを付加してもよい。過去の乗車履歴(実車データ)の出発地点と到着地点から、各乗車点で乗車されたときの乗客の移動方向を識別することができる。ドライバの行き先と乗車点の移動方向とが近いほど、合計スコアSUMscoreまたはスコアScが大きくなるようにしてもよい。
【0283】
ステップS75の各ルートの合計スコアSUMscoreの計算後、処理は、後述するステップS81に進む。
【0284】
一方、指定された探索モードが“すぐ乗せるモード”であると判定された場合のステップS76では、需要予測アプリは、所定のルート探索領域に対して、グラフ理論である深さ制限探索により複数のルートを決定する。より具体的には、グラフ理論におけるノードを交差点、エッジを交差点間の道路(経路)として、ルート探索領域内で、深さ制限探索により、複数のルートが決定される。ルート探索領域は、自車位置が得意エリア内にいる場合には、得意エリアとしてもよいし、自車位置から半径何km以内としてもよいし、自車位置を中心に、所定数のエリアARとしてもよい。
【0285】
ステップS77において、需要予測アプリは、検索された各ルートの合計スコアSUMscoreを計算する。需要予測アプリは、例えば、検索されたルート上に存在する乗車点ごとのスコアScを、例えば、スコアSc=乗車点を含むエリアARの乗車需要レベル[1-5]として算出して合算することで、合計スコアSUMscoreを計算する。
【0286】
ルートの合計スコアSUMscoreは、上述した例に限らず、需要予測のレベルが高く、乗車点が多いルートの合計スコアSUMscoreが大きくなるような任意の計算方法を採用することができる。逆方向のスコアScの加算または減算や、需要予測の予測時刻の更新などは、“行き先モード”時の計算と同様に行うことができる。
【0287】
ステップS77の各ルートの合計スコアSUMscoreの計算後、処理は、後述するステップS81に進む。
【0288】
一方、指定された探索モードが“近くの乗車点モード”であると判定された場合のステップS78では、需要予測アプリは、自車位置からの距離が一定値以内に存在する乗車点を抽出し、抽出された各乗車点にスコアScを付与する。
【0289】
“近くの乗車点モード”における各乗車点のスコアScは、例えば、以下のように付与することができる。
【0290】
例えば、需要予測アプリは、各乗車点において、乗車があった日時が現在の日時に近いほど、大きなスコアScを付与する。需要予測アプリは、各乗車点において、乗車があった回数(乗車数)が多いほど、大きなスコアScを付与する。需要予測アプリは、各乗車点において、総乗車時間(各乗車回の乗車時間の合計)や、平均乗車時間が大きいほど、大きなスコアScを付与する。
【0291】
需要予測アプリは、各乗車点において、自車位置から、直進または左折で到達できる場所を高く、右折で到達できる場所は低くなるスコアScを付与する。
【0292】
例えば、
図31に示されるように、タクシー11が、自車位置マーク505の場所を走行中であり、乗車点として、直進で到達できる乗車点HS1と、左折で到達できる乗車点HS2と、右折で到達できる乗車点HS3があるとする。左側通行の日本では、直進の乗車点HS1と左折の乗車点HS2は、比較的移動しやすいが、対向車線を横断する必要がある右折の乗車点HS3は、信号機のタイミングや、対向車線を走行する車両のタイミングに依存する部分が多く、到達するまでに時間がかかることが多い。そのため、需要予測アプリは、乗車点HS1と乗車点HS2のスコアScを、乗車点HS3のスコアScよりも高く付与することができる。
【0293】
なお、右側通行が採用されている外国の道路においては、直進または右折で到達できる場所を高く、左折で到達できる場所は低くなるように、スコアScが付与される。すなわち、直進と、対向車線を横断する必要が無い方向に曲がる乗車点は高く、対向車線を横断する必要がある方向に曲がる乗車点は低く、スコアScが付与される。
【0294】
需要予測アプリは、各乗車点において、自車位置から近い場所であるほど高くなるスコアScを付与する。
【0295】
需要予測アプリは、各乗車点において、その乗車点が存在するエリアAR内で、乗車点が占める割合(例えば、その乗車点の乗車回数/エリアAR内全ての乗車回数)が大きいほど高くなるスコアScを付与する。
【0296】
需要予測アプリは、行き先が設定されている場合には、各乗車点において、行き先の方向との一致度が大きいほど高くなるスコアScを付与する。
【0297】
以上のようにして各乗車点に付与されたスコアScの合計が、最終的な各乗車点のスコアScとなる。なお、以上は、各乗車点に付与するスコアScの付与例の一例であり、その他の付与基準で、スコアScを付与してもよい。
【0298】
ステップS79において、需要予測アプリは、各乗車点に付与されたスコアScを参照し、スコアScの高い所定数の乗車点を経由点として、複数のルートを検索する。より具体的には、最初に、各乗車点に付与されたスコアScを参照し、スコアScの高い所定数の乗車点が抽出される。そして、抽出された乗車点を経由するように、複数(所定数)のルートが探索経路アルゴリズムを用いて探索される。
【0299】
ステップS80において、需要予測アプリは、検索された各ルートの合計スコアSUMscoreを計算する。需要予測アプリは、例えば、検索されたルート上に存在する各乗車点のスコアScを合算することで、合計スコアSUMscoreを計算する。あるいはまた、ルート上に存在する乗車点の数を、合計スコアSUMscoreとしてもよい。
【0300】
ステップS80の各ルートの合計スコアSUMscoreの計算後、処理は、ステップS81に進む。
【0301】
ステップS81において、“行き先モード”、“すぐ乗せるモード”、または、“近くの乗車点モード”のいずれかの探索モードで計算された複数のルートのうち、合計スコアSUMscoreが最も高いルートを、おすすめルートとしてディスプレイに表示する。
図29に示したおすすめルート提示画面は、探索モードが“行き先モード”で表示された例である。
【0302】
図30のおすすめルート提示処理は、以上のように実行される。おすすめルートが提示された後、一般的なカーナビゲーションシステムと同様に、ルートの案内が開始される。すなわち、ディスプレイによるルート表示の他、「次の交差点を右です」のように音声ガイドによりルートがドライバに指示される。ディスプレイによるルート表示では、
図26に示した需要点451のように、ルート上に表示される乗車点の記号や色、模様などを、乗車点のスコアScの値(大きさ)に応じて変えて表示してもよい。
【0303】
ドライバがおすすめルートの案内を停止する操作をタッチパネル操作等により行った場合、おすすめルートの案内が終了される。なお、端末装置23の需要予測アプリが、「実車」、「空車」、または「迎車」のステータスを、料金メータ21または車両管理装置22から取得して、「空車」以外のステータス、即ち、「実車」または「迎車」のステータスとなった場合に、ドライバの操作なしで終了(自動終了)するようにしてもよい。
【0304】
<19.乗車禁止地区案内表示>
タクシー11のドライバは、タクシー乗り場以外の場所でお客を乗せることが禁止されている乗車禁止地区に注意する必要がある。仮に、新人ドライバなど、乗車禁止地区に慣熟していないドライバが注乗車禁止地区でお客を乗せてしまった場合には、厳しい罰則がある。例えば、関東地方では、銀座や新橋に乗車禁止地区が設定されている。関西地方では、北新地や南地に乗車禁止地区が設定されている。
【0305】
需要予測アプリは、需要予測画面において、乗車禁止地区を表示することができる。
【0306】
図32は、乗車禁止地区を表示した需要予測画面の例を示している。
【0307】
図32において、
図29等と対応する部分については同一の符号を付してあり、その部分の説明は適宜省略する。
【0308】
図32の需要予測画面には、需要予測メッシュ63が重畳された地
図41上に、詳細ボタン511、広域ボタン512、および、全画面表示ボタン513が表示されている。また、地
図41上には、地
図41の表示を、自車位置を基準にした表示に切り替える現在地ボタン514も表示されている。
【0309】
さらに、地
図41の乗車禁止地区に該当する領域には、乗車禁止地区表示521が表示されている。また、乗車禁止地区表示521の近傍に、乗車禁止地区に関する詳細情報を表示する詳細表示522も表示されている。詳細表示522には、乗車禁止地区が適用される時間を示す「乗車禁止地区 22時から1時まで」の文字と、乗車禁止地区表示521を消去するための[OFF]ボタンが含まれる。乗車禁止地区表示521は、地
図41上に重畳されるため、需要予測の乗車点を示す表示が見えにくい場合や、乗車禁止地区の表示が不要なドライバは、[OFF]ボタンを操作することにより、乗車禁止地区表示521を消すことができる。需要予測アプリは、乗車禁止地区が適用される時間外となると、乗車禁止地区表示521と詳細表示522を消去する。
【0310】
また、
図32の需要予測画面には、地
図41の表示領域とは異なる領域に、予測時刻表示部502と、付加情報表示部531が設けられている。付加情報表示部531には、例えば、電車の運行情報や、イベント情報、天気情報などが表示される。
【0311】
乗車禁止地区に関する情報は、需要予測アプリ(端末装置23)内に予め記憶されてもよいし、サーバ12や、その他の情報提供会社のサーバ等から取得してもよい。
【0312】
<20.付け場所表示>
図17に示した付け待ち時間予測の表示では、「付け待ち」と呼ばれる、タクシー乗り場でタクシー11の列に並び、タクシー11を待機させた状態で乗客を獲得する方法があることについて説明した。「付け待ち」が行われる場所(以下、付け場所と称する。)は、駅前やホテル前のタクシー乗り場や、所定のオフィスビルの玄関前などである。このような付け場所には、付け場所を使用できるタクシー会社が限定された場所がある。所定のタクシー会社に限定された付け場所を、他のタクシー会社のタクシー11は使うことはできない。需要予測アプリは、所定のタクシー会社専用の付け場所であることを表示する機能を有する。
【0313】
図33は、タクシー会社ごとの付け場所を表示した需要予測画面の例を示している。
【0314】
図33の需要予測画面には、需要予測メッシュ63が重畳された地
図41上に、詳細ボタン511、広域ボタン512、全画面表示ボタン513、および、現在地ボタン514が表示されている。
【0315】
また、地
図41上の所定の乗車点541Aおよび541Bのそれぞれに、それらの乗車点が付け場所であることを示す付け場所表示551Aおよび551Bが表示されている。付け場所表示551Aは実線の円状図形で表され、付け場所表示551Bは破線の円状図形で表されており、付け場所表示551Aと付け場所表示551Bとで表示方法が異なっている。この表示方法の違いは、付け場所を使用可能なタクシー会社が異なることを表す。付け場所表示551Aと付け場所表示551Bとを特に区別しない場合には、単に付け場所表示551と称する。
【0316】
ドライバは、所定の付け場所表示551を選択(タップ)することにより、その付け場所の詳細情報553を表示することができる。
図33の例では、乗車点541Aの付け場所表示551Aに関する詳細情報553が表示されている。
【0317】
詳細情報553には、乗り場名称、そのタクシー11が付け場所を使用可能か否か、お客を乗せることが可能な時間帯、付け場所を使用可能なタクシー会社の名前、需要予測画面の地
図41上に表示された他の使用可能な付け場所、などの情報が表示される。
【0318】
図33の付け場所表示551Aの詳細情報553には、乗り場名称として「ホテル品川」が、タクシー11が使用可能か否かについて、使用できない付け場所であることを表す「×(使用不可)」、お客を乗せることが可能な時間帯として「終日」が、付け場所を使用可能なタクシー会社の名前として「Kmタクシー専用」が、需要予測画面の地
図41上に表示された他の使用可能な付け場所、すなわち付け場所表示551Bの乗車点541Bの乗り場名称として「大崎Thinkビル」が表示されている。
【0319】
ドライバのタクシー会社については、需要予測アプリを起動時のログイン画面や、設定画面において、会社を識別する会社IDや、タクシー11に乗務しているドライバを識別する乗務員IDなどを登録(入力)することで、需要予測アプリが識別することができる。
【0320】
図33の画面例では、付け場所表示551Aおよび551Bが、乗車点を囲む円状図形で表されているが、付け場所を示す表示方法は、これに限られない。付け場所表示551は、そのタクシー11が使用可能か否かで表示(色や記号)を変えてもよいし、そのタクシー11が使用可能な付け場所に限定して、付け場所表示551を表示するようにしてもよい。
【0321】
付け場所についての情報は、需要予測アプリ内に予め記憶されてもよいし、サーバ12や、その他の情報提供会社のサーバ等から取得してもよい。車両動態ログデータには、タクシー11が所属する会社を識別する会社IDが含まれているので、サーバ12は、既知の付け場所情報を取得する他、車両動態ログデータの履歴から乗車点の推定とともに、その乗車点が付け場所であるか否か、付け場所である場合に、どのタクシー会社が使用可能であるかを特定することができる。乗車点が付け場所であるかの特定は、上述したようにタクシー11の付け待ち動作を検出することができるので、その付け待ち動作後に、ステータスが「空車」から「実車」となる乗車変化点を付け場所の乗車点とすることができる。
【0322】
需要予測アプリの付け場所表示551により、ドライバが不要な付け場所に行くことを防止し、効率的な営業を行うことができる。
【0323】
<21.電車時刻表示>
ある鉄道路線の営業時間帯において、最後に運転される電車(いわゆる、終電)が出発した駅では、その電車を逃した人によるタクシー11の需要が増加する。また、終電が到着した駅においても、時間的に他の乗り換え線やバスも終了していることが多く、タクシー11の需要が増加する。あるいはまた、電車の運行本数が少ない(運行間隔が長い)鉄道路線では、ある駅で電車を降りた人が、タクシー11を利用することも多い。したがって、電車の終電時刻や到着時刻など電車時刻情報をドライバに案内できれば、ドライバは、その電車時刻情報を基に、駅前のタクシー乗り場に向かうことで、乗客を獲得することができる。
【0324】
需要予測アプリは、需要予測画面において、地
図41に表示された鉄道路線の駅の終電時刻等の所定の電車時刻を表示する機能を有する。
【0325】
図34は、終電の電車時刻を表示した需要予測画面の例を示している。
【0326】
図34の需要予測画面の地
図41には、京浜急行電鉄株式会社の品川駅と、東日本旅客鉄道株式会社(JR東日本)の品川駅と、都営浅草線の高輪台駅が存在しており、それぞれの終電の電車時刻が表示されている。
【0327】
具体的には、時刻表示571は、「品川駅 0:23 金沢文庫行」を表示し、京浜急行電鉄株式会社の品川駅の金沢文庫行きの最終電車の発車時刻が0:23であることを示している。
【0328】
時刻表示572は、「品川駅 0:46 大崎行」を表示し、東日本旅客鉄道株式会社(JR東日本)の品川駅の大崎行きの最終電車の発車時刻が0:46であることを示している。
【0329】
時刻表示573は、「高輪台駅 0:31 西馬込行」を表示し、都営浅草線の高輪台駅の西馬込行きの最終電車の発車時刻が0:31であることを示している。
【0330】
需要予測画面の地
図41の右側には、地
図41上に表示された電車時刻情報をリストで表示するリスト表示部581が表示されている。
【0331】
リスト表示部581には、時刻表示571乃至573と同じ情報が、電車時刻の早い順または遅い順、自車位置から駅までの距離が近い順または遠い順、などの所定の順番で一覧表示される。ソートボタン582は、電車時刻の早い順から遅い順へ、自車位置からの距離が近い順から遠い順へ、電車時刻順から自車位置からの距離順へなど、リスト表示部581に表示される順番を変更する際に操作される。電車時刻は、到着時刻または発車時刻のいずれでもよい。
【0332】
需要予測アプリが、終電時刻等の所定の電車時刻を表示する機能を有することにより、終電を逃した人や、終電から下りた人などを、乗客として獲得する機会が増加する。電車時刻表示機能は、設定により表示をオンオフさせることができる。需要予測画面の地
図41に表示された全ての駅の電車時刻を表示するのではなく、利用者数が多い(利用者数が一定値以上の)駅や、複数の路線が乗り入れているターミナル駅、始発や終点となる駅などに限定してもよい。地
図41に表示されている駅ではなく、自車位置から一定距離以内(例えば、半径2.5km以内)の駅を表示するようにしてもよい。あるいはまた、自車の進行方向に存在する駅のみ表示してもよい。どのような条件の駅の電車時刻を表示するかは、設定画面で設定することができるようにしてもよい。
【0333】
上述したように、電車の運行本数が少ない(運行間隔が長い)鉄道路線では、終電や始発に限らず、全ての電車時刻を表示するようにしてもよい。
【0334】
需要予測アプリは、乗車需要予測データとともに、または、乗車需要予測データの一部として、電車時刻表示のデータをサーバ12から取得して、需要予測画面に表示させることができる。需要予測アプリは、タクシー11の現在地と現在時刻に連動して、例えば、電車時刻の所定時間前となったら表示してもよいし、需要予測画面に電車時刻表示ボタンを設け、ドライバの操作に基づいて表示してもよい。
【0335】
<22.逆引き乗車点表示>
乗客が羽田空港や成田空港を行き先としてタクシー11を利用する場合などでは、乗車距離が長距離となることが期待できる。そのため、ドライバが、特定の行き先に向かう乗客を希望することがある。実車データには、出発地点と到着地点が記録されているので、到着地点が特定の場所である実車データを集めることにより、行き先が特定の場所である乗車点(出発地点)を解析することができる。
【0336】
そこで、需要予測アプリは、ドライバが行き先として特定の場所を指定し、過去の実車データにおいて、その指定された場所を、乗客が実際に行き先として乗車した乗車点のみを表示する逆引き乗車点表示機能を備える。逆引き乗車点とは、行き先が特定の場所に限定された乗車点を表す。行き先として指定可能な場所には、例えば、羽田空港や成田空港、東京ディスニーリゾート(登録商標)(以下、TDRと称する。)などが挙げられる。
【0337】
図35は、逆引き乗車点表示機能が実行された需要予測画面の例を示している。
【0338】
図35の需要予測画面は、例えば、ドライバが、需要予測画面上に表示された逆引き乗車点表示ボタン等を操作することにより表示される。
【0339】
図35の需要予測画面では、需要予測メッシュ63が重畳された地
図41の隣り(右側)に、逆引き乗車点表示部601が配置されている。地
図41の下方には、予測時刻表示部602が配置されている。
【0340】
逆引き乗車点表示部601には、需要予測を表示する乗客の行き先のリストと、需要予測表示を実行する実行ボタン611が表示される。
図35の例では、行き先として、羽田空港、成田空港、および、TDRの3つが表示されており、羽田空港に向かう乗客の需要予測を表示させる場合には実行ボタン611A、成田空港に向かう乗客の需要予測を表示させる場合には実行ボタン611B、TDRに向かう乗客の需要予測を表示させる場合には実行ボタン611Cがタッチ(選択)される。
【0341】
予測時刻表示部602には、需要予測の予測時刻が表示されるとともに、
図2の予測時刻設定領域42と同様に、需要予測の予測時刻の変更が可能である。
【0342】
図36は、実行ボタン611Aがタッチされた場合の、羽田空港に向かう乗客の需要予測画面の例を示している。詳細ボタン511または広域ボタン512を操作することにより、需要予測画面の地
図41の倍率を変更することができる。
図36の例は、実行ボタン611Aにより最初に表示される需要予測の地
図41の縮尺が、高倍率(広域地図)とした例であるが、実行ボタン611Aにより最初に表示される需要予測の地
図41の縮尺は、実行時の
図35の需要予測画面の地
図41と同倍率の表示とすることもできる。
図36の需要予測画面では、乗車点や行き先ごとに、その行き先に行く乗客に該当する確率を表示してもよい。
【0343】
所定の場所を行き先とする乗客の需要予測は、時間帯の他、天気や曜日(平日、休前日、休日)などの条件ごとに分類し、需要予測実行時の条件に合致する逆引き乗車点を表示することができる。
【0344】
逆引き乗車点表示部601に表示される1以上の行き先は、
図35に示した、羽田空港、成田空港、および、TDRのように、予め設定された場所としてもよいし、タクシー11の現在地に応じて、現在地から向かうことが多い場所としてもよい。行き先には、上述した例の他、例えば、その他のテーマパーク、コンサート会場、イベント会場、球場などを設定しておくことができる。
【0345】
<23.配車/流し/付け待ちの需要予測分類表示>
利用者がタクシー11に乗る場合、「配車(trip request)」、「流し(cruising vehicle)」、「付け待ち(customer waiting at stand)」の3通りのタクシー11の獲得方法がある。「配車」は、タクシー会社のコールセンターやアプリ等でタクシー11を手配し、所定の場所へタクシー11に来てもらう方法である。「流し」は、空車で移動しているタクシー11を捕まえる方法である。「付け待ち」は、付け場所に移動して、付け待ちをしているタクシー11に乗る方法である。需要予測アプリが、需要予測画面において需要予測を表示する場合、「配車」、「流し」、「付け待ち」の乗車方法の違いを区別して需要予測を表示することができる。すなわち、需要予測アプリは、「配車」、「流し」、「付け待ち」の乗車方法の違いを区別して需要予測を表示する機能を備える。
【0346】
図37は、「配車」、「流し」、「付け待ち」の乗車方法の違いを区別して需要予測を表示する需要予測画面の例を示している。
【0347】
図37の需要予測画面には、需要予測メッシュ63が重畳された地
図41と、需要予測の予測時刻の指定が可能な予測時刻表示部502と、付加情報表示部531とが設けられている。
【0348】
需要予測画面の地
図41上には、詳細ボタン511、広域ボタン512、全画面表示ボタン513、および、現在地ボタン514に加えて、付け表示ボタン641、流し表示ボタン642、および、配車表示ボタン643が設けられている。また、「配車」、「流し」、および「付け待ち」の乗車方法の違いを識別可能に、色、模様、マーク形状等の表示方法を異ならせた乗車点645が、地
図41上に表示されている。
【0349】
付け表示ボタン641は、「付け待ち」の乗車方法による乗車点645を地
図41上に表示する場合に操作される。流し表示ボタン642は、「流し」の乗車方法による乗車点645を地
図41上に表示する場合に操作される。配車表示ボタン643は、「配車」の乗車方法による乗車点645を地
図41上に表示する場合に操作される。付け表示ボタン641、流し表示ボタン642、および、配車表示ボタン643は、トグルボタンとなっており、操作する度に、指定の乗車方法単位で乗車点645の表示をオンオフすることができる。また、「配車」、「流し」、および「付け待ち」の任意の組合せも可能であり、例えば、「配車」と「流し」の両方がオンされている場合には、地
図41上には、「配車」の乗車方法と「流し」の乗車方法の両方の乗車点645が表示される。
【0350】
「配車」、「流し」、または「付け待ち」の乗車方法の違いによる乗車点の需要予測は、「配車」、「流し」、または「付け待ち」の乗車方法の違いごとに乗車需要を予測することで求めることができる。「配車」による実車データは、タクシー11のステータスが「迎車」となった直後の「実車」の実車データを集めればよい。「付け待ち」による実車データは、付け待ち動作後の「実車」の実車データを集めればよい。「流し」による実車データは、「配車」と「付け待ち」以外の実車データとすることができる。
【0351】
乗車需要(乗車点)を、「配車」、「流し」、または「付け待ち」の乗車方法の違いを区別して表示することで、ドライバの営業スタイルに合わせた乗車需要をドライバに提示することができる。
【0352】
<24.乗車料金予測の表示>
図18では、所定のエリアARが注目エリアARとして選択された場合に、注目エリアARの長距離の乗客の割合を表示するロング表示241を行う例について説明した。
【0353】
また、
図19では、所定のエリアARが注目エリアARとして選択された場合に、注目エリアARで乗車する乗客の平均乗車距離とその信頼区間を表示する乗車距離表示251を行う例について説明した。
【0354】
また、
図19の説明では、需要予測アプリが、平均乗車距離および信頼区間の代わりに、平均乗車料金(運賃)と信頼区間を示してもよいことや、時間帯や天候ごとに乗車需要を予測することができることを説明した。
【0355】
図38は、注目エリアARで乗車する乗客の平均乗車料金(運賃)と信頼区間を表示した場合の表示例を示している。
【0356】
需要予測アプリは、
図38に示されるように、注目エリアAR全体の乗車数とは別に、注目エリアARで乗車する乗客の平均乗車料金とその信頼区間を表示する乗車料金表示711を行うことができる。
【0357】
乗車料金表示711では、注目エリアARにおける乗車の平均料金が、「2,400円」であり、例えば70%の信頼度における平均乗車料金の信頼区間が、「1,110円から3,700円」であることが表示されている。信頼区間の信頼度は70%に限定されず、80%など任意に設定することができる。
【0358】
また、乗車料金表示711では、表示された乗車料金の予測値が、「18:00-18:30の時間帯、平日、雨、10月」に特化した実車データに基づく値であることを示している。
【0359】
このように、注目エリアARの平均乗車料金およびその信頼区間を表示することにより、ドライバが、例えば、高い乗車料金が期待できるエリアARを探したりすることができる。
【0360】
乗車料金表示711は、
図38に示したように、注目エリアARについて表示してもよいし、ピンポイント乗車位置マーク221(
図15)に付随して表示させ、ピンポイント乗車位置についての平均乗車料金および信頼区間を表示してもよい。
【0361】
また、上述した説明では、
図2を参照して説明したように、需要予測メッシュ63の各エリアARを、乗車需要の度合いに応じて、色や濃度で分けて表示するようにしたが、期待される乗車料金で、色や濃度を変えて表示してもよい。この場合、ドライバは、例えば、高い乗車料金が期待できるルートを選んで、「流し」の運転を行うことができる。
【0362】
<25.リアルタイム空車台数の表示>
需要予測アプリは、所定の時刻(時間帯)における乗車需要を予測して表示するが、例えば、注目エリアARに10台の乗車需要が予測されるが、そこに、お客を乗せたいタクシー11が20台存在するとしたら、10台のタクシー11は、乗客を獲得することができない。すなわち、乗客を獲得することができるか否かは、需要と供給の関係にも依存する。
【0363】
タクシー会社は、配車センターなどにおいて、営業中の各タクシー11の現在地と、「実車」、「空車」または「迎車」等のステータスとをリアルタイムに管理している。リアルタイムに取得される、各タクシー11の現在地とステータスとを含む運行データと、乗車需要予測とを組み合わせることで、ドライバは、上述した需要と供給の関係をも考慮した効率の良い営業を行うことができる。なお、リアルタイムには、営業中の各タクシー11の現在地とステータス情報の収集、需要予測アプリへの運行データの配信等にかかる多少(例えば、数分程度)のタイムラグを含む。
【0364】
図39は、運行データに基づいてリアルタイムの空車情報を表示する需要予測画面の例を示している。
【0365】
図39の需要予測画面は、需要予測メッシュ63が重畳された地
図41と、需要予測の予測時刻の指定が可能な予測時刻表示部502と、エリア情報表示部741とを備える。
【0366】
地
図41の需要予測メッシュ63で区分された各エリアARには、そのエリアARに存在するタクシー11の空車情報742がリアルタイムに表示されている。タクシー11の空車情報742は、現在、そのエリアAR内を移動し、「空車」のステータスとなっているタクシー11の台数を表す。
【0367】
需要予測メッシュ63で区分されたエリアARのうち、ドライバにより指定された注目エリアARには、注目エリア枠211が表示されている。エリア情報表示部741には、注目エリア枠211の詳細情報が、エリア情報として表示されている。エリア情報表示部741は、例えば、そのエリアARの乗車需要の予測台数、そのエリアARの乗客のロング率などが表示されている。
図39の例では、注目エリア枠211が表示された注目エリアARに、乗車需要の予測台数が0台に対して、現在5台の「空車」のタクシー11がいることを表している。
【0368】
図40は、地
図41の縮尺が低倍率、換言すれば、詳細地図表示である場合のリアルタイムの空車情報を示した需要予測画面の表示例を示している。
【0369】
図39は、地
図41の縮尺が高倍率、換言すれば、広域地図表示である場合のリアルタイムの空車情報を示した需要予測画面の表示例を示していた。広域地図表示の場合には、
図39に示したように、需要予測メッシュ63のエリアAR単位で、「空車」のタクシー11の台数が、空車情報として表示される。
【0370】
これに対して、詳細地図表示の場合には、
図40に示されるように、「空車」のタクシー11が存在する位置に、「空車」のタクシー11の存在を示すアイコン751が表示される。
【0371】
なお、付け待ち場所の乗車点などでは、その付け待ち場所の乗車点で付け待ちしている台数も表示することができる。
【0372】
需要予測アプリが、運行データに基づいてリアルタイムの空車情報を表示する機能を備えることにより、ドライバは、乗客を獲得する確率の高いエリアARを選んで運行することができ、乗客を獲得する確率を上げることができる。
【0373】
また、需要予測アプリが運行データを取得できる場合には、上述したおすすめルート提示処理において、運行データのリアルタイムの空車情報を含めて、おすすめルートを探索し、提示することができる。すなわち、おすすめルートの一部として所定の経路を選択する際、需要予測アプリが、乗車需要の予測台数が、「空車」のタクシー台数以上の経路をおすすめルートとして選択したり、大きなスコアScを付与する。また、需要予測アプリは、所定の経路で、現在から所定時間前までの一定期間、「空車」のタクシー11が通っていない場合には、乗車需要があるかもしれないので、おすすめルートとして選択する処理を入れてもよい。
【0374】
<26.1日の営業評価の表示>
需要予測アプリは、ドライバが1日の営業の終了後に、その日の営業を評価する営業評価情報を出力する機能を備えることができる。営業の評価は、優秀なドライバ、例えば、1日の売り上げ平均が高いドライバを基準に行うことができる。優秀なドライバを評価の基準ドライバとすることで、売り上げを上げるための情報をドライバに提供することができる。
【0375】
図41は、1日の営業評価情報を出力する評価画面の例を示している。この評価画面は、例えば、需要予測アプリにおいて、1日の営業を終了する操作が行われたタイミング等で表示される。
【0376】
図41の評価画面には、その上部に、タイトル表示811が表示されている。
図41の例では、「10/11 乗務スコア」と表示され、10月11日の営業日の評価情報であることが示されている。
【0377】
また、評価画面には、評価点数表示812と、レーダチャート813、営業収入グラフ814、および、ルート履歴表示ボタン815が設けられている。
【0378】
評価点数表示812は、ドライバの1日全体の総合評価を、基準ドライバを100点とする値で示している。この総合評価値を参照することにより、ドライバが、どれくらい基準ドライバに近づいたかを確認することができる。
【0379】
レーダチャート813は、ドライバの1日全体の総合評価値を複数項目に分けて示した評価結果を示している。
図41の例では、営業収入、実車率、空車時間、営業回数、および、営業範囲の5項目に分類されている。営業収入は、実走行時間当たりの営業収入(売り上げ)の観点からの評価値を表す。実車率は、「実車」の走行時間/総走行時間の観点からの評価値を表す。空車時間は、「空車」の時間/総走行時間の観点からの評価値を表す。営業回数は、お客を乗せた回数の観点からの評価値を表す。営業範囲は、走行したエリアの大きさの観点からの評価値を表す。
【0380】
営業収入グラフ814は、1日の営業時間(営業時刻)を横軸、営業収入を縦軸として、その日1日の営業収入の推移を表示する。営業収入グラフ814内に表示された実線821は、ドライバの実際の売り上げを表す。一方、営業収入グラフ814内に表示された破線822は、ドライバの実際の運行経路と、他のタクシー11の運行データ等を基に、理想的な仮想の売り上げを表す。例えば、ドライバの実際の運行経路と、他のタクシー11の運行データがあれば、ある交差点で、実際にはドライバは直進したが、仮に左折していれば、乗客を獲得できたと予想される場合などを解析することができる。そのような想定を実際の運行経路について解析すると、運行経路の少しの違いで獲得できたであろう理想の営業収入を予測することができる。そのような理想の営業収入が、破線822として表示されている。また、破線822において、営業収入を上げる可能性があったポイント(場所)に対して、「東銀座7丁目を曲がっていた場合」、「新橋5丁目を曲がっていた場合」などのように、コメントが表示されている。
【0381】
ルート履歴表示ボタン815は、ドライバの1日の実際の運行履歴を地図上に表示する機能である。
【0382】
図42は、ルート履歴表示ボタン815が操作されたときに表示される運行履歴画面の例を示している。
【0383】
運行履歴画面には、
図42に示されるように、1日の営業開始から営業終了までに、そのタクシー11が移動した経路と、「実車」、「空車」、または「迎車」のステータス、乗客が乗った場所と降りた場所およびその時刻、などが表示される。なお、
図42の例では、地
図41が表示されていないが、実際には、地
図41上に重畳表示される。また、
図42の例では、1日の運行経路の一部のみが表示されているが、ドライバは、地
図41の表示倍率を変えることにより、1日の全部または一部の運行経路を確認することができる。
【0384】
図42の運行履歴画面は、
図41の評価画面と合わせて、1つの画面に表示してもよい。
図42の運行履歴画面は、
図41の評価画面の営業収入グラフ814の営業収入を上げる可能性があったポイントと合わせて参照することで、次回の営業に参考にすることができる。
【0385】
<27.距離および方角を考慮した付加情報の表示>
電車の運行情報や、イベント情報、天気情報などの付加情報を表示する場合、
図32の例で示したように、地
図41の表示領域とは異なる領域に付加情報表示部531を設け、表示してもよいが、距離や方角を考慮して、地
図41上に、付加情報を表示してもよい。
【0386】
図43は、距離や方角を考慮して付加情報を表示した需要予測画面の例を示している。
【0387】
図43の例では、付加情報831と、付加情報832が、地
図41上に表示されている。
【0388】
付加情報831は、山手線の田町駅で運転見合わせが発生したことを通知する情報である。付加情報831は、タクシー11の現在地を示す自車位置マーク505を基準に、田町駅の方角に対応する位置に表示されている。
図43の例は、田町駅が、需要予測画面の地
図41の表示外の場所にあるため、田町駅の方角に対応する位置に付加情報831のみが表示されているが、仮に、田町駅が、需要予測画面の地
図41上にある場合には、地
図41上の田町駅の部分に、付加情報831とともに、運転見合わせが発生したことを示す、例えば、×、△などの記号が表示される。また、付加情報831として記号のみの表示し、その記号をタップ(選択)した場合に、詳細情報が表示されるようにしてもよい。
【0389】
付加情報832は、都営浅草線の戸越駅で電車の遅延が発生したことを通知する情報である。付加情報832は、タクシー11の現在地を示す自車位置マーク505を基準に、戸越駅の方角に対応する位置に表示されている。
【0390】
自車位置マーク505を基準とする方角は、1度単位などの詳細な角度でもよいし、4方向、8方向などの所定の範囲に収束させた角度でもよい。
【0391】
また、距離についても同様に、付加情報に関する位置までの距離が現在地から遠い場合は、自車位置マーク505に対して遠く、近い場合は自車位置マーク505に対して近い位置に表示される。
【0392】
例えば、付加情報が、電車の遅延に関する情報である場合、影響があると計算された駅を、付加情報に関する位置として、自車位置マーク505からの方向および距離を計算することができる。
【0393】
例えば、付加情報が、イベントに関する情報である場合、イベントが開催される場所を、付加情報に関する位置として、自車位置マーク505からの方向および距離を計算することができる。
【0394】
例えば、付加情報が、ゲリラ豪雨などの天気に関する情報である場合、気象現象の発生場所を、付加情報に関する位置として、自車位置マーク505からの方向および距離を計算することができる。
【0395】
以上のように、付加情報の距離や方角に応じて、付加情報を地
図41上に表示して、ドライバに提示することにより、ドライバが付加情報を直観的に理解することができる。
【0396】
なお、
図43の需要予測画面において、地
図41上に表示される乗車点645(需要点451でも同様)の表示や、予測時刻表示部502の表示は省略されている。
【0397】
<28.進行方向に応じた情報の表示>
需要予測の乗車点などの予測情報や、
図43等で示したイベント情報や電車遅延情報などの付加的な付加情報は、タクシー11の進行方向にある情報は重要であるが、進行方向の逆方向にある情報は、さほど重要ではない。地
図41の経路の情報についても同様である。
【0398】
そのため、需要予測アプリは、需要予測画面の地
図41を表示する際、進行方向の情報を、進行方向の逆方向の情報よりも、表示される情報量が多くなるように表示することができる。
【0399】
図44のAは、タクシー11の進行方向を画面の上方(上辺側)とするヘッドアップ(Head Up)モード時の表示例を示している。
【0400】
ヘッドアップモードでは、地
図41の全領域に対して、自車位置マーク505が、左右方向については、右側領域R1と左側領域L1とが同一または略同一となり、上下方向については、上側領域U1が下側領域D1よりも大きくなるように配置される。
【0401】
図44のBは、タクシー11の進行方向に関係なく、北の方角を画面の上方(上辺側)とするノースアップ(North Up)モード時の表示例を示している。
【0402】
ノースアップモードでは、右側領域R1と左側領域L1との配分、および、上側領域U1と下側領域D1との配分が、タクシー11の進行方向によって異なるが、
図44のBは、タクシー11の進行方向が、北東方向の場合の表示例を示している。この場合、左右方向については、右側領域R1が左側領域L1よりも大きくなり、上下方向については、上側領域U1が下側領域D1よりも大きくなるように配置される。
【0403】
その他の図示は省略するが、例えば、タクシー11の進行方向が南西方向の場合には、左右方向については、左側領域L1が右側領域R1よりも大きくなり、上下方向については、下側領域D1が上側領域U1よりも大きくなるように配置される。
【0404】
以上のように、進行方向の情報を、進行方向の逆方向の情報よりも、表示される情報量が多くなるように表示することで、ドライバにより有用な情報を表示することができる。
【0405】
<29.コンピュータ構成例>
上述した一連の処理は、ハードウエアにより実行することもできるし、ソフトウエアにより実行することもできる。一連の処理をソフトウエアにより実行する場合には、そのソフトウエアを構成するプログラムが、コンピュータにインストールされる。ここで、コンピュータには、専用のハードウエアに組み込まれているマイクロコンピュータや、各種のプログラムをインストールすることで、各種の機能を実行することが可能な、例えば汎用のパーソナルコンピュータなどが含まれる。
【0406】
図45は、サーバ12、車両管理装置22、または、端末装置23が実行する各処理をコンピュータがプログラムにより実行する場合の、コンピュータのハードウエアの構成例を示すブロック図である。
【0407】
コンピュータにおいて、CPU(Central Processing Unit)301,ROM(Read Only Memory)302,RAM(Random Access Memory)303は、バス304により相互に接続されている。
【0408】
バス304には、さらに、入出力インタフェース305が接続されている。入出力インタフェース305には、入力部306、出力部307、記憶部308、通信部309、及びドライブ310が接続されている。
【0409】
入力部306は、操作ボタン、キーボード、マウス、マイクロホン、タッチパネル、入力端子などよりなる。出力部307は、ディスプレイ、スピーカ、出力端子などよりなる。記憶部308は、ハードディスク、RAMディスク、不揮発性のメモリなどよりなる。通信部309は、ネットワークインタフェースなどよりなる。ドライブ310は、磁気ディスク、光ディスク、光磁気ディスク、或いは半導体メモリなどのリムーバブル記録媒体311を駆動する。
【0410】
以上のように構成されるコンピュータでは、CPU301が、例えば、記憶部308に記憶されているプログラムを、入出力インタフェース305及びバス304を介して、RAM303にロードして実行することにより、上述した一連の処理が行われる。RAM303にはまた、CPU301が各種の処理を実行する上において必要なデータなども適宜記憶される。
【0411】
コンピュータ(CPU301)が実行するプログラムは、例えば、パッケージメディア等としてのリムーバブル記録媒体311に記録して提供することができる。また、プログラムは、ローカルエリアネットワーク、インターネット、デジタル衛星放送といった、有線または無線の伝送媒体を介して提供することができる。
【0412】
コンピュータでは、プログラムは、リムーバブル記録媒体311をドライブ310に装着することにより、入出力インタフェース305を介して、記憶部308にインストールすることができる。また、プログラムは、有線または無線の伝送媒体を介して、通信部309で受信し、記憶部308にインストールすることができる。その他、プログラムは、ROM302や記憶部308に、あらかじめインストールしておくことができる。
【0413】
本明細書において、システムとは、複数の構成要素(装置、モジュール(部品)等)の集合を意味し、すべての構成要素が同一筐体中にあるか否かは問わない。したがって、別個の筐体に収納され、ネットワークを介して接続されている複数の装置、及び、1つの筐体の中に複数のモジュールが収納されている1つの装置は、いずれも、システムである。
【0414】
また、本明細書において、フローチャートに記述されたステップは、記載された順序に沿って時系列的に行われる場合はもちろん、必ずしも時系列的に処理されなくとも、並列に、あるいは呼び出しが行われたとき等の必要なタイミングで実行されてもよい。
【0415】
本技術の実施の形態は、上述した実施の形態に限定されるものではなく、本技術の要旨を逸脱しない範囲において種々の変更が可能である。
【0416】
上述した実施の形態は、営業車両として、タクシーの乗車の需要を予測する予測システムの例について説明したが、客(人)を乗せるその他の営業車両、具体的には、バス、電車、飛行機、船、ヘリコプターなどや、物(荷物)を載せる営業車両、トラック、ダンプ等の需要を予測するシステムにも適用することができる。また、営業車両は、ドローン等の無人で動く輸送車両であってもよい。
【0417】
例えば、上述した実施の形態の全てまたは一部を適宜組み合わせた形態を採用することができる。
【0418】
例えば、本技術は、1つの機能をネットワークを介して複数の装置で分担、共同して処理するクラウドコンピューティングの構成をとることができる。
【0419】
また、上述のフローチャートで説明した各ステップは、1つの装置で実行する他、複数の装置で分担して実行することができる。
【0420】
さらに、1つのステップに複数の処理が含まれる場合には、その1つのステップに含まれる複数の処理は、1つの装置で実行する他、複数の装置で分担して実行することができる。
【0421】
なお、本明細書に記載された効果はあくまで例示であって限定されるものではなく、本明細書に記載されたもの以外の効果があってもよい。
【0422】
なお、本技術は以下のような構成も取ることができる。
(1)
営業車両の営業地域を複数のエリアに分割して、エリア毎の乗車需要を予測した前記複数のエリアのうち、注目する前記エリアである注目エリアの乗客の移動方向および移動距離を、予測結果として表示部に表示させる表示制御部を備える
情報処理装置。
(2)
前記表示制御部は、前記移動方向および前記移動距離を前記注目エリアから外側に向かう矢印で前記表示部に表示させる
前記(1)に記載の情報処理装置。
(3)
前記矢印の方向は前記移動方向を表し、前記矢印の長さは前記移動距離を表し、前記矢印の太さは全方向における前記移動方向の乗車の割合を表す
前記(2)に記載の情報処理装置。
(4)
前記表示制御部は、前記注目エリア内の、乗車が多い乗車位置および前記乗車位置での乗車数を、予測結果として前記表示部に表示させる
前記(1)乃至(3)のいずれかに記載の情報処理装置。
(5)
前記表示制御部は、前記注目エリア内の、乗車が多い乗車位置および前記乗車位置での乗車数と、前記注目エリアの乗車数とを、予測結果として前記表示部に表示させる
前記(1)乃至(4)のいずれかに記載の情報処理装置。
(6)
前記表示制御部は、前記注目エリア内の、所定の乗車位置および前記乗車位置での乗車数と、前記乗車位置で待って乗客を乗せるまでに要する時間とを、予測結果として前記表示部に表示させる
前記(1)乃至(5)のいずれかに記載の情報処理装置。
(7)
前記表示制御部は、前記注目エリアにおける乗車距離が所定の距離以上となる乗車の割合を、予測結果として前記表示部に表示させる
前記(1)乃至(6)のいずれかに記載の情報処理装置。
(8)
前記表示制御部は、前記注目エリアにおける乗車距離を複数の区分に分割し、分割した区分ごとの乗車の割合を、予測結果として前記表示部に表示させる
前記(1)乃至(7)のいずれかに記載の情報処理装置。
(9)
前記表示制御部は、前記複数のエリア全体の前記区分ごとの乗車の割合も、予測結果として前記表示部に表示させる
前記(8)に記載の情報処理装置。
(10)
前記表示制御部は、目的地までの移動に要する時間および料金と、前記目的地までの移動経路を所定の単位に分割した分割単位ごとの移動に要する時間および料金とを、予測結果として前記表示部に表示させる
前記(1)乃至(9)のいずれかに記載の情報処理装置。
(11)
前記表示制御部は、前記注目エリアにおける前記乗客の平均乗車距離とその信頼区間とを、予測結果として前記表示部に表示させる
前記(1)乃至(10)のいずれかに記載の情報処理装置。
(12)
前記表示制御部は、前記注目エリアにおける前記乗客の平均乗車料金とその信頼区間とを、予測結果として前記表示部に表示させる
前記(1)乃至(10)のいずれかに記載の情報処理装置。
(13)
前記表示制御部は、前記注目エリアにおける前記乗客の平均乗車時間とその信頼区間とを、予測結果として前記表示部に表示させる
前記(1)乃至(10)のいずれかに記載の情報処理装置。
(14)
前記表示制御部は、分割した前記複数のエリアのうち、隣接する複数エリアの乗車数が所定の閾値以下となる前記複数エリアについては、1つのエリアとして結合して、前記予測結果を前記表示部に表示させる
前記(1)乃至(10)のいずれかに記載の情報処理装置。
(15)
進行方向に存在する乗車需要の高い場所を音で通知する通知部をさらに備える
前記(1)乃至(14)のいずれかに記載の情報処理装置。
(16)
前記通知部は、前記エリア単位に、前記乗車需要の高い場所を通知する
前記(15)に記載の情報処理装置。
(17)
前記通知部は、前記表示部に表示される前記予測結果の縮尺に応じて音の種類を変えて、乗車需要の高い場所を通知する
前記(15)または(16)に記載の情報処理装置。
(18)
前記通知部は、前記乗車需要の高い場所までの距離に応じて音の種類を変えて、前記乗車需要の高い場所を通知する
前記(15)乃至(17)のいずれかに記載の情報処理装置。
(19)
前記通知部は、前記乗車需要の大きさに応じて音の種類を変えて、前記乗車需要の高い場所を通知する
前記(15)乃至(18)のいずれかに記載の情報処理装置。
(20)
前記通知部は、前記乗車需要の高い場所を通過する毎に音で通知する
前記(15)乃至(19)のいずれかに記載の情報処理装置。
(21)
前記通知部は、「実車」または「空車」のステータスに連動して、通知をオンオフする 前記(15)乃至(20)のいずれかに記載の情報処理装置。
(22)
前記音は、効果音または音声メッセージである
前記(15)乃至(21)のいずれかに記載の情報処理装置。
(23)
前記通知部は、さらに、電車の運行情報、イベント情報、天気情報の少なくとも一つを、音声メッセージで通知する
前記(15)乃至(22)のいずれかに記載の情報処理装置。
(24)
前記表示制御部は、乗車需要を予測した予測結果に基づくおすすめのルートを、前記表示部に表示させる
前記(1)乃至(23)のいずれかに記載の情報処理装置。
(25)
前記表示制御部は、設定された目的地に向かうルートを探索し、前記おすすめのルートとして、前記表示部に表示させる
前記(24)に記載の情報処理装置。
(26)
前記目的地は、ドライバが得意とするエリアまたは場所である
前記(25)に記載の情報処理装置。
(27)
前記ドライバが得意とするエリアは、前記ドライバが移動した時間が所定値以上のエリアである
前記(26)に記載の情報処理装置。
(28)
前記ドライバが得意とするエリアは、前記ドライバが乗客を乗せた時間が所定値以上のエリアである
前記(26)または(27)に記載の情報処理装置。
(29)
前記ドライバが得意とするエリアの表示単位は、市区町村であり、
前記ドライバが得意とする場所の表示単位は、乗車数が多い乗車位置である
前記(26)乃至(28)のいずれかに記載の情報処理装置。
(30)
前記表示制御部は、現在地の周辺で、乗車需要が予測される場所を通過するルートを探索し、前記おすすめのルートとして、前記表示部に表示させる
前記(24)に記載の情報処理装置。
(31)
前記表示制御部は、通過するルートのスコアを合計した合計スコアが高いルートを、前記おすすめのルートとして、前記表示部に表示させる
前記(24)乃至(30)のいずれかに記載の情報処理装置。
(32)
前記合計スコアは、乗車需要のレベルに基づく前記エリア毎の前記スコアを合計して算出される
前記(31)に記載の情報処理装置。
(33)
前記合計スコアは、乗車需要が予測される場所毎の前記スコアを合計して算出される
前記(31)に記載の情報処理装置。
(34)
対向車線を横断する必要がある場所の前記スコアは、対向車線を横断する必要がない場所の前記スコアよりも低く設定される
前記(31)乃至(33)のいずれかに記載の情報処理装置。
(35)
乗客の移動方向の予測結果と、目的地の方向とが近いほど、前記スコアが大きい
前記(31)乃至(34)のいずれかに記載の情報処理装置。
(36)
前記おすすめのルートを探索する際の所定のエリアの前記乗車需要を予測する予測時刻が、現在地からの距離に応じて変更される
前記(24)乃至(35)のいずれかに記載の情報処理装置。
(37)
前記乗車需要の予測台数が、空車の営業車両の台数以上のルートを、前記おすすめのルートとして表示させる
前記(24)乃至(36)のいずれかに記載の情報処理装置。
(38)
前記表示制御部は、乗車禁止地区をさらに前記表示部に表示させる
前記(1)乃至(37)のいずれかに記載の情報処理装置。
(39)
前記表示制御部は、「付け待ち」が行われる場所をさらに前記表示部に表示させる
前記(1)乃至(38)のいずれかに記載の情報処理装置。
(40)
前記表示制御部は、前記「付け待ち」が行われる場所を使用可能な会社の名前を、さらに前記表示部に表示させる
前記(39)に記載の情報処理装置。
(41)
前記表示制御部は、前記営業車両が使用可能な他の「付け待ち」が行われる場所を、さらに前記表示部に表示させる
前記(39)または(40)に記載の情報処理装置。
(42)
前記表示制御部は、前記表示部に表示された地図上の駅の電車時刻を、さらに表示させる
前記(1)乃至(41)のいずれかに記載の情報処理装置。
(43)
前記表示制御部は、複数の前記駅の電車時刻を、到着時刻順、または、自車位置から前記駅までの距離順でリスト表示させる
前記(42)に記載の情報処理装置。
(44)
前記表示制御部は、指定された場所を乗客の行き先として、乗車した乗車点のみを表示させる
前記(1)乃至(43)のいずれかに記載の情報処理装置。
(45)
前記表示制御部は、複数の前記行き先を表示させ、選択された前記行き先の乗車点のみを表示させる
前記(44)に記載の情報処理装置。
(46)
前記表示制御部は、「配車」、「流し」、および「付け待ち」の乗車方法の違いを区別して、乗車の需要予測をさらに前記表示部に表示させる
前記(1)乃至(45)のいずれかに記載の情報処理装置。
(47)
前記表示制御部は、「配車」、「流し」、および「付け待ち」の乗車方法単位で、前記乗車の需要予測の表示をオンオフさせる
前記(46)に記載の情報処理装置。
(48)
前記表示制御部は、前記注目エリアにおける前記乗客の平均乗車料金とその信頼区間とを、予測結果として前記表示部に表示させる
前記(1)乃至(47)のいずれかに記載の情報処理装置。
(49)
前記表示制御部は、所定の乗車位置における前記乗客の平均乗車料金とその信頼区間とを、予測結果として前記表示部に表示させる
前記(1)乃至(47)のいずれかに記載の情報処理装置。
(50)
前記表示制御部は、リアルタイムの空車情報をさらに前記表示部に表示させる
前記(1)乃至(49)のいずれかに記載の情報処理装置。
(51)
前記表示制御部は、前記空車情報として、前記エリア毎の空車台数を表示させる
前記(50)に記載の情報処理装置。
(52)
前記表示制御部は、前記空車情報として、空車の前記営業車両のアイコンを表示させる
前記(50)または(51)のいずれかに記載の情報処理装置。
(53)
前記表示制御部は、1日の営業の終了後に、その日の営業を評価する営業評価情報を、さらに前記表示部に表示させる
前記(1)乃至(52)のいずれかに記載の情報処理装置。
(54)
前記表示制御部は、前記営業評価情報の一部として、実際の売り上げと、仮想の売り上げとを表示させる
前記(53)に記載の情報処理装置。
(55)
前記表示制御部は、前記営業評価情報の一部として、実車と空車のステータスを含む運行経路を表示させる
前記(53)または(54)に記載の情報処理装置。
(56)
前記表示制御部は、付加情報の距離または方角に応じて、前記付加情報を前記表示部の地図上にさらに表示させる
前記(1)乃至(55)のいずれかに記載の情報処理装置。
(57)
前記表示制御部は、進行方向の情報を、進行方向の逆方向の情報よりも、表示される情報量が多くなるように前記表示部に表示させる
前記(1)乃至(56)のいずれかに記載の情報処理装置。
(58)
情報処理装置が、
営業車両の営業地域を複数のエリアに分割して、エリア毎の乗車需要を予測した前記複数のエリアのうち、注目する前記エリアである注目エリアの乗客の移動方向および移動距離を、予測結果として表示部に表示させる
情報処理方法。
(59)
コンピュータに、
営業車両の営業地域を複数のエリアに分割して、エリア毎の乗車需要を予測した前記複数のエリアのうち、注目する前記エリアである注目エリアの乗客の移動方向および移動距離を、予測結果として表示部に表示させる
処理を実行させるためのプログラム。
【符号の説明】
【0423】
1 予測システム, 11 タクシー, 12 サーバ, 22 車両管理装置, 23 端末装置, 63 需要予測メッシュ, 121 制御部, 131 データ生成部, 132 学習部, 133 予測部, 141 制御部, 142 操作部, 143 表示部, 145 スピーカ, 146 マイクロホン, 211 注目エリア枠, 212 矢印, 221 ピンポイント乗車位置マーク, 222 乗車数表示, 223 付け待ち開始ボタン, 224 付け待ち表示, 241 ロング表示, 251 乗車距離表示, 261 個別表示, 262 目的地表示, 301 CPU, 302 ROM, 303 RAM, 306 入力部, 307 出力部, 308 記憶部, 309 通信部, 310 ドライブ, 521 乗車禁止地区表示, 531 付加情報表示部, 551 付け場所表示, 553 詳細情報, 581 リスト表示部, 582 ソートボタン, 601 逆引き乗車点表示部, 641 付け表示ボタン, 642 流し表示ボタン, 643 配車表示ボタン, 711 乗車料金表示, 741 エリア情報表示部, 742 空車情報, 751 アイコン, 812 評価点数表示, 813 レーダチャート, 814 営業収入グラフ, 815 ルート履歴表示ボタン, 821,822 実線, 831,832 付加情報