JP2023017285A - 相乗りタクシーシステム - Google Patents
相乗りタクシーシステム Download PDFInfo
- Publication number
- JP2023017285A JP2023017285A JP2021121433A JP2021121433A JP2023017285A JP 2023017285 A JP2023017285 A JP 2023017285A JP 2021121433 A JP2021121433 A JP 2021121433A JP 2021121433 A JP2021121433 A JP 2021121433A JP 2023017285 A JP2023017285 A JP 2023017285A
- Authority
- JP
- Japan
- Prior art keywords
- data
- boarding
- taxi
- shared
- time
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
- 238000012545 processing Methods 0.000 claims abstract description 72
- 230000005540 biological transmission Effects 0.000 claims abstract description 16
- 230000029305 taxis Effects 0.000 claims description 14
- 238000000034 method Methods 0.000 description 31
- 238000004364 calculation method Methods 0.000 description 30
- 230000008569 process Effects 0.000 description 21
- 238000012790 confirmation Methods 0.000 description 17
- 238000010586 diagram Methods 0.000 description 16
- 230000008859 change Effects 0.000 description 15
- 230000002195 synergetic effect Effects 0.000 description 12
- 239000013598 vector Substances 0.000 description 4
- 238000004891 communication Methods 0.000 description 3
- 238000012986 modification Methods 0.000 description 3
- 230000004048 modification Effects 0.000 description 3
- 230000008901 benefit Effects 0.000 description 2
- 230000004044 response Effects 0.000 description 2
- 230000015572 biosynthetic process Effects 0.000 description 1
- 239000000470 constituent Substances 0.000 description 1
- 238000010801 machine learning Methods 0.000 description 1
- 239000000463 material Substances 0.000 description 1
- 238000010295 mobile communication Methods 0.000 description 1
Images
Abstract
【課題】相乗り走行ルートを作成後に、所定の条件を満足しない場合に、クラスタリングを再度行い、相乗り走行ルートを再度作成する相乗りタクシーシステムを提供する。【解決手段】相乗りタクシーサービスにおいて、相乗りタクシーシステム10は、相乗りを希望する複数の利用者の乗降要望データを受信する受信部24、乗降要望データに基づいて、配車計画を生成する配車計画部20及び配車計画をタクシー会社に送信する送信部25を有する。配車計画部20は、乗降要望データが有する乗車情報又は降車情報の類似性に基づいて、複数の乗降要望データをグループ化し、配車するタクシーを1台ずつ割当て、タクシー1台に乗る人数が所定数以下となるようにクラスタを生成するクラスタリングを行うクラスタリング部21と、クラスタに対して、相乗り走行ルートを作成し、走行ルートに基づいて、配車計画を生成する配車計画処理部22を有する。【選択図】図3
Description
本開示は、相乗りタクシーシステムに関する。
タクシーを利用する場合に、出発地或いは目的地が同じである場合、相乗りをして低額でタクシーを利用したいという要望が存在する。相乗りタクシーを提供するためには、出発地或いは目的地が同じタクシー利用者のデータを収集し、出発地或いは目的地と乗降時刻等でデータをマッチングし、得られたデータに対して、走行ルートを算出する必要がある。
特許文献1には、顧客とタクシー会社とを連携するコールセンターシステムによって、受け付けた予約情報から、出発地、目的地及び乗車予約時刻それぞれのマッチングをとるマッチング検索と、マッチングによって得られた結果をグループ化したデータを生成するグループ化データ生成を行うタクシー相乗り支援システムが開示されている。
タクシーの利用形態として、利用時間によって料金が決められている時間貸しの形態がある。料金計算が容易となる点を生かして、相乗りタクシーを仲介する場合に、タクシーの時間貸しを利用する場合がある。しかし、タクシー時間貸しの場合、相乗り走行ルートを作成しても一定時間を超えるとタクシーの貸出料金が上がるため、料金コストが高くなる場合がある。特許文献1のタクシー相乗り支援システムでは、タクシー時間貸しの時間条件に限らず、相乗り走行ルートを作成した後、所定の条件を満足するかどうかについては考慮されていない。
本開示の目的は、相乗り走行ルートを作成した後、タクシー時間貸しの時間条件等の所定の条件を満足しない場合に、クラスタリングを再度行い、相乗り走行ルートを再度作成する相乗りタクシーシステムを提供することにある。
本開示に係る相乗りタクシーシステムは、相乗りを希望する複数の利用者の乗降要望データを受信する受信部と、乗降要望データに基づいて、配車計画を生成する配車計画部と、配車計画をタクシー会社に送信する送信部とを有する。配車計画部は、乗降要望データが有する乗車情報又は降車情報の類似性に基づいて、複数の乗降要望データをグループ化し、配車するタクシーを1台ずつ割当て、タクシー1台に乗る人数が所定数以下となるようにクラスタを生成するクラスタリングを行うクラスタリング部と、クラスタに対して、相乗り走行ルートを作成し、走行ルートに基づいて、配車計画を生成する配車計画処理部を有する。配車計画処理部は、クラスタ毎の相乗り走行時間が一定時間以上の場合には、配車するタクシーの台数を増やして、再度クラスタリングを行うことを特徴とする。
本開示に係る相乗りタクシーシステムは、クラスタ毎の相乗り走行時間が一定時間以上の場合に、配車するタクシーの台数を増やして、再度クラスタリングを行うことで、所定の条件を満足する相乗り走行ルートを作成することができる。
以下、本開示の実施形態について、図面を参照しながら詳細に説明する。以下の説明において、具体的な形状、材料、方向、数値等は、本開示の理解を容易にするための例示であって、用途、目的、仕様等に合わせて適宜変更することができる。また、以下で説明する実施形態および変形例の構成要素を選択的に組み合わせることは当初から想定されている。
[定義]
本開示において、「クラスタリング」とは、データ間の類似度にもとづいて、データをグループ分けする手法を言い、クラスタリングによってできた、似たもの同士が集まったグループのことを「クラスタ」と呼ぶ。
本開示において、「クラスタリング」とは、データ間の類似度にもとづいて、データをグループ分けする手法を言い、クラスタリングによってできた、似たもの同士が集まったグループのことを「クラスタ」と呼ぶ。
[システム構成]
図1は、本開示の相乗りタクシーシステム10を使用して、相乗りタクシーサービスを提供する全体構成図である。相乗りタクシーシステム10は、ネットワーク300を介して、相乗りについての乗車地、乗車日時、降車地、降車日時等の要望である乗降要望データをユーザー端末100から受信し、相乗りのためのタクシーのオーダー情報を兼ねる配車計画を外部のタクシー会社に設置されるコンピュータ200に送信することで、相乗りタクシーサービスを実現している。
図1は、本開示の相乗りタクシーシステム10を使用して、相乗りタクシーサービスを提供する全体構成図である。相乗りタクシーシステム10は、ネットワーク300を介して、相乗りについての乗車地、乗車日時、降車地、降車日時等の要望である乗降要望データをユーザー端末100から受信し、相乗りのためのタクシーのオーダー情報を兼ねる配車計画を外部のタクシー会社に設置されるコンピュータ200に送信することで、相乗りタクシーサービスを実現している。
ユーザー端末100は、相乗りタクシーの利用希望者が、相乗りの乗降要望データを、相乗りタクシーシステム10に送信する端末である。ユーザー端末100は、利用者毎に複数の端末が存在し、例えば携帯端末100Aは、移動体通信網を介して、ネットワーク300と接続されている。或いは、ユーザー端末100は、ネットワーク300に接続されたコンピュータ100Bの場合もある。
コンピュータ200は、外部のタクシー会社に設置され、相乗りタクシーシステム10から、配車計画を送信する外部システムである。コンピュータ200の構成については、本開示では限定しない。
[システムのハードウェア構成]
図2に、相乗りタクシーシステム10のハードウェア構成図の一例を示す。相乗りタクシーシステム10は、CPU(中央処理装置)11,入力装置12,出力装置13,記憶装置14,通信装置15を有している。CPU11は、種々の演算と各装置の制御を行う。入力装置12は、外部からデータの入力を行う。出力装置13は、外部へのデータの出力を行う。記憶装置14は、プログラム及びデータの記憶、外部から入力されたデータの記憶等を行う。通信装置15は、ネットワーク300を介して、外部システムとのデータの送受信を行う。これら各装置はバス16で互いに接続され、データのやり取りを行う。図2で示した各装置が協働して動作することで、相乗りタクシーシステム10として動作する。
図2に、相乗りタクシーシステム10のハードウェア構成図の一例を示す。相乗りタクシーシステム10は、CPU(中央処理装置)11,入力装置12,出力装置13,記憶装置14,通信装置15を有している。CPU11は、種々の演算と各装置の制御を行う。入力装置12は、外部からデータの入力を行う。出力装置13は、外部へのデータの出力を行う。記憶装置14は、プログラム及びデータの記憶、外部から入力されたデータの記憶等を行う。通信装置15は、ネットワーク300を介して、外部システムとのデータの送受信を行う。これら各装置はバス16で互いに接続され、データのやり取りを行う。図2で示した各装置が協働して動作することで、相乗りタクシーシステム10として動作する。
<第1の実施形態>
図3に、第1の実施形態の相乗りタクシーシステム10の機能ブロック図を示す。相乗りタクシーシステム10は、配車計画部20と受信部24と送信部25を有する。受信部24はネットワーク300と接続されており、相乗りを希望する利用者のユーザー端末100から乗降要望データを受信する。送信部25はネットワーク300と接続されており、相乗りの配車計画を外部のタクシー会社のコンピュータ200に送信する。相乗りタクシーシステム10は、更に配車計画部20が生成する種々のデータや受信部24が受信したデータを記憶するための記憶部23、料金算出処理部31、情報通知処理部32、オーダー処理部33等、他の機能ブロックを備えていてもよい。
図3に、第1の実施形態の相乗りタクシーシステム10の機能ブロック図を示す。相乗りタクシーシステム10は、配車計画部20と受信部24と送信部25を有する。受信部24はネットワーク300と接続されており、相乗りを希望する利用者のユーザー端末100から乗降要望データを受信する。送信部25はネットワーク300と接続されており、相乗りの配車計画を外部のタクシー会社のコンピュータ200に送信する。相乗りタクシーシステム10は、更に配車計画部20が生成する種々のデータや受信部24が受信したデータを記憶するための記憶部23、料金算出処理部31、情報通知処理部32、オーダー処理部33等、他の機能ブロックを備えていてもよい。
配車計画部20は、乗降要望データに基づいて、配車計画を生成する。配車計画部20は、クラスタリング部21と配車計画処理部22を有しており、配車計画部20は、これらによって、具体的な処理を行う。
クラスタリング部21は、受信部24から乗降要望データを受けとる。クラスタリング部21は、乗降要望データが有する乗車情報又は降車情報の類似性に基づいて、複数の乗降要望データをグループ化する。更に、クラスタリング部21は、タクシー1台に乗る人数が所定数以下となるようにクラスタを生成するクラスタリングを行う。クラスタリング部21は、グループ化された各グループに対してクラスタリングを行う。
配車計画処理部22は、クラスタリング部21が生成したクラスタ毎に配車計画を生成する。配車計画処理部22は、クラスタに含まれる乗降要望データに基づいて、相乗りの経路を表す相乗り走行ルートを作成する。作成した相乗り走行ルートに基づいて算出した値に、所定の条件を満足しないデータがある場合には、相乗りに不適なクラスタであると判断して、配車するタクシーの台数を増やして、即ち、グループ内のクラスタの総数を増やして、再度クラスタリングを行う。
受信部24は、ネットワーク300と接続されて、外部からのデータを受信する。本実施形態における受信部24は、ユーザー端末100からの乗降要望データを受信する。また受信部24は、タクシー会社のコンピュータ200からの配車オーダーに対する返信を受信する。受信部24は、外部からデータを受信すると、記憶部23へデータを保存する。
送信部25は、配車計画をタクシー会社のコンピュータ200へ送信する。また、ユーザー端末から受信した乗降要望データに対して、予約確認データを送信する。
料金算出処理部31は、配車計画に基づいて、相乗り利用者毎の料金を算出する。本実施形態の料金算出処理部31は、相乗りの乗降要望データに対する変更、キャンセルの処理も行うように構成されている。
情報通知処理部32は、ユーザー端末100へ、相乗りの予約受付時及び変更の受付時の予約確認データの送信及び乗降要望データがキャンセルされた場合の応答とキャンセル料金の送信を送信部25を介して行う。
オーダー処理部33は、配車計画を送信部25を介して、タクシー会社のコンピュータ200へ送信する。
[データ構造について]
図4~図11を参照して、相乗りタクシーシステム10が相乗りの配車計画を生成する過程で生成するデータの構造を示しながら、乗降要望データをグループ化し、クラスタリングして、相乗り走行ルート及び配車計画を生成する一連の処理について説明する。本開示においてデータの構造は、縦に項目、横にデータ内容を表記した表によって示すこととする。縦一列が1つのまとまったデータであり、異なる複数のデータが存在する場合は、横に連続して表示する。
図4~図11を参照して、相乗りタクシーシステム10が相乗りの配車計画を生成する過程で生成するデータの構造を示しながら、乗降要望データをグループ化し、クラスタリングして、相乗り走行ルート及び配車計画を生成する一連の処理について説明する。本開示においてデータの構造は、縦に項目、横にデータ内容を表記した表によって示すこととする。縦一列が1つのまとまったデータであり、異なる複数のデータが存在する場合は、横に連続して表示する。
[乗降要望データ]
図4は、ユーザー端末100から受信した乗降要望データ121の構造を示している。乗降要望データ121の項目は、縦に予約受付No、(予約の)種類、乗車地、乗車日時、降車地、降車日時、希望時間、希望料金、相乗条件1、2等から構成されている。予約受付Noは、相乗りタクシーシステム10が、乗降要望データ121を受付けたときに割付ける番号であり、他のデータと区別する識別番号の意味を持つ。乗降要望データ121には、図4(a)、(b)に示す新規のデータ121a、121bと、図4(c)に示す変更のデータ121cと、図4(d)に示すキャンセルのデータ121dがある。変更のデータ121cとキャンセルのデータ121dには、種類の項目にそれぞれ、変更、キャンセルの文字データが入力されている。変更のデータ121c、キャンセルのデータ121dの種類の項目には、前回の予約受付Noが入力されている。
図4は、ユーザー端末100から受信した乗降要望データ121の構造を示している。乗降要望データ121の項目は、縦に予約受付No、(予約の)種類、乗車地、乗車日時、降車地、降車日時、希望時間、希望料金、相乗条件1、2等から構成されている。予約受付Noは、相乗りタクシーシステム10が、乗降要望データ121を受付けたときに割付ける番号であり、他のデータと区別する識別番号の意味を持つ。乗降要望データ121には、図4(a)、(b)に示す新規のデータ121a、121bと、図4(c)に示す変更のデータ121cと、図4(d)に示すキャンセルのデータ121dがある。変更のデータ121cとキャンセルのデータ121dには、種類の項目にそれぞれ、変更、キャンセルの文字データが入力されている。変更のデータ121c、キャンセルのデータ121dの種類の項目には、前回の予約受付Noが入力されている。
図4(a)、(b)に示すように、新規のデータ121a、121bの場合は、予約受付Noは未定である。乗車地から降車日時までの項目は、相乗り走行ルートを作成する際に使用される項目である。希望時間、希望料金、相乗条件1、2は、必須の条件ではない。例えば、相乗条件の例としては、相乗りする同乗者の性別や人数の条件などがある。他には、相乗りによる走行時間の制限、料金などの条件がある。これらは必ずしもすべての項目が必要ではなく、提供する相乗りタクシーサービス内容に応じて調整することができる。相乗条件の利用については、後述する。
図4(a)のデータ121aのデータ内容と、図4(b)のデータ121bのデータ内容を比較すると、乗車地と降車地が入れ替わっていることが分かる。乗車日時と降車日時は異なっている。データ121aは、利用者が住所Aから住所Xへ行くときの乗降要望データ121であり、データ121bは、住所Xから住所Aへ帰るときの乗降要望データ121となっているためである。
相乗りタクシーシステム10は、予約の受付状況(乗降要望データの受付状況)を確認のために、ユーザー端末100へ向けて予約確認データを送信する。図5は、ユーザー端末100へ送信する予約確認データ122のデータ構造の一例である。利用者は、ユーザー端末100で、予約確認データを確認して、相乗り予約の状況を確認することができる。
予約確認データ122の項目は、縦に予約受付No、乗車地、乗車日時、降車地、降車日時、相乗り人数、料金、タクシー情報、経路情報となっている。予約受付Noから降車日時までは、乗降要望データ121の項目と共通している。相乗り人数は、相乗りするときの本人を含む同乗者の人数である。料金は、相乗りにかかる利用料金、タクシー情報は、配車されるタクシー会社名が入力されている。経路情報は、相乗りの経路を示す情報であり、ユーザー端末100上では、地図画面へのリンクとなっている。経路情報のリンクから地図アプリが開き、実際に走行する相乗り走行ルートが地図上で表示されるように構成されている。尚、経路情報の形式は一例であり、他の形式であってもよい。
図6は、相乗りタクシーシステム10において、複数の乗降要望データ121が蓄積された状態を示している。基本的に単独の乗降要望データ121と変わらないが、乗降要望データ121に、利用者情報が追加されている。利用者情報は、利用者の氏名、年齢、性別、当該システムへの登録ID番号等の複数の項目に分かれていてもよい。利用者情報を付加する理由は、相乗り走行ルートを作成した場合に、乗降者の情報が必要な為である。後述するように、配車計画には、乗車地においての乗車者、又は降車地においての降車者の情報が付加されるが、乗車者、降車者の情報として、利用者情報が使われる。相乗りタクシーの運転手は、乗降地において乗降する利用者を利用者情報によって確認することができる。
乗車地、降車地には住所情報が入力されている。住所情報は、住所を表す文字情報でもよいし、緯度経度の数値データでもよい。更に乗降地における建物情報などが追加されていてもよい。相乗りタクシーの走行において、乗降地の確認を助ける情報などが付加されるようにしてもよい。
図6に示す複数の乗降要望データ121に入力されているデータについて見てみる。予約受付Noの001~003のデータは、何れも降車地と降車日時が同じである。このデータは、利用者A、B、Cがそれぞれ別の乗車地から同一の降車地へ行きたい要望を示している。具体的な状況としては、学習塾へ行く場合が考えられる。例えば、同一の学習塾で同じ時間帯の授業を受ける利用者が想定される。よって、予約受付Noの001~003の利用者は相乗りタクシーを利用できる可能性が高いと言える。
次に、予約受付Noの011~013は、予約受付Noの001~003と同じ利用者A、B、Cが、同じ乗車地と乗車日時を要望しているデータとなっている。降車地について見ると、予約受付Noが011の降車地は、予約受付Noが001の乗車地と同じ住所Aである。予約受付Noが012の降車地は、予約受付Noが002の乗車地と同じ住所B、予約受付Noが013の降車地は、予約受付Noが003と同じ住所Cである。先ほどの例でいえば、学習塾の授業が終わって、一斉に帰宅する場合が考えられる。以上に示した状況はあくまで例示であって、他の状況が当然に考えうる。降車地が同じ場合には、人が多く集まる施設などへ行くときの利用が考えられる。乗車地が同じ場合は、その施設から自宅へ帰る場合の利用が考えられる。
[乗降要望データのグループ化]
次に複数の乗降要望データ121をグループ化する処理について説明する。図7は、図6と同じデータを基にグループ化する方法を説明する図である。本実施形態のグループ化の手法としては、乗車地と乗車日時が同じ乗降要望データ121を一つのグループにまとめる。また、降車地と降車日時が同じ乗降要望データ121を一つのグループにまとめる。そして、グループ毎にデータの先頭にGroupNoを付加している。このようにして、同じグループには、同じGroupNoを付して生成されたのが図7のデータである。図7の例では、予約受付Noが001~003のデータが、GroupNoが001としてグループ化され、また、予約受付Noが011~013のデータが、GroupNoが002としてグループ化された様子を示している。即ち、図7に示すデータにおいては、GourpNoが001のデータは、降車地が住所Xで、降車日時が日時X1と何れも同じデータである。GroupNoが002のデータは、乗車地が住所Xで、乗車日時が日時X3と同じデータである。
次に複数の乗降要望データ121をグループ化する処理について説明する。図7は、図6と同じデータを基にグループ化する方法を説明する図である。本実施形態のグループ化の手法としては、乗車地と乗車日時が同じ乗降要望データ121を一つのグループにまとめる。また、降車地と降車日時が同じ乗降要望データ121を一つのグループにまとめる。そして、グループ毎にデータの先頭にGroupNoを付加している。このようにして、同じグループには、同じGroupNoを付して生成されたのが図7のデータである。図7の例では、予約受付Noが001~003のデータが、GroupNoが001としてグループ化され、また、予約受付Noが011~013のデータが、GroupNoが002としてグループ化された様子を示している。即ち、図7に示すデータにおいては、GourpNoが001のデータは、降車地が住所Xで、降車日時が日時X1と何れも同じデータである。GroupNoが002のデータは、乗車地が住所Xで、乗車日時が日時X3と同じデータである。
GroupNoが001の予約受付Noが異なる3つのデータの乗車地は異なっている。これは利用者が異なるためで、それぞれ異なる乗車地から、同じ降車地である住所Xへ行くのに相乗りタクシーを利用したい利用者を1つのグループにまとめていることになる。GroupNoが002の予約受付Noが異なる3つのデータは乗車地と乗車日時が同じであり、降車地が異なっている。これは同じ乗車地からそれぞれ異なる降車地へ行くのに相乗りタクシーを利用したい利用者を1つのグループにまとめていることになる。尚、グループ化された各グループのデータの数は、本例の3つに限らない。同じ乗車地と乗車日時、又は同じ降車地と降車日時を有する乗降要望データは全て1つのグループにまとめることになる。
上述の例では、乗降要望データが有する乗車情報又は降車情報の類似性に基づいて、複数の乗降要望データをグループ化する一例として、乗車地と乗車日時が同じ乗降要望データ、或いは降車地と降車日時が同じ乗降要望データをグループ化したが、完全に同じでなくてもよい。乗車地と乗車日時が近似する乗降要望データ、或いは降車地と降車日時が近似する乗降要望データをグループ化するようにしてもよい。グループ化する乗降要望データの近似の度合いについては、提供する相乗りサービスに応じて適宜設定する。
本実施形態の相乗りタクシーシステム10は、複数の乗降要望データをグループ化した後、グループ内のデータをクラスタリングして、少数のデータから成るクラスタに分け、クラスタ毎にタクシーを1台割当てた配車計画を作成する。以下に順を追って説明する。
[クラスタリング処理]
図8(a)は、1つのグループに含まれる全ての乗降要望データについて、降車地を地図上に配置したときの図を示している。当該グループに含まれる乗降要望データは、同じ乗車地から利用者それぞれの降車地で降りる場合のデータとなっている。地図の略中央で他とは形の異なる図形を配置した地点Oは、乗車地(出発地)を示している。即ち、図8(a)に示すマップは、同じ日時に乗車地を示す地点Oから、相乗りタクシーを利用して行きたい降車地の分布を示している。よって、これらの降車地をクラスタリングして、クラスタ毎に走行ルートを作成することで、相乗り走行ルートが作成されることになる。以下に示すのは、1つの手法であって、他の手法で走行ルートを作成することを除外するものではない。
図8(a)は、1つのグループに含まれる全ての乗降要望データについて、降車地を地図上に配置したときの図を示している。当該グループに含まれる乗降要望データは、同じ乗車地から利用者それぞれの降車地で降りる場合のデータとなっている。地図の略中央で他とは形の異なる図形を配置した地点Oは、乗車地(出発地)を示している。即ち、図8(a)に示すマップは、同じ日時に乗車地を示す地点Oから、相乗りタクシーを利用して行きたい降車地の分布を示している。よって、これらの降車地をクラスタリングして、クラスタ毎に走行ルートを作成することで、相乗り走行ルートが作成されることになる。以下に示すのは、1つの手法であって、他の手法で走行ルートを作成することを除外するものではない。
まず始めに図8(b)に示すように、乗降要望データに含まれる住所情報から、出発地(地点O)から各乗降要望データの降車地へのベクトルを計算する。図8(b)に、矢印で示すのが当該ベクトルである。
例えば、矢印の向きが近いデータは、出発地からの行き先の方向が近いことを意味し、相乗りのクラスタにすることに適する傾向がある。矢印の長さは出発地からの距離を意味し、矢印の向きが概ね近く、長さが段階的に異なるデータを選ぶようにすると、相乗り走行に適するクラスタとなる。このようにして、図8(a)の乗降要望データをクラスタリングしたものが、図8(c)の実線で囲んだデータである。図8(c)の破線は、出発地からの距離を段階的に示している。図8(c)は、CL1~CL6で示すクラスタが生成されたことを示している。尚、図8(a)~(c)で示した地図上の描画は、クラスタリングの過程を理解しやすいように図に示したものであって、実際に地図上にデータを描画して、クラスタを生成する必要はない。尚、本実施形態では、クラスタリングを行う際に、各クラスタに含まれる乗降要望データの数は、4以下となるように行う。これは相乗りする同乗者の最大人数であり、4人より多い場合には同乗が困難になるためである。クラスタに含まれる最大数は、相乗りタクシーを提供する車両の大きさにも関係するので、4人に限定されるものではない。
クラスタリング手法は、上述のクラスタリング手法に限らない。複数の乗降要望データからクラスタを生成する手法は、AIによる機械学習を適用することによって可能であるが、詳細は省略する。
[相乗り走行ルート]
次に、相乗りタクシーシステム10は、クラスタリングされた各クラスタに対して、相乗り走行ルートを作成する。図9(a)、(b)に作成した相乗り走行ルート124の一例を示す。図9(a)は、複数の乗車地で利用者を乗車させ、共通の到着地に相乗りする場合の相乗り走行ルート124aを示している。図9(b)は、共通の出発地から複数の利用者を載せて、それぞれ別の降車地で利用者を降ろす場合の相乗り走行ルート124bを示している。
次に、相乗りタクシーシステム10は、クラスタリングされた各クラスタに対して、相乗り走行ルートを作成する。図9(a)、(b)に作成した相乗り走行ルート124の一例を示す。図9(a)は、複数の乗車地で利用者を乗車させ、共通の到着地に相乗りする場合の相乗り走行ルート124aを示している。図9(b)は、共通の出発地から複数の利用者を載せて、それぞれ別の降車地で利用者を降ろす場合の相乗り走行ルート124bを示している。
相乗り走行ルート124aは、縦の先頭に配車Noが付加されている。続いて乗車地、乗車日時の項目が4つ続いて、到着地、到着日時、経路情報が付加されている。配車Noは、相乗りに配車されるタクシーの番号を意味している。配車Noが001のデータにおいては、4人の利用者がそれぞれの乗車地1~4で乗車して、到着地(住所X)で降車することを意味している。経路情報は相乗りの経路を示す情報である。経路情報の経路R1は、図5の経路情報と同じ構造のデータである。経路情報は、後にユーザー端末100とタクシー会社のコンピュータ200へ送信するために使用される。
配車Noが002のデータは、乗車地3から乗車日時4までの項目が空欄である。これは利用者が二人のためである。このように、利用者が4名未満の場合は、空欄となる項目が生じる。到着地以降のデータ項目については、配車Noが001の場合と同様である。配車Noが003以降のデータ項目についても、配車Noが001、002のデータと同様である。
図9(b)は、相乗り走行ルート124bの構造を示している。相乗り走行ルート124bは、相乗り走行ルート124aと異なり、出発地で複数の利用者がタクシーに乗って、それぞれの降車地でタクシーを降りるときの相乗りデータである。従って、配車Noに続いて、出発地、出発日時が項目となっている。その後に、降車地、降車日時の項目が4つ続いて、経路情報となっている。相乗り走行ルート124bの配車Noが011のデータは、4人の利用者が、出発地(住所X)で一斉にタクシーに乗車し、利用者それぞれが一人ずつ降車していくデータを意味している。経路情報の経路R11の内容は、相乗り経路を示す情報である。配車Noが012のデータは、乗車者が二人のため、降車地3から降車日時4までの項目は空欄である。
相乗り走行ルート124a、124bは、所定の条件を満足しないデータ(相乗りに適しないと判断するデータ)がある場合は、後述するように同一のグループ内の配車タクシーの台数を増やして(例えば1台増やして)、再度クラスタリングを行い、相乗り走行ルートを再度作成する。所定の条件を満足しないデータが無い場合には、配車計画に加工される。
[所定の条件に対する判断]
本実施形態の相乗りタクシーシステム10においては、相乗り走行ルートを作成した後、当該データに相乗りに適しないデータの存否を判断する。時間貸しで相乗りタクシーを利用している場合を例にして説明する。時間貸しで利用する場合に問題となるのは、利用時間が一定の貸出時間を超える毎に料金が高くなることである。従って、相乗りにタクシーを利用する時間が一定の貸出時間を超えないようにする必要がある。この場合、利用時間が一定の貸出時間を超えないことが所定の条件となる。以降、図9(a)の相乗り走行ルート124aの配車Noが001のデータの例で説明する。
本実施形態の相乗りタクシーシステム10においては、相乗り走行ルートを作成した後、当該データに相乗りに適しないデータの存否を判断する。時間貸しで相乗りタクシーを利用している場合を例にして説明する。時間貸しで利用する場合に問題となるのは、利用時間が一定の貸出時間を超える毎に料金が高くなることである。従って、相乗りにタクシーを利用する時間が一定の貸出時間を超えないようにする必要がある。この場合、利用時間が一定の貸出時間を超えないことが所定の条件となる。以降、図9(a)の相乗り走行ルート124aの配車Noが001のデータの例で説明する。
相乗りにタクシーを利用する時間は、相乗りの全ルートを走行するのに要する相乗り利用時間に相当し、乗車日時1である日時A1から到着日時である日時X1までの時間である。日時A1から日時X1までに要する時間をTAとし、時間貸しの料金が変わる時間をTaとすると、TA<Taを所定の条件とする。この条件を満足しない場合、貸出時間をオーバーするので、タクシー貸出料金が高くなり、相乗りに適しないと判断する。所定の条件TA<Taを満足しない場合には、当該相乗り走行ルートが含まれるグループに対して、タクシーの台数を増やして、再度クラスタリングを行う。クラスタには配車するタクシーが1台ずつ割当てられるので、配車するタクシーの台数を増やすことは、クラスタの総数を増やすことになり、再度クラスタリングすることで、相乗り利用時間TAを短くすることが可能となる。所定の条件を満足する場合には、配車計画を生成する。
所定の条件は、タクシーの時間貸しの貸出時間以外とすることも可能である。例えば、相乗りする場合と相乗りしない場合の時間の差(ロス時間と呼ぶ)が所定の時間を超えるか否かで判断してもよい。ロス時間とは、相乗りする場合に要する時間から単独でタクシーを利用した場合に要する時間との差である。このロス時間は、相乗りすることによって、余分にかかる時間であり、ロス時間が長い場合には、相乗りによるメリットを減少させることになる。
再び、図9(a)の相乗り走行ルート124aの配車Noが001のデータの例で説明する。配車Noが001のデータは、乗車地1~4の項目にデータが埋まっているので、利用者が4人いることになる。利用者のそれぞれが相乗りで要する時間は、到着日時の日時X1から利用者の乗車日時を引いた時間である。二番目のデータである乗車日時2のデータに対しては、日時X1-日時B1(T1とする)である。単独でタクシーを利用した時間に対してロス時間が発生するのは、他の利用者を乗車させるために経路を迂回する可能性があるためである。今、乗車地2で乗車する利用者について、ロス時間を算出する場合に、単独でタクシーを利用した時間(t1とする)を算出する必要があるが、この時間t1は、乗車地2の住所Bと到着地の住所Xとから、既存の経路算出手法を使用して算出することができる。ロス時間は、T1-t1となる。ロス時間の許容時間をTbとしたとき、(T1-t1)<Tbを所定の条件とする。この条件を満足しない場合には、相乗りによって許容時間以上の時間がかかっていることになり、利用者によっては相乗りのメリットを感じられない場合が発生する。所定の条件を満足しない場合には、当該相乗り走行ルートが含まれるグループに対して、タクシーの台数を増やして(クラスタの総数を増やして)、再度クラスタリングを行う。所定の条件を満足する場合には、配車計画を生成する。
[配車計画]
相乗り走行ルートに所定の条件を満足しないデータが無ければ、配車計画125を生成する。配車計画125は、タクシー会社にタクシーの配車を依頼するためのデータである。配車計画125には、図9(a)、(b)の相乗り走行ルート124a、124bに含まれる項目は全て含まれる。また、図9(a)、(b)の2種類の相乗り走行ルート124に対応して、配車計画125も2種類の構造を有する。図10(a)が、図9(a)に対応する配車計画125aであり、図10(b)が、図9(b)に対応する配車計画125bである。
相乗り走行ルートに所定の条件を満足しないデータが無ければ、配車計画125を生成する。配車計画125は、タクシー会社にタクシーの配車を依頼するためのデータである。配車計画125には、図9(a)、(b)の相乗り走行ルート124a、124bに含まれる項目は全て含まれる。また、図9(a)、(b)の2種類の相乗り走行ルート124に対応して、配車計画125も2種類の構造を有する。図10(a)が、図9(a)に対応する配車計画125aであり、図10(b)が、図9(b)に対応する配車計画125bである。
配車計画125aのデータ構造は、相乗り走行ルート124aに比べて、乗車地1~4のそれぞれに乗車する乗車者の情報が付加されている点で異なる。更に降車地での降車者の情報も付加されている。配車計画125bのデータ構成は、相乗り走行ルート124bに比べて、出発地において、乗車する乗車者の情報と降車地1~4毎に降車する降車者の情報が付加されている。これらの情報は、タクシー会社のドライバーにとって、乗降者を確認するために必要な情報となる。
[料金算出データ]
図11に、料金算出データ126のデータ構造を示す。料金算出データ126は、相乗りタクシーの各利用者毎に料金を算出したデータである。料金算出データ126は、縦先頭に配車No、続いて利用者、乗車地、乗車日時、降車地、降車日時、所要時間、単独時間、単独距離、単独料金、相乗人数、係数、料金、経路情報となっている。単独時間、単独距離、単独料金の項目は、必須の項目ではないが、相乗り利用の良し悪しを反映するデータであり、参考値として付加している。所要時間は、相乗りに乗車地から降車地までかかる予定時間である。単独時間は、相乗りをせず直接タクシーを利用したときの予測所要時間である。単独距離、単独料金は、直接タクシーを利用したときの距離と料金の予測である。相乗り人数は、相乗りで同乗する利用者の人数である。係数は、相乗りによる料金を算出するための係数であり、例えば、単独料金に係数を掛けることで相乗りの料金を決定するようにしている。経路情報は、配車計画125の経路情報と同じデータ構造である。図11においては、配車Noが001のデータが4つ示されているが、図10(a)の配車計画125aの配車Noが001のデータに含まれる4人の利用者A~Dのそれぞれに対して、料金を算出したデータに対応している。
図11に、料金算出データ126のデータ構造を示す。料金算出データ126は、相乗りタクシーの各利用者毎に料金を算出したデータである。料金算出データ126は、縦先頭に配車No、続いて利用者、乗車地、乗車日時、降車地、降車日時、所要時間、単独時間、単独距離、単独料金、相乗人数、係数、料金、経路情報となっている。単独時間、単独距離、単独料金の項目は、必須の項目ではないが、相乗り利用の良し悪しを反映するデータであり、参考値として付加している。所要時間は、相乗りに乗車地から降車地までかかる予定時間である。単独時間は、相乗りをせず直接タクシーを利用したときの予測所要時間である。単独距離、単独料金は、直接タクシーを利用したときの距離と料金の予測である。相乗り人数は、相乗りで同乗する利用者の人数である。係数は、相乗りによる料金を算出するための係数であり、例えば、単独料金に係数を掛けることで相乗りの料金を決定するようにしている。経路情報は、配車計画125の経路情報と同じデータ構造である。図11においては、配車Noが001のデータが4つ示されているが、図10(a)の配車計画125aの配車Noが001のデータに含まれる4人の利用者A~Dのそれぞれに対して、料金を算出したデータに対応している。
相乗りタクシーシステム10は、この料金算出データを基に、各利用者に対して、図5に示した予約確認データ122を、送信部25からユーザー端末100に送信する。
[再度のクラスタリング処理]
図12を参照して、相乗り走行ルートに所定の条件を満足しないデータが存在し、相乗りに適しないと判断した場合の再度のクラスタリング処理について説明する。図12(a)は、図8(c)と同様のクラスタリングを完了した直後の様子を示している。クラスタCL3に星印を付けたデータが、相乗りに不適のデータであるとする。この場合、クラスタCL3を分解して、全体のクラスタ数を1増やして、クラスタ数を7として、再度クラスタリングを行う。
図12を参照して、相乗り走行ルートに所定の条件を満足しないデータが存在し、相乗りに適しないと判断した場合の再度のクラスタリング処理について説明する。図12(a)は、図8(c)と同様のクラスタリングを完了した直後の様子を示している。クラスタCL3に星印を付けたデータが、相乗りに不適のデータであるとする。この場合、クラスタCL3を分解して、全体のクラスタ数を1増やして、クラスタ数を7として、再度クラスタリングを行う。
最も単純な再度のクラスタリングの方法は、相乗りに不適のデータがあるクラスタのデータを分割して、2つのクラスタに分けることである。クラスタの分割だけで、相乗りに不適のデータが無くならない場合には、隣接するクラスタを含めて、再度クラスタリングを試みる。或いは、図8(b)、(c)で説明した、出発地と降車地のベクトルの向きと大きさを基に、グループ全体のクラスタリングを行うようにしてもよい。この場合、クラスタの総数を増やしているため、クラスタに含まれるデータの数が少なくなるので、同様の手法で相乗りの不適なデータが無くなるようにクラスタリングすることが可能になる。図12(b)が再度のクラスタリングの結果の一例である。クラスタCL3が分割されて、クラスタCL7が新たに追加された状態となっている。
[相乗りタクシーシステムの処理シーケンス]
図13に示すシーケンス図によって、本実施形態の相乗りタクシーシステム10がユーザー端末100とタクシー会社のコンピュータ200との間で行う処理の一例について、データの授受と共に示す。図13で示すのは、ユーザー端末100で相乗り乗降要望を送信し、相乗りタクシーシステム10で相乗りのデータ処理を行い、ユーザー端末100に結果を送信し、タクシー会社のコンピュータ200に配車オーダーを送信するまでの一連の処理である。尚、図13の説明においては、相乗りタクシーシステム10については、単にシステム10と呼ぶ。
図13に示すシーケンス図によって、本実施形態の相乗りタクシーシステム10がユーザー端末100とタクシー会社のコンピュータ200との間で行う処理の一例について、データの授受と共に示す。図13で示すのは、ユーザー端末100で相乗り乗降要望を送信し、相乗りタクシーシステム10で相乗りのデータ処理を行い、ユーザー端末100に結果を送信し、タクシー会社のコンピュータ200に配車オーダーを送信するまでの一連の処理である。尚、図13の説明においては、相乗りタクシーシステム10については、単にシステム10と呼ぶ。
ステップS1において、ユーザー端末100から乗降要望データが送信され、システム10は、受信部24で当該データを受信する。次に、ステップS2において、システム10は、既に蓄積された乗降要望データとステップS1で受信したデータをマージした後、上述した、グループ化、クラスタリング、相乗り走行ルートの作成、配車計画の生成までを行う。
次に、ステップS3において、システム10は、コンピュータ200へ配車計画を送信する。配車計画は、図10で説明したデータである。次に、ステップS4において、コンピュータ200から送信される配車計画の受領返信を受信して、データ送信が正常に完了したことを確認する。その後、ステップS5において、システム10は、ユーザー端末100に向けて、予約受付No、経路情報、料金を含む予約確認データを送信する。予約確認データは、図4に示したデータである。
続いて、実際の相乗りタクシーの配車までに、予約の変更或いはキャンセルがあった場合のシーケンスについて説明する。
システム10は、予約の変更またはキャンセルの要望を、ユーザー端末100から乗降要望データとして受信する。ステップS6において、システム10が予約の変更またはキャンセルの乗降要望データを受信したとする。システム10は、次にステップS7において、予約変更、キャンセルの処理を行う。実際の処理は、乗降要望データの項目の種類に記入されているデータに基づいて行う。予約の変更である場合は、システム10内に既にある乗降要望データの中の予約受付Noが一致するデータを更新して、グループ化以降の処理を行い、配車計画を生成する。予約のキャンセルである場合は、予約受付Noが一致するデータを消去して、グループ化以降の処理を行い、配車計画を生成する。次に、ステップS8において、システム10は、コンピュータ200へ更新した配車計画を送信する。ステップS9において、コンピュータ200から送信される配車計画の受領返信を受信して、データ送信が正常に完了したことを確認する。その後、ステップS10において、システム10は、ユーザー端末100に向けて、更新した予約受付No、経路情報、料金を含む予約確認データを送信する。
相乗りタクシーの配車当日になると、システム10は、ステップS11において、配車確定情報をコンピュータ200に送信する。これ以降、システム10は、予約の変更、キャンセルを受付けないようにする。ステップS12において、システム10は、ユーザー端末100に向けて、当日の配車情報を送信する。この当日の配車情報は、既にユーザー端末100に送信している予約確認データと同じものである。尚、当日の配車確定情報と配車情報の送信は必須ではない。
次に相乗りタクシーシステム10において行われる処理のフローチャートを示す。ここで説明するフローチャートは、図3で示したクラスタリング部21、配車計画処理部22及び料金算出処理部31において処理される内容である。
[クラスタリング処理]
図14は、クラスタリング部21が行う処理のフローチャートである。クラスタリング部21は、複数の乗降要望データのグループ化とクラスタリング及び再度のクラスタリングの処理を行う。
図14は、クラスタリング部21が行う処理のフローチャートである。クラスタリング部21は、複数の乗降要望データのグループ化とクラスタリング及び再度のクラスタリングの処理を行う。
クラスタリング部21は、始めに乗降要望データを受信する(ステップS11)。乗降要望データには、予約の変更、キャンセルの乗降要望データを含んでいる(図中C)。乗降要望データは、記憶部23に記憶され蓄積される。次に蓄積された乗降要望データのグループ化を行う(ステップS12)。グループ化の詳細は、既に図7で説明しているので省略する。次に、クラスタリング部21は、グループデータについて、クラスタリングを行う(ステップS13)。クラスタリングには、後述する配車計画処理において、乗降時間が不適の場合の再度のクラスタリングを含む(図中Aからの処理)。図中Aから来た処理は再クラスタリングに該当し、タクシーの台数(クラスタ数)を1増やして(ステップS14)、クラスタリングの処理を行う(ステップS13)。クラスタリングが終了すると、クラスタリング部21の処理は終了する。尚、ステップS13のクラスタリングの後に、相乗条件調整(ステップS15)を行うようにしてもよい。相乗条件調整については、後述する。
[配車計画処理]
図15は、配車計画処理部22が行う処理のフローチャートである。配車計画処理部22は、クラスタリング部21が生成したクラスタに対して、相乗り走行ルートの作成、相乗りに適するか否かを判断するデータの算出、配車計画の生成、料金計算のためのマッチング係数の割当て等の処理を行う。
図15は、配車計画処理部22が行う処理のフローチャートである。配車計画処理部22は、クラスタリング部21が生成したクラスタに対して、相乗り走行ルートの作成、相乗りに適するか否かを判断するデータの算出、配車計画の生成、料金計算のためのマッチング係数の割当て等の処理を行う。
配車計画処理部22は、まず初めにクラスタデータに対して、相乗り走行ルートの作成を行い、各所要時間の算出を行う(ステップS21)。各所要時間とは、相乗りの全ルートを走行するのに要する相乗り利用時間TA、及び相乗り利用者毎のロス時間T1-t1である。まず、相乗り利用時間TAが所定の条件:TA<Taを満足するかどうかを判断する(ステップS22)。満足しない場合は、乗降時間の所定の条件を満足しない場合として、再度クラスタリングを行う(図中Aへ)。所定の条件を満足する場合は、次のステップS23へ進む。次は、ロス時間が所定の条件:(T1-t1)<Tbを満足するかどうかを判断する(ステップS23)。満足しない場合は、同様に再度クラスタリングを行う(図中Aへ)。満足する場合は、料金計算のためのマッチング係数を利用者毎に割り当てる処理を行う(ステップS24)。ステップS24の後は、料金算出処理へ処理を移行する(図中Bへ)。配車計画処理部22は、ステップS24と平行して、配車計画を生成する(ステップS25)。生成された配車計画は、情報通知処理部32及びオーダー処理部33へ送られ、必要な加工をされて、送信部25によってユーザー端末100とコンピュータ200へ送信される。
[料金算出処理]
図16は、料金算出処理部31が行う処理のフローチャートである。料金算出処理部31は、配車計画が生成された後に、相乗り料金の算出、乗降要望データの予約変更、キャンセルの有無の確認、キャンセルが発生した場合のキャンセル料金の算出等の処理を行う。
図16は、料金算出処理部31が行う処理のフローチャートである。料金算出処理部31は、配車計画が生成された後に、相乗り料金の算出、乗降要望データの予約変更、キャンセルの有無の確認、キャンセルが発生した場合のキャンセル料金の算出等の処理を行う。
料金算出処理部31は、まず始めに配車計画に基づいて、乗降距離に基づく料金算出を行う(ステップS31)。この料金算出は、図10の料金算出データで説明した、単独料金の算出が該当する。次に、算出した料金に対して、配車計画処理部(図中B)から受け取ったマッチング係数を乗算することで、料金を算出する(ステップS32)。以上で料金算出は完了であるが、本実施形態の料金算出処理部31は、更に予約の変更の有無(ステップS33)、キャンセルの有無(ステップS34)を確認する処理を行う。予約の変更がある場合は、予約変更の処理へ移行する(図中C)。これと並行して、ユーザー端末への変更受付データを作成し(ステップS35)、送信するために情報通知処理部32へ処理を移行する。キャンセルがある場合には、キャンセルの処理へ移行する(図中C)。これと平行して、キャンセル料金を算出して(ステップS36)、キャンセル料金をユーザー端末に送信するために情報通知処理部32へ処理を移行する。予約変更もキャンセル変更もない場合には、予約確認データと料金情報を作成し(ステップS37)、ユーザー端末100へ送信するために情報通知処理部32へ処理を移行する。
以上、第1の実施形態について説明した。本実施形態によれば、乗降要望データをグループ化、クラスタリングしたクラスタに対して、相乗り走行ルートを作成し、相乗りの所定の条件を満足しないデータがある場合には、タクシーの台数(クラスタ数)を増やして、再度クラスタリングを行うようことにより、所定の条件を満足するように相乗り走行ルートを生成することが可能となる。
<第2の実施形態>
図17に、第2の実施形態の相乗りタクシーシステム10の他の処理例を示す。ユーザー端末100からの乗降要望データの予約の受付期間が長く、相乗りタクシーの配車までに一定の期間があり、乗降要望データが時間と共に増えていく場合の相乗りタクシーシステム10の動作について説明する。
図17に、第2の実施形態の相乗りタクシーシステム10の他の処理例を示す。ユーザー端末100からの乗降要望データの予約の受付期間が長く、相乗りタクシーの配車までに一定の期間があり、乗降要望データが時間と共に増えていく場合の相乗りタクシーシステム10の動作について説明する。
図17(a)は、例えば、相乗りタクシーの配車の1週間前のクラスタ形成の様子を示す。図17(b)は、相乗りタクシーの配車の3日前のクラスタ形成の様子を示す。図17(c)は、相乗りタクシーの配車の前日のクラスタ形成の様子を示す。図17(a)~(c)に示す通り、時間と共に、乗降要望データが増加して、クラスタ形成の様子も変化していく。第1の実施形態においては、予約の変更を受付ける毎に再度クラスタリングを行うようにしたが、第2の実施形態では、一定期間ごとにクラスタリングを行うようにする。予約期間が長い場合には、乗降要望データが増えていくことが想定され、予約変更の都度、再度クラスタリングを行うよりもシステムのリソースを消費しないので有利である。尚、再度クラスタリングを行う間隔については、具体的な相乗りを提供する状況に応じて、適宜調整することは言うまでもない。
<第3の実施形態>
図18は、乗降要望データに設定した相乗条件を基に再度クラスタリングを行う例を示す。第1の実施形態では、配車計画処理部22で各所要時間の算出結果に基づいて、所定の条件を満足するか否かを判断し、満足しない場合に再度クラスタリングを行った。第3の実施形態では、乗降要望データに項目がある相乗条件に基づいて、再度クラスタリングを行うものである。相乗条件は、図4の乗降要望データで説明したように、相乗りする同乗者の条件などである。具体的には、先に説明した学習塾への送迎に相乗りを利用する場合は、利用者は子供であり、同性の同乗者しか許容しない場合が想定される。この処理は、図14のクラスタリング処理で説明を省略した相乗条件調整(ステップS15)に相当する。
図18は、乗降要望データに設定した相乗条件を基に再度クラスタリングを行う例を示す。第1の実施形態では、配車計画処理部22で各所要時間の算出結果に基づいて、所定の条件を満足するか否かを判断し、満足しない場合に再度クラスタリングを行った。第3の実施形態では、乗降要望データに項目がある相乗条件に基づいて、再度クラスタリングを行うものである。相乗条件は、図4の乗降要望データで説明したように、相乗りする同乗者の条件などである。具体的には、先に説明した学習塾への送迎に相乗りを利用する場合は、利用者は子供であり、同性の同乗者しか許容しない場合が想定される。この処理は、図14のクラスタリング処理で説明を省略した相乗条件調整(ステップS15)に相当する。
図18(a)~(c)を参照して説明する。図18(a)はクラスタリングが完了して、クラスタCL1~CL6が生成された場合を示している。図18(b)は、相乗条件の関係を示している。相乗条件A、B、Cの利用者に対して、それぞれ相乗りの同乗を許容している利用者の相乗条件を示した表である。図18(a)のクラスタCL1~CL3のマップ上のデータには、条件A~Cの何れであるかを示している。クラスタCL1のデータは、A、A、Cであり、図18(b)から相乗条件に問題はない。クラスタCL2のデータは、B、C、Cである。条件Bの利用者は、条件A、Bの利用者しか同乗を許容しないから、相乗条件を満足していない。クラスタCL3のデータは、A、A、A、Bであり、相乗条件に問題はない。
この場合に、クラスタ数を増やし(クラスタ数を7にして)、再度クラスタリングを行う。結果として、クラスタCL2、CL3を分割して、クラスタCL7を図18(c)に示すようにクラスタが生成されて、相乗条件の問題は解消する。当該処理はクラスタリング部に組み込んだプログラムによって実行する。本実施形態で示したのは、一例であって、クラスタリングのアルゴリズムによって、図示した以外のクラスタが生成されることは当然にして有り得る。本開示は、クラスタリングの詳細まで特定するものではなく、クラスタ数を増やして、再度クラスタリングを行うことに特徴を有するものである。
なお、本発明は上述した実施形態およびその変形例に限定されるものではなく、本願の特許請求の範囲に記載された事項の範囲内において種々の変更や改良が可能であることは勿論である。
10 相乗りタクシーシステム、11 CPU、12 入力装置、13 出力装置、14 記憶装置、15 通信装置、16 バス、20 配車計画部、21 クラスタリング部、22 配車計画処理部、23 記憶部、24 受信部、25 送信部、31 料金算出処理部、32 情報通知処理部、33 オーダー処理部、100、100A、100B ユーザー端末、200 コンピュータ、300 ネットワーク
Claims (1)
- 相乗りを希望する複数の利用者の乗降要望データを受信する受信部と、
前記乗降要望データに基づいて、配車計画を生成する配車計画部と、
前記配車計画をタクシー会社に送信する送信部と、
を有する相乗りタクシーシステムであって、
前記配車計画部は、
前記乗降要望データが有する乗車情報又は降車情報の類似性に基づいて、複数の前記乗降要望データをグループ化し、配車するタクシーを1台ずつ割当て、タクシー1台に乗る人数が所定数以下となるようにクラスタを生成するクラスタリングを行うクラスタリング部と、
前記クラスタに対して、相乗り走行ルートを作成し、前記走行ルートに基づいて、前記配車計画を生成する配車計画処理部と、
を有し、
前記配車計画処理部は、前記クラスタ毎の相乗り走行時間が一定時間以上の場合には、前記配車するタクシーの台数を増やして、再度クラスタリングを行う、
相乗りタクシーシステム。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2021121433A JP2023017285A (ja) | 2021-07-26 | 2021-07-26 | 相乗りタクシーシステム |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2021121433A JP2023017285A (ja) | 2021-07-26 | 2021-07-26 | 相乗りタクシーシステム |
Publications (1)
Publication Number | Publication Date |
---|---|
JP2023017285A true JP2023017285A (ja) | 2023-02-07 |
Family
ID=85157954
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2021121433A Pending JP2023017285A (ja) | 2021-07-26 | 2021-07-26 | 相乗りタクシーシステム |
Country Status (1)
Country | Link |
---|---|
JP (1) | JP2023017285A (ja) |
Cited By (12)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2023053387A (ja) * | 2022-02-04 | 2023-04-12 | 株式会社三洋物産 | 遊技機 |
JP2023053388A (ja) * | 2018-03-08 | 2023-04-12 | 株式会社三洋物産 | 遊技機 |
JP2023054222A (ja) * | 2019-03-28 | 2023-04-13 | 株式会社三洋物産 | 遊技機 |
JP2023054225A (ja) * | 2019-04-11 | 2023-04-13 | 株式会社三洋物産 | 遊技機 |
JP2023054224A (ja) * | 2019-04-11 | 2023-04-13 | 株式会社三洋物産 | 遊技機 |
JP2023054223A (ja) * | 2019-03-28 | 2023-04-13 | 株式会社三洋物産 | 遊技機 |
JP2023060269A (ja) * | 2022-04-01 | 2023-04-27 | 株式会社三洋物産 | 遊技機 |
JP2023060270A (ja) * | 2022-04-01 | 2023-04-27 | 株式会社三洋物産 | 遊技機 |
JP2023063369A (ja) * | 2022-01-07 | 2023-05-09 | 株式会社三洋物産 | 遊技機 |
JP2023071934A (ja) * | 2019-02-15 | 2023-05-23 | 株式会社三洋物産 | 遊技機 |
JP2023105101A (ja) * | 2018-12-26 | 2023-07-28 | 株式会社三洋物産 | 遊技機 |
JP2023105105A (ja) * | 2020-05-29 | 2023-07-28 | 株式会社三洋物産 | 遊技機 |
-
2021
- 2021-07-26 JP JP2021121433A patent/JP2023017285A/ja active Pending
Cited By (12)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2023053388A (ja) * | 2018-03-08 | 2023-04-12 | 株式会社三洋物産 | 遊技機 |
JP2023105101A (ja) * | 2018-12-26 | 2023-07-28 | 株式会社三洋物産 | 遊技機 |
JP2023071934A (ja) * | 2019-02-15 | 2023-05-23 | 株式会社三洋物産 | 遊技機 |
JP2023054222A (ja) * | 2019-03-28 | 2023-04-13 | 株式会社三洋物産 | 遊技機 |
JP2023054223A (ja) * | 2019-03-28 | 2023-04-13 | 株式会社三洋物産 | 遊技機 |
JP2023054225A (ja) * | 2019-04-11 | 2023-04-13 | 株式会社三洋物産 | 遊技機 |
JP2023054224A (ja) * | 2019-04-11 | 2023-04-13 | 株式会社三洋物産 | 遊技機 |
JP2023105105A (ja) * | 2020-05-29 | 2023-07-28 | 株式会社三洋物産 | 遊技機 |
JP2023063369A (ja) * | 2022-01-07 | 2023-05-09 | 株式会社三洋物産 | 遊技機 |
JP2023053387A (ja) * | 2022-02-04 | 2023-04-12 | 株式会社三洋物産 | 遊技機 |
JP2023060269A (ja) * | 2022-04-01 | 2023-04-27 | 株式会社三洋物産 | 遊技機 |
JP2023060270A (ja) * | 2022-04-01 | 2023-04-27 | 株式会社三洋物産 | 遊技機 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
JP2023017285A (ja) | 相乗りタクシーシステム | |
Tsubouchi et al. | Innovative on-demand bus system in Japan | |
JP3959245B2 (ja) | 乗合車両運行スケジューリングシステム | |
JP7378831B2 (ja) | 情報処理装置、情報処理方法及びプログラム | |
WO2020256116A1 (ja) | スケジュール調整方法及びスケジュール調整プログラムを格納した記憶媒体 | |
CN112906980B (zh) | 订单处理方法、装置、系统及可读存储介质 | |
JP2020194366A (ja) | 配車処理システム | |
JP2015035043A (ja) | 相乗り支援システム | |
JP2002024659A (ja) | 配車予約システム | |
Yan et al. | Solution methods for the taxi pooling problem | |
JP2003288516A (ja) | サービス車両予約システム | |
JP2020119441A (ja) | 配車プログラム及び配車システム | |
JP7359083B2 (ja) | 配車計画装置、配車計画システム、及び配車計画プログラム | |
JP6933675B2 (ja) | 車両乗合支援システム | |
JP4054018B2 (ja) | 空席経路探索システム、空席経路探索装置および端末装置 | |
JP7198425B2 (ja) | 自動車運行管理システム及び自動車運行管理システムに用いられる運行管理装置 | |
JP7169536B2 (ja) | 自動車運行管理システム及び自動車運行管理システムに用いられる運行管理装置 | |
JP6409159B1 (ja) | バス手配運行方法、サーバおよびプログラム | |
JP7348735B2 (ja) | 配車装置、配車システム、および配車方法 | |
JP7079368B1 (ja) | 情報処理装置及びプログラム | |
JP7383330B2 (ja) | 配車装置、配車方法、及びプログラム | |
Kim | Model and algorithm for solving real time dial-a-ride problem | |
JP6977192B1 (ja) | 情報処理装置及びプログラム | |
JP6565024B2 (ja) | バス手配運行方法、サーバおよびプログラム | |
KR102323831B1 (ko) | 전세버스 모객 시스템 및 방법 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20240212 |