JP2018173985A - 混雑度推定システムおよび電子機器 - Google Patents

Abstract

【課題】将来の混雑状況を推定することができない。【解決手段】混雑度推定サーバは、複数の路上の監視カメラから受信した映像を解析して人数および道路の面積から現在の混雑度を算出する。所定のエリアに含まれる監視カメラから算出された混雑度を平均して、所定のエリアの現在の混雑度を算出し、さらに、イベント情報から所定のエリアにおける将来の混雑度の増加分を推定し、算出した現在の混雑度との和を算出することにより所定のエリアにおける将来の混雑度の推定する。推定した将来の混雑度を要求に応じて外部に送信する。【選択図】図１

Description

本発明は、混雑度推定サーバ、および混雑度推定システムに関する。

ネットワークに接続された複数の監視カメラにより撮影して得られた映像を解析し、混雑状況を把握するシステムが、たとえば特許文献１に開示されている。

特開２０１１−００８４５４

特許文献１に記載されている発明では、将来の混雑状況を推定することができない。

（１）請求項１に記載の混雑度推定サーバは、撮影位置に関する情報が付加された撮影画像、ならびに開催場所、時刻、および参加者の数の情報を含む将来のイベントの情報を受信する通信部と、通信部が受信した撮影画像を解析し、人数と歩道の面積から算出される現在の混雑度を出力する画像解析部と、歩道の面積を算出できる情報を含む地図情報を保存する地図データベースと、画像解析部が出力する現在の混雑度、撮影画像の撮影位置、地図データベースが保存する地図情報、および将来のイベントの情報に基づいて撮影位置を含む所定のエリアの将来の混雑度の時間分布を推定する混雑度推定部と、混雑度推定部が推定した将来の混雑度の時間分布を通信部より送信する制御部とを備える。
（２）請求項６に記載の混雑度推定システムは、上記混雑度推定サーバと、演算装置とを備える混雑度推定システムであって、演算装置は、混雑度推定サーバに要求を送信し、混雑度推定サーバから将来の混雑度の時間分布を受信する演算装置通信部と、演算装置通信部が受信した将来の混雑度の時間分布を出力する情報出力部とを備える。

本発明によれば、将来の混雑状況を推定することができる。

第１の実施の形態における混雑度推定システムの構成を示すブロック図 推定混雑度の一例を示す図 増加混雑度データベースの一例を示す図 携帯端末の表示部における混雑度の表示の一例を示す図 現在の混雑度を算出するプログラムのフローチャート イベントによる混雑度への影響を算出するプログラムのフローチャート 図６のサブルーチンのフローチャート 図７のフローチャートの説明のための地図 第１の実施の形態における推定混雑度を算出するプログラムのフローチャート 第２の実施の形態における混雑度推定システムの構成を示すブロック図 混雑度統計データベースの一例を示す図 第２の実施の形態における推定混雑度を算出するプログラムのフローチャート

（第１の実施の形態）
以下、図１〜９を参照して、本発明による混雑度推定システム１の第１の実施の形態を説明する。本実施の形態では、イベントとは少なくとも、開催日時、終了時刻、開催場所、参加予想人数が明らかな催しをいい、たとえばスポーツの試合やコンサートなどである。本実施の形態において、混雑度とは１ｍ^２あたりに存在する人の数をいい、混雑度が高いほど混雑している状態を示す。
図１は、混雑度推定システム１の構成を示すブロック図である。
混雑度推定システム１は、混雑度推定サーバ１０と、携帯端末２０と、複数の監視カメラ３０と、イベント情報サーバ４０とから構成され、これらは全てネットワーク網Ｘに接続されている。

混雑度推定サーバ１０は、制御部１１と、記憶部１２と、通信部１３と、地図データベース１４と、増加混雑度データベース１５と、交通統計データベース１６とを備える。
制御部１１は、不図示のＣＰＵ、ＲＯＭ、およびＲＡＭを備え、ＲＯＭには以下の動作を行うプログラムが格納され、プログラムはＲＡＭに展開されて実行される。
記憶部１２は、不図示の磁気ディスクにより構成され、記憶部１２には、推定混雑度１２ａ、複数の撮影画像１２ｂ、およびそれらの撮影位置１２ｃが保存される。

推定混雑度１２ａは、携帯端末２０からの要求に応じて制御部１１により作成され、通信部１３から携帯端末２０に送信される。ただし制御部１１は、一定時間ごとに推定混雑度１２ａを作成し、携帯端末２０に送信してもよい。推定混雑度１２ａは、現在時刻以降の、地図データベース１４の分割されたエリアごとの推定した混雑度を表す。推定混雑度１２ａは、携帯端末２０から要求があるたびに、後述する方法により増加混雑度データベース１５をもとにして作成される、たとえば図２に示すものである。
図２は、エリアＡ１〜Ａ３における現在の混雑度、現在時刻におけるエリア固有の混雑度であるＢＡＳＥの値、および将来の混雑度の推定値を示している。撮影画像１２ｂから算出した現在の混雑度は、イベントに影響を受けないエリア固有の混雑度とイベントによる混雑度の増加分との和であると考え、予め算出したイベントによる混雑度の増加予想分を現在の混雑度から減算して、現在時刻におけるエリア固有の混雑度であるＢＡＳＥを求めている。図２の例では０時５分に推定混雑度１２ａを作成しているので、将来の混雑度として０時１０分以後のエリアごとの混雑度の推定値が表示されている。なお、前述のとおり、本実施の形態では混雑度の単位は（人／ｍ^２）である。

撮影画像１２ｂは、監視カメラ３０が撮影した画像であり、その撮影位置の情報は撮影位置１２ｃとして記録される。撮影画像１２ｂ、および撮影位置１２ｃは、通信部１３が複数の監視カメラ３０から受信する。ただし、それぞれの監視カメラ３０が撮影した最新の撮影画像のみを使用するため、新たに撮影画像１２ｂを受信すると同一の位置情報を有する記憶部１２に保存されていた撮影画像１２ｂは制御部１１により削除される。
通信部１３は、ネットワーク網Ｘにより携帯端末２０、複数の監視カメラ３０、イベント情報サーバ４０と通信を行う。
地図データベース１４は、不図示の磁気ディスクにより構成され、地図データベース１４には、交通機関の乗降場所、および歩道の道幅の情報を含む地図が記録されている。交通機関の乗降場所とは、鉄道の駅、バスの停留所などをいう。地図データベース１４に保存されている地図は、所定の大きさごとに名前付きのエリアに分割されている。たとえば、地図が３ｍ四方ごとのメッシュ状のエリアに分割され、１から始まる行番号とＡから始まる列記号の組み合わせにより、Ａ１、Ａ２、Ａ３，・・、Ｂ１、Ｂ２、・・のように名前が付けられる。地図データベース１４はさらに、一般的な外側線の幅やガードレースの支柱の間隔の情報が保存されている。

増加混雑度データベース１５は、不図示の磁気ディスクにより構成される。増加混雑度データベース１５には、地図データベース１４の分割されたエリアごとの監視カメラ３０が撮影した撮影画像１２ｂから算出される現在の混雑度と、エリアごと時刻ごとの、イベントにより増加する混雑度である増加混雑度とが保存される。
図３は、増加混雑度データベース１５の一例を示すものであり、エリアＡ１〜Ａ３の現在の混雑度、および０時から２３時５５分までの５分ごとの時刻における、イベントにより増加する混雑度が示されている。増加混雑度データベース１５には、全てのイベントの影響の和として保存されている。図３には、エリアＡ１の０：００において混雑度が１．５（人／ｍ^２）増加すると記載されているが、たとえばこれは、あるイベントによる混雑度の１．０（人／ｍ^２）の増加と、別のイベントによる混雑度の０．５（人／ｍ^２）の増加の和などである。後述するように、現在の混雑度は一定時間ごとに算出されるが、増加混雑度は１日に１回のみ算出される。なお、図３ではある１日分の増加混雑度しか表示していないが、数日分をまとめて算出し、増加混雑度データベース１５に保存してもよい。

交通統計データベース１６は、不図示の磁気ディスクにより構成され、交通統計データベース１６には、交通機関の乗降場所、たとえば鉄道の駅やバス停の、１日あたりの平均利用者数が格納されている。交通統計データベース１６を参照することにより、イベント参加者が、どのような割合で周辺の交通機関の乗降場所を利用するかを推定することができる。

携帯端末２０は、制御部２１と、入力部２２と、表示部２３と、通信部２４と、記憶部２５とを備える、たとえば携帯電話やウエアラブル機器である。制御部２１は、不図示のＣＰＵ、ＲＯＭ、およびＲＡＭを備え後述する動作を行うプログラムをＲＡＭに展開して実行する。入力部２２は、不図示のタッチパネル、またはボタンを備え、携帯端末２０のユーザによる推定混雑度１２ａの要求を制御部２１に伝達する。表示部２３は、不図示のディスプレイを備え、制御部２１から受信したデータを表示する。通信部２４は、ネットワーク網Ｘを介して混雑度推定サーバ１０と通信し、推定混雑度１２ａを受信する。記憶部２５は、混雑度推定サーバ１０から受信する推定混雑度１２ａを保存する。

ユーザが入力部２２から推定混雑度１２ａを要求する所定の操作を行うと、制御部２１は通信部２４から混雑度推定サーバ１０に所定の信号を送信し、推定混雑度１２ａを得ることができる。制御部２１は、受信した推定混雑度１２ａを、数字のまま、または図４のように可視化して表示部２３に表示し、ユーザによる入力部２２からの指令、または自動的に表示部２３に表示する混雑度の時刻を変化させる。
図４は、エリアごとの推定混雑度１２ａを棒グラフの高さにより表現したものである。エリアは、南北方向の位置を示すＡ〜Ｆと東西方向の位置を示す１〜７との組み合わせにより特定される。図４に表示されているエリアでは、エリアＢ２の推定混雑度が最も高く、次にエリアＡ２、Ｂ１、Ｂ３、Ｃ２の４つのエリアの推定混雑度が高いことがわかる。

監視カメラ３０は、制御部３１と、撮影部３２と、通信部３３と、を備える、路上に設置されている監視カメラである。制御部３１は、不図示のＣＰＵ、ＲＯＭ、およびＲＡＭを備え、ＲＯＭには以下の動作を行うプログラム、および当該監視カメラ３０の撮影位置が記録される。撮影部３２は、被写体を撮影する。通信部３３は、混雑度推定サーバ１０と通信する。制御部３１は、一定時間ごと、たとえば５分ごとに撮影部３２により撮影し、ＲＯＭに保存された当該監視カメラ３０の撮影位置とともに、撮影して得られた画像を通信部３３から混雑度推定サーバ１０に送信する。混雑度推定サーバ１０は、受信した画像を撮影画像１２ｂとして、受信した撮影位置を撮影位置１２ｃとして、記憶部１２に保存する。

イベント情報サーバ４０は、制御部４１と、記憶部４２と、通信部４３とを備える。制御部４１は、不図示のＣＰＵ、ＲＯＭ、およびＲＡＭを備え、ＲＯＭには以下の動作を行うプログラムが保存される。記憶部４２は、磁気ディスクから構成され、記憶部４２には、イベントに関する情報が保存される。イベントに関する情報とは、イベントの開催日時、終了時刻、開催場所、参加予想人数、などである。通信部４３は、混雑度推定サーバ１０と通信する。制御部４１は、通信部４３が混雑度推定サーバ１０からイベント情報の要求を受信すると、イベントの情報を通信部４３により混雑度推定サーバ１０に送信する。

第１の実施の形態の動作を説明する。
混雑度推定サーバ１０は、現在の混雑度を算出して増加混雑度データベース１５を更新するために、一定時間ごとに以下のプログラムを実行する。
図５は、混雑度推定サーバ１０の制御部１１が現在の混雑度を算出するために実行するプログラムの動作を示すフローチャートである。

ステップＳ２０１では、制御部１１は、複数の監視カメラ３０から受信して記憶部１２に保存されている複数の撮影画像１２ｂを対象として画像処理を行い、それぞれの撮影画像１２ｂに撮影されている人物を認識して人数を算出し、ステップＳ２０２に進む。
ステップＳ２０２では、制御部１１は、ステップＳ２０１と同じ複数の撮影画像１２ｂを対象として、認識した人物の足の付近が歩道であること、歩道の色はおおよそ均一であること、壁と歩道の色は明確なコントラストを有すること、などから歩道を判別する。次に、撮影画像１２ｂに撮影されている既知の大きさ、または既知の長さを有する物体を利用して歩道の面積を算出する。たとえば、地図データベース１４に保存されている、道路の外側線の幅やガードレールの支柱の間隔の情報を利用する。そして、ステップＳ２０１において認識した人数を、ステップＳ２０２において算出した歩道の面積で除し、それぞれの撮影画像１２ｂにおける単位面積当たりの歩行者の数、すなわち混雑度を算出してステップＳ２０３に進む。すなわち、ステップＳ２０２の処理により、記憶部１２に保存されている撮影画像１２ｂのそれぞれに対応した混雑度が算出される。

ステップＳ２０３では、制御部１１は、前述のメッシュ状のエリアごとにそのエリア内が設置箇所である監視カメラ３０を全て特定し、それらの監視カメラ３０で撮影された撮影画像１２ｂから算出された混雑度の平均値を、増加混雑度データベース１５に現在の混雑度として保存し、ステップＳ２０４に進む。たとえば、あるエリアに２つの監視カメラ３０が設置されており、それらの監視カメラ３０で撮影された撮影画像１２ｂから算出された混雑度が、０．１（人／ｍ^２）と０．３（人／ｍ^２）であったとする。この場合は、平均値である０．２（人／ｍ^２）を地図データベース１４の当該エリアの現在の混雑度として保存する。

ステップＳ２０４では、制御部１１は、ステップＳ２０３において算出したエリアごとの混雑度の補間処理を行う。すなわち、あるエリアには１台も監視カメラが設置されておらず、現在の混雑度の算出ができなかった場合には、隣接する周囲のエリアの混雑度の平均値を算出し、そのエリアの混雑度として増加混雑度データベース１５に保存する。その後、図５のフローチャートを終了する。
混雑度推定サーバ１０は、翌日開催されるイベントによる混雑度への影響を推定するために、１日に１回、以下のプログラムを実行する。

図６は、混雑度推定サーバ１０の制御部１１がイベントによる混雑度への影響を算出し、増加混雑度データベース１５の増加混雑度を更新するために実行するプログラムの動作を示すフローチャートである。
ステップＳ３０１では、制御部１１は、イベント情報サーバ４０に問合せを行い、翌日に行われるすべてのイベントの情報を受信し、翌日にイベントが行われるか否かを判断する。イベントが行われると判断する場合は１つのイベントを処理対象に選択してステップＳ３０２に進み、イベントが行われないと判断する場合はステップＳ３０８に進む。

ステップＳ３０２では、制御部１１は、図７に示すサブルーチンを実行し、イベント参加者が利用する交通機関の乗降場所、および各乗降場所を利用するイベント参加者数を推定してステップＳ３０３に進む。図７に示すサブルーチンの処理は後に説明する。サブルーチンでは、たとえば、野球場Ｊで開催されるイベントへ参加する１万５千人の参加者のうち、１千人がＡ駅を、１万人がＢ駅を、４千人がＣ駅を使用することが推定される。

ステップＳ３０３では、制御部１１は、ステップＳ３０２において利用することを推定した各乗降場所からイベント会場への複数の経路、および各経路の移動に必要な時間（以後、所要時間とよぶ）を算出する。そして、所要時間を変数として含む所定の関数により、各経路を利用するイベント参加者数を推定してステップＳ３０４に進む。たとえば、Ａ駅から野球場Ｊまでの移動経路がＰとＱの２つ算出され、それらの移動経路の所要時間が等しい場合には、Ａ駅を利用する１千人のうち５００人が移動経路Ｐを、別の５００人が移動経路Ｑを使用すると推定する。

ステップＳ３０４では、制御部１１は、イベント開始前のイベント参加者の移動を推定する。ステップＳ３０３において算出した移動経路ごとに、イベント開始時刻、移動経路の所要時間、および所定の余裕時間を変数として含む所定の関数により、移動経路上のイベント参加者の時間分布を推定してステップＳ３０５に進む。
余裕時間とは、イベント参加者がイベントの開始時刻よりもどの程度早くイベント会場に到着することを目標にすることが多いかを示す時間である。たとえば、イベント開始が午後７時で余裕時間が３０分の場合には、午後６時３０分の到着を目指して移動するイベント参加者が最も多い。たとえば、ある移動経路を利用してイベント会場に到着するのイベント参加者の時間分布は、イベント開始時刻を余裕時間だけ早めた時刻に到着する参加者が最大である正規分布で、２σがその移動経路の所要時間である。そして、その移動経路の出発地である乗降場所を出発するイベント参加者の時間分布は、イベント開始時刻から余裕時間およびその移動経路の所要時間を早めた時刻に最大値をとる正規分布であり、２σがその移動経路の所要時間である。
なお、本フローチャートの実行により更新される増加混雑度データベース１５は、地図を所定のエリアに区切っており、所定の時間間隔でしか記述していないので時間が離散的であるが、ステップＳ３０４において推定される移動経路上のイベント参加者の時間分布は、エリアは考慮せず時間も連続的なものとして扱っている。

ステップＳ３０５では、制御部１１は、ステップＳ３０４とは反対にイベント終了後のイベント参加者の移動を推定する。イベント終了時もイベント参加者はステップＳ３０３と同じ移動経路を利用することとし、イベント会場の出入り口が混雑している状況を、イベント終了時刻から一定の時間間隔ごとに一定の割合の参加者のみが移動を開始することにより近似する。たとえば、５分ごとにイベント参加者の６分の１ずつが、イベント会場から交通機関の乗降場所に移動を開始するとして、ステップＳ３０４と同様に移動経路上のイベント参加者の時間分布を算出する。その後、ステップＳ３０６に進む。

ステップＳ３０６では、制御部１１は、ステップＳ３０４〜Ｓ３０５において推定した移動経路上のイベント参加者の時間分布を、地図データベース１４に保存されている歩道面積の情報を参照して、エリアごとの混雑度の時間変化に換算する。そして、エリアごとの混雑度の時間変化から、所定の時間間隔で混雑度を抽出して、エリアごとの増加混雑度として増加混雑度データベース１５に保存しステップＳ３０７に進む。ただし、すでに同一エリアの同一時刻に増加混雑度が保存されている場合には、増加混雑度を足し合わせる。保存されている増加混雑度は、他のイベントにより同一時刻、同一エリアで増加する混雑度なので、複数のイベントが並行して開催されれば、混雑度はその分だけ高まるからである。

ステップＳ３０７では、制御部１１は、ステップＳ３０１においてイベント情報サーバ４０に問い合わせた結果から、他に未処理のイベントが存在するか否かを判断する。未処理のイベントが存在すると判断する場合は、処理対象を他の未処理のイベントに設定してステップＳ３０２に進み、未処理のイベントがないと判断する場合は図６のフローチャートを終了する。
ステップＳ３０８では、制御部１１は、増加混雑度データベース１５の増加混雑度に全てゼロを書込み、図６のフローチャートを終了する。イベントがないため、イベントによる混雑度の増加もないからである。

図７は、図６のステップＳ３０２から呼び出されるサブルーチンの動作を示すフローチャートである。図７の説明のために、あるイベント会場Ｄとその周辺にある駅を示す図８を用いる。図８において、Ｅ駅とＦ駅、Ｇ駅とＨ駅は同一路線の駅である。
ステップＳ４０１では、制御部１１は、地図データベース１４を利用して、イベント会場から所定距離内に存在する交通機関の乗降場所を列挙して、ステップＳ４０２に進む。図８に示す例では、イベント会場Ｄから所定の距離、１ｋｍ以内に駅Ｅ〜Ｉがあり、これらの全てが列挙される。

ステップＳ４０２では、制御部１１は、ステップＳ４０１において列挙した駅から、同一路線内でイベント会場に最も近い駅を選択してステップＳ４０３に進む。イベントの参加者は、乗り換えの必要のない同一路線の駅ならば、目的地であるイベント会場に最も近い駅で降りるからである。図８に示す例では、同一路線の駅であるＥ駅とＦ駅のうち、Ｆ駅の方がイベント会場Ｄに近いのでＦ駅が選択され、同一路線の駅であるＧ駅とＨ駅のうちイベント会場Ｄに近いＨ駅が選択される。また、Ｉ駅は他に選択されている同一路線の駅がないので、そのまま選択が維持される。すなわち、ステップＳ４０２において図８の例では、Ｆ駅、Ｈ駅、Ｉ駅が選択される。

ステップＳ４０３では、制御部１１は、交通統計データベース１６から、ステップＳ４０２において選択された各駅の１日あたりの平均利用者数を抽出し、各駅の１日あたりの平均利用者数の比を算出する。図８に示す例では、ステップＳ３０２において選択されたＦ駅、Ｈ駅、Ｉ駅の１日の平均利用者数が、順に２万人、５万人、３万人であったとすると、それらの比として、２：５：３が算出される。
ステップＳ４０４では、制御部１１は、ステップＳ４０３において算出された比で、全てのイベントの参加予定者数がそれらの駅を利用するとして、各駅の利用者数を算出して図７のフローチャートを終了し、図６のステップＳ３０３に進む。図８に示す例では、イベントの参加予定者が１万人であったとすると、ステップＳ４０２において算出した比率から、Ｆ駅、Ｈ駅、Ｉ駅の利用者数は、それぞれ２千人、５千人、３千人と算出される。

図９は、携帯端末２０からの要求により制御部１１により実行される、推定混雑度１２ａを作成するプログラムの処理を示すフローチャートである。図９に示すフローチャートを実行する際には、これまでに説明した増加混雑度データベース１５がすでに作成されている。
ステップＳ５０１では、制御部１１は、増加混雑度データベース１５から、全エリアの現在の混雑度を取得して、推定混雑度１２ａの現在の混雑度に書込み、ステップＳ５０２に進む。図２の例では、Ａ１から順に、４（人／ｍ^２），１（人／ｍ^２），２（人／ｍ^２）の値を取得する。

ステップＳ５０２では、制御部１１は、エリアごとに以下のように変数ｂａｓｅの値を算出して、推定混雑度１２ａのメモリエリアに書き込む。変数ｂａｓｅは、現在の混雑度から現在時刻における増加混雑度を減算して算出される。次にステップＳ５０３に進む。図２の例では、エリアＡ１では現在の混雑度が４（人／ｍ^２）、現在時刻である０時５分における増加混雑度が１（人／ｍ^２）なので、ｂａｓｅは３（人／ｍ^２）である。同様に、エリアＡ２、Ａ３におけるｂａｓｅは０（人／ｍ^２）、１（人／ｍ^２）となる。変数ｂａｓｅは、現在時刻におけるエリア固有の混雑度であり、現在時刻以降もイベントとは関係なく変数ｂａｓｅで表される混雑度は維持される。変数ｂａｓｅが負の値の場合は、イベントの開催により予想された混雑度よりも、撮影画像１２ｂから算出された現在の混雑度が低いことを示している。

ステップＳ５０３では、制御部１１は、増加混雑度データベース１５から現在の時刻以降の増加混雑度を参照し、エリアごと、時刻ごとに変数ｖａｌを算出する。変数ｖａｌは、変数ｂａｓｅと時間ごとの増加混雑度の和として算出する。その後、ステップＳ５０４に進む。図２の例では、エリアＡ１における現在から５分後の０時１０分の推定混雑度は、現在時刻における増加混雑度が２（人／ｍ^２）であり、エリアＡ１のｂａｓｅが３（人／ｍ^２）なので、合計の５（人／ｍ^２）となる。同様に、エリアＡ２，Ａ３における推定混雑度は１（人／ｍ^２），３（人／ｍ^２）となる。
ステップＳ５０４では、制御部１１は、ステップＳ５０３において算出した変数ｖａｌを推定値として推定混雑度１２ａのメモリエリアに書込み、ステップＳ５０５に進む。
ステップＳ５０５では、記憶部１２に保存されている推定混雑度１２ａを、要求を送信した携帯端末２０に通信部１３から送信し、図９のフローチャートを終了する。

第１の実施の形態において、混雑度推定システム１は、以下の動作を行う。
混雑度推定サーバ１０は、イベント情報サーバ４０からイベントの情報を受信し、イベントの影響による混雑度の増加をエリアごと、時刻ごとに推定して、増加混雑度データベース１５に保存する。
混雑度推定サーバ１０は、複数の監視カメラ３０から撮影位置１２ｃが付された撮影画像１２ｂを次々に受信し、一定時間ごとに受信した最新の撮影画像１２ｂを画像解析することにより、現在の混雑度分布を算出して増加混雑度データベース１５に保存する。
混雑度推定サーバ１０は、携帯端末２０から指定を受信すると、増加混雑度データベース１５を用いて推定混雑度１２ａを作成し、携帯端末２０に送信する。
携帯端末２０は、受信した推定混雑度１２ａを表示部２３に表示する。

上述した第１の実施の形態によれば、次の作用効果が得られる。
（１）混雑度推定サーバ１０は、監視カメラ３０の撮影位置１２ｃ、撮影画像１２ｂ、ならびにイベント開催場所、開催日時、終了時刻、参加予定人数の情報を含む将来のイベントの情報を受信する通信部１３と、通信部２４が受信した撮影画像１２ｂを解析し、人数と歩道の面積から算出される現在の混雑度を出力する画像解析処理（図５のステップＳ２０１、Ｓ２０２）と、道路幅の情報を含む地図を保存する地図データベース１４と、画像解析処理により出力される現在の混雑度、撮影画像１２ｂの撮影位置１２ｃ、地図データベース１４、および将来のイベントの情報に基づいて撮影位置１２ｃを含む所定のエリアの将来の混雑度の時間分布を推定する混雑度推定処理（図９のステップＳ５０１〜Ｓ５０５）と、混雑度推定処理が推定した将来の混雑度の時間分布である推定混雑度１２ａを通信部１３より送信する制御部１１とを備える。
そのため、混雑度推定サーバ１０は、イベント情報と現在の混雑度から各エリアの将来の混雑度の時間分布である推定混雑度１２ａを推定することができる。また、携帯端末２０のユーザは混雑度推定サーバ１０から推定混雑度１２ａを得られる。
（２）制御部１１による混雑度推定処理は、地図データベース１４の情報から算出する所定のエリアにおける歩道の面積、所定のエリアを通行するイベント参加者の時間分布に基づいて、イベント参加者による混雑度の増加を推定する。
そのため、算出された混雑度は歩道の歩きやすさを示しており、推定混雑度１２ａを受信した携帯端末２０のユーザは、歩きやすい歩道を選択して通行することができる。
（３）混雑度推定サーバ１０は、交通機関の乗降場所の平均利用者数に関する情報を保存する交通統計データベース１６をさらに備え、制御部１１の混雑度推定処理は、イベントの開催場所から所定の距離内にある交通機関の乗降場所を利用する当該イベントの参加者の数を、イベントの開催場所から所定の距離内にある交通機関の乗降場所の平均利用者数の比に基づき算出し、所定のエリアにおけるイベントの参加者により増加する将来の混雑度の時間分布を、地図データベース１４の情報から算出する当該エリアの歩道の面積と交通機関の乗降場所からイベントの開催場所へ移動するイベントの参加者の時間分布とから推定する。
そのため、イベント参加者が集中して通行するエリアを特定し、そのエリアを避けて移動することができる。

（変形例１）
第１の実施の形態においては、交通統計データベース１６を利用して、交通機関の乗降場所ごとにイベント参加者の利用者数を推定し、その乗降場所とイベント会場とを結ぶ経路の混雑度が上昇するとしたが、イベントの開催による混雑度への影響の算出方法はこれに限定されない。交通統計データベース１６を使用せずに、図７のステップＳ４０３およびＳ４０４の処理を、イベント参加者はイベント会場から所定距離内にある乗降場所を均一な確率で使用すると変更してもよい。たとえば、図８の例では、イベント会場Ｄへ行く５千人の参加者は、イベント会場Ｄから１ｋｍ以内の距離にある、Ｅ駅〜Ｉ駅の５つの駅を均等に使用し、全ての駅を１千人ずつが使用するとしてもよい。
この変形例１によれば、交通統計データベース１６が不要であり、交通機関の乗降場所の利用者数を簡易に算出することができる。

（変形例２）
第１の実施の形態においては、監視カメラ３０は、撮影画像とともに監視カメラ３０の設置場所を混雑度推定サーバ１０に送信したが、監視カメラ３０の位置情報の混雑度推定サーバ１０への伝達方法はこれに限定されない。監視カメラ３０の制御部３１のＲＯＭに、当該監視カメラ３０の撮影位置に代えて監視カメラ３０の識別番号を保存し、撮影画像とともに識別番号を送信してもよい。そして、混雑度推定サーバ１０は監視カメラ３０の識別番号と監視カメラ３０の撮影位置の対応を示すカメラ位置データベースをさらに備え、制御部１１は、監視カメラ３０から受信した識別番号から、その監視カメラの撮影位置を検索してもよい。
この変形例２によれば、監視カメラ３０の撮影位置が変更になった場合に、監視カメラ３０のＲＯＭを書き換える必要がなく、カメラ位置データベースを更新するだけでよいので、処理が簡便である。

（変形例３）
第１の実施の形態においては、イベント参加者はすべて歩道を通行するとして、歩道の面積を用いて混雑度を算出したが、歩道の面積に代えて、車道のみの面積または車道および歩道の面積を用いてもよい。

（第２の実施の形態）
図１０〜１２を参照して、本発明による第２の実施の形態を説明する。以下の説明では、第１の実施の形態と同じ構成要素には同じ符号を付して相違点を主に説明する。特に説明しない点については、第１の実施の形態と同じである。本実施の形態では、主に、混雑度推定サーバ１０が将来の混雑度を推定するために、統計的な混雑度の変化を示すデータベースを利用する点で、第１の実施の形態と異なる。
混雑度推定システム１の構成は、第１の実施の形態と同様であり、主に混雑度推定サーバ１０が混雑度統計データベース１７をさらに備える点が異なる。

混雑度統計データベース１７には、図１１に示すように、エリアごと、時刻ごとのある一定期間、たとえば過去１００日間の混雑度の平均値が記録されている。図１１には、エリアＡ１〜Ａ３における、０時０分から２３時５５分までの５分ごとの混雑度の平均値が表示されているが、混雑度統計データベース１７に保存される全てのエリアについての情報が保存されている。
混雑度統計データベース１７に保存されている値は、撮影画像１２ｂを解析して得られた、それぞれの時刻における増加混雑度データベース１５の現在の混雑度の、１００日分の平均値である。制御部１１は、前述のとおり一定時間ごとに図５により動作が示されるプログラムを実行して、増加混雑度データベース１５の現在の混雑度を算出する度に、混雑度統計データベース１７の現在時刻の値も更新する。たとえば、制御部１１が０時１０分に図５に示すプログラムを実行し、エリアＡ１の混雑度が４（人／ｍ^２）と算出され、混雑度統計データベース１７のエリアＡ１の０時１０分には１（人／ｍ^２）と記録されていたとする。この場合には、過去１００日間の平均なので、１と４を９９対１の割合で合成し、１．０３の値に更新される。ただし、図５には記載していないが、時刻だけでなく曜日の種別を加えてもよい。

第２の実施の形態の動作を説明する。
第２の実施の形態の動作の第１の実施の形態との主な差異は、推定混雑度１２ａの作成方法である。
図１２のフローチャートにより動作が表されるプログラムは、第１の実施の形態における図９のフローチャートに示すプログラムに代わって、第２の実施の形態において制御部１１が携帯端末２０から要求を受けると実行される。

ステップＳ５０１では、制御部１１は、増加混雑度データベース１５から、全エリアの現在の混雑度を取得して、推定混雑度１２ａの現在の混雑度の欄に書込み、ステップＳ５０２に進む。
ステップＳ５０２では、制御部１１は、エリアごとにエリア固有の混雑度である変数ｂａｓｅを算出するために、現在の混雑度から現在時刻における増加混雑度を減算する。そしてその値を推定混雑度１２ａの当該エリアの変数ｂａｓｅの欄に書込み、ステップＳ６０１に進む。

ステップＳ６０１では、制御部１１は、エリアごとに、以下のように変数ｒａｔｅの値を算出する。変数ｒａｔｅは、混雑度統計データベース１７の現在時刻における統計値を、ステップＳ５０２において算出した変数ｂａｓｅで除することにより得られる。次にステップＳ６０２に進む。変数ｒａｔｅは、イベントの影響を排除した現在の混雑度と、平均的な混雑度の比を表しており、たとえば現在が平均的な混雑度よりも低いのであれば、これから数時間後も平均的な混雑度よりも低いと推測できる。

ステップＳ６０２では、制御部１１は、エリアごとに、増加混雑度データベース１５のある時刻における増加混雑度、および混雑度統計データベース１７のある時刻における平均的な混雑度を参照し、全ての時間について以下のように変数ｖａｌを算出する。変数ｖａｌは、ステップＳ６０１において算出した変数ｒａｔｅとある時刻における平均的な混雑度との積に、ある時刻における増加混雑度を加えた値である。次にステップＳ５０４に進む。
ステップＳ５０４では、制御部１１は、ステップＳ５０３において算出した変数ｖａｌを推定混雑度として推定混雑度１２ａのメモリエリアに書き込む。続くステップＳ５０５では、推定混雑度１２ａを携帯端末２０に送信して、図１１のフローチャートを終了する。

第２の実施の形態において、混雑度推定サーバ１０は、以下の動作を行う。
エリアごと、時刻ごとの平均的な混雑度を格納する混雑度統計データベース１７を一定時間ごとに更新する。携帯端末２０から指令を受信すると、エリアごとに、同一時刻の平均的な混雑度と現在の混雑度の比を算出する。そして、現在時刻において平均よりも混雑度が高いのであれば、数時間後の将来においても同じ比率でその時刻における平均的な混雑度より混雑度が高いであろうとの予想に基づき、推定混雑度１２ａを算出して携帯端末２０に送信する。

上述した第２の実施の形態によれば、次の作用効果が得られる。
（１）混雑度推定サーバ１０は、制御部１１の画像解析処理により解析した、エリアごと、時刻ごとの現在の混雑度を保存する混雑度統計データベース１７をさらに備える。制御部１１による混雑度推定処理では、変数ｖａｌと変数ｒａｔｅとを算出し、変数ｒａｔｅおよび混雑度統計データベース１７により、イベント参加者による混雑度の増加を除いた混雑度の時間分布を推定する。さらに、その値に増加混雑度データベース１５における各時刻の増加混雑度を加えて推定混雑度１２ａを算出する。
エリアごとに過去の統計による平均的な混雑度と、現在の混雑度との比率から将来の混雑度の推移を予測し、さらにイベントによる混雑度の変化を考慮しているので、高い精度で混雑度を推定することができる。

上述した各実施の形態および変形例は、それぞれ組み合わせてもよい。
上記では、種々の実施の形態および変形例を説明したが、本発明はこれらの内容に限定されるものではない。本発明の技術的思想の範囲内で考えられるその他の態様も本発明の範囲内に含まれる。

１０…混雑度推定サーバ
１１…制御部
１２…記憶部
１２ａ…推定混雑度
１２ｂ…撮影画像
１２ｃ…撮影位置
１３…通信部
１４…地図データベース
１５…増加混雑度データベース
１６…交通統計データベース
１７…混雑度統計データベース
２０…携帯端末
３０…監視カメラ
４０…イベント情報サーバ

本発明は、混雑度推定システムおよび電子機器に関する。

請求項１に記載の混雑度推定システムは、撮影位置に関する情報が付加された撮影画像、ならびに開催場所、時刻、および参加者の数の情報を含む将来のイベントの情報を受信する通信部と、前記通信部が受信した前記撮影画像を解析し、人数と歩道の面積から算出される現在の混雑度を出力する画像解析部と、歩道の面積を算出できる情報を含む地図情報を保存する地図データベースと、前記画像解析部が出力する前記現在の混雑度、前記撮影画像の前記撮影位置、前記地図データベースが保存する前記地図情報、および前記将来のイベントの情報に基づいて前記撮影位置を含む所定のエリアの将来の混雑度の時間分布を推定する混雑度推定部と、前記混雑度推定部が推定した前記将来の混雑度の時間分布を前記通信部より送信する制御部とを備えるサーバ装置と、前記サーバ装置から送信された前記混雑度を表示する電子機器とを備える混雑度推定システムであって、前記電子機器は、 入力部と、前記入力部からの送信要求に応じてサーバ装置より送信された所定のエリアの将来の前記混雑度を受信する通信部と、前記通信部より受信した前記混雑度を表示する表示部とを備える。
請求項４に記載の電子機器は、撮影位置に関する情報が付加された撮影画像、ならびに開催場所、時刻、および参加者の数の情報を含む将来のイベントの情報を受信する通信部と、前記通信部が受信した前記撮影画像を解析し、人数と歩道の面積から算出される現在の混雑度を出力する画像解析部と、歩道の面積を算出できる情報を含む地図情報を保存する地図データベースと、前記画像解析部が出力する前記現在の混雑度、前記撮影画像の前記撮影位置、前記地図データベースが保存する前記地図情報、および前記将来のイベントの情報に基づいて前記撮影位置を含む所定のエリアの将来の混雑度の時間分布を推定する混雑度推定部と、前記混雑度推定部が推定した前記将来の混雑度の時間分布を前記通信部より送信する制御部とを備えるサーバ装置と協働して、前記サーバ装置から送信された前記混雑度を表示部に表示する。
請求項７に記載の電子機器は、入力部と、前記入力部からの送信要求に応じてサーバ装置より送信された所定のエリアの将来の混雑度を受信する通信部と、前記通信部より受信した前記混雑度を表示する表示部とを備える。

Claims (6)

1. 撮影位置に関する情報が付加された撮影画像、ならびに開催場所、時刻、および参加者の数の情報を含む将来のイベントの情報を受信する通信部と、
   前記通信部が受信した前記撮影画像を解析し、人数と歩道の面積から算出される現在の混雑度を出力する画像解析部と、
   歩道の面積を算出できる情報を含む地図情報を保存する地図データベースと、
   前記画像解析部が出力する前記現在の混雑度、前記撮影画像の前記撮影位置、前記地図データベースが保存する前記地図情報、および前記将来のイベントの情報に基づいて前記撮影位置を含む所定のエリアの将来の混雑度の時間分布を推定する混雑度推定部と、
   前記混雑度推定部が推定した前記将来の混雑度の時間分布を前記通信部より送信する制御部とを備える混雑度推定サーバ。
2. 請求項１に記載の混雑度推定サーバにおいて、
   前記混雑度推定部は、前記将来のイベントの開始時刻前および終了時刻後における前記撮影位置を含む所定のエリアの将来の混雑度の時間分布を推定する混雑度推定サーバ。
3. 請求項１または２に記載の混雑度推定サーバにおいて、
   前記混雑度推定部は、前記地図データベースの情報から算出する前記所定のエリアにおける歩道の面積、および前記所定のエリアを通行する前記将来のイベントの参加者の時間分布から前記将来のイベントの参加者による将来の混雑度の増加を推定する混雑度推定サーバ。
4. 請求項３に記載の混雑度推定サーバにおいて、
   前記画像解析部が出力する前記現在の混雑度を保存する混雑度データベースをさらに備え、
   前記混雑度推定部は、前記現在の混雑度および前記混雑度データベースを参照し、前記イベントの参加者による混雑度の増加を除いた前記将来の混雑度の時間分布を推定する混雑度推定サーバ。
5. 請求項１乃至４のいずれか１項に記載の混雑度推定サーバにおいて、
   前記混雑度推定サーバは、交通機関の乗降場所の平均利用者数に関する情報を保存する交通統計データベースをさらに備え、
   前記混雑度推定部は、前記イベントの開催場所から所定の距離内にある前記交通機関の乗降場所を利用する当該イベントの参加者の数を、前記イベントの開催場所から所定の距離内にある前記交通機関の乗降場所の平均利用者数の比に基づき算出し、
   前記所定のエリアにおける前記イベントの参加者により増加する将来の混雑度の時間分布を、前記地図データベースの情報から算出する当該エリアの歩道の面積と前記交通機関の乗降場所から前記イベントの開催場所へ移動する前記イベントの参加者の時間分布とから推定する混雑度推定サーバ。
6. 請求項１乃至５のいずれか１項に記載の混雑度推定サーバと、演算装置とを備える混雑度推定システムであって、
   前記演算装置は、
   前記混雑度推定サーバに要求を送信し、前記混雑度推定サーバから前記将来の混雑度の時間分布を受信する演算装置通信部と、
   前記演算装置通信部が受信した前記将来の混雑度の時間分布を出力する情報出力部とを備える混雑度推定システム。

Images