特許法第30条第2項適用 (1)ウェブサイトの掲載日1.令和2年3月25日2.令和2年7月7日3.令和2年7月27日(2)ウェブサイトのアドレス1.https://www.jreast.co.jp/development/theme/speed/speed04.html2.https://www.jreast.co.jp/press/2020/20200707_ho01.pdf3.https://konzatsu-kashika.azureedge.net/station-congestion/
実施の形態について、図面を用いて詳細に説明する。ただし、本発明は以下に示す実施の形態の記載内容に限定して解釈されるものではない。本発明の思想ないし趣旨から逸脱しない範囲で、その具体的構成を変更し得ることは当業者であれば容易に理解される。
以下に説明する発明の構成において、同一部分又は同様な機能を有する部分には同一の符号を異なる図面間で共通して用い、重複する説明は省略することがある。
本明細書等における「第1」、「第2」、「第3」などの表記は、構成要素を識別するために付するものであり、必ずしも、数または順序を限定するものではない。また、構成要素の識別のための番号は文脈毎に用いられ、一つの文脈で用いた番号が、他の文脈で必ずしも同一の構成を示すとは限らない。また、ある番号で識別された構成要素が、他の番号で識別された構成要素の機能を兼ねることを妨げるものではない。以下、図1から図17を用いて本発明の実施形態を説明する。
図1は、駅の滞留人数を推定するために必要な改札入出場者数データ、駅間を走行中の列車の乗員人数、駅で列車から乗り降りする乗員人数データとの関係性を示す図である。近年、走行中の列車(車上)から、現在の列車の位置情報などを一定周期で地上のセンターサーバに伝送する列車無線システムの導入が進んでいる。また、ほとんどの列車には、車両毎の重量に応じて加減速の度合を制御する目的で、応荷重装置が取り付けられている。各駅間を通過する度に、応荷重装置で取得した重量データから、その時点で列車に乗車している人数(「乗員人数」という)のおおよその数を計算することができる。例えば、乗員人数は、一人あたりの体重が60kgであると仮定して、応荷重装置で取得した重量を前記の体重で割って得られる商より計算することができる。そして、図1に示すように、列車から数秒おきに伝送された列車位置、駅間における乗員人数などの情報が、地上側サーバで収集、蓄積される。
列車の位置情報および乗員人数情報により、どの駅と駅の間(「駅間」という)を列車が走行中か、もしくはどの駅に列車が停車中かといった列車の状態と、それぞれの状態において何人の乗客が乗車しているかを検知することが可能になる。これにより、例えば、A路線上り方面の列車Tr1が駅ST1と駅ST2の間を走行している時の列車乗員人数をa1、駅ST2と駅ST3の間を走行している時の列車乗員人数をb1、A路線下り方面の列車Tr2が駅ST3と駅ST2の間を走行している時の列車乗員人数をa2、駅ST2と駅ST1の間を走行している時の列車乗員人数をb2というように、各列車の一連の動きと乗員人数の変化を追跡することができる。なお、列車位置情報は例えば起点からの距離(m)や、緯度・経度で示すことができる。
ここで列車Tr1と列車Tr2が、ほぼ同時刻に駅ST2に停車すると仮定した時、その停車時間帯において、駅ST2と各列車の間で乗客の乗り降りが発生する。ある時刻(または時間帯)における駅の混雑度を評価する場合、その時刻(または時間帯)において、駅構内に存在する人の数(「滞留人数」という)を指標とすることができる。ここで駅ST2の総滞留人数Pstayは、駅ST2から列車に乗る人数(「乗車人数」という)Pget_onと列車から降りる人数(「降車人数」という)Pget_offの和と考えられ、数1の関係式が成り立つ。
ここで複数の路線方面の列車が停車する駅においては、乗車人数Pget_onは、各路線方面の列車の乗車人数の和になる。すなわち、図1の例においては、列車Tr1に係るPB1と、列車Tr2に係るPB2と、の和となる。その一方で、降車人数Pget_offも、各路線方面の列車の降車人数(例えばPA1とPA2)の和になると考えられる。すなわち、図1の例においては、列車Tr1に係るPA1と、列車Tr2に係るPA2と、の和となる。
図1においては、駅ST2には、2つの路線方面の列車(すなわち、A路線上り方面の列車Tr1、および、A路線下り方面の列車Tr2)が停車する。ここで、A路線上り方面の列車Tr1と下り方面の列車Tr2の間で乗り換える乗客はいないと見なしたとき、駅ST2に改札から入場する人数(「改札入場者数」という)をIN(Penter)とすると、IN(Penter)は、A路線上りホームの列車Tr1に乗る人(PB1)と、A路線下りホームの列車Tr2に乗る人(PB2)の和で構成される。同様に、改札から出場する人数(「改札出場者数」という)をOUT(Pexit)とすると、OUT(Pexit)は、A路線の上りホームの列車Tr1から降りる人(PA1)とA路線の下りホームの列車Tr2から降りる人(PA2)の和で構成される。
そして、PenterやPexitを配分することで、複数の路線方面の列車が停車する駅における、それぞれの路線方面の列車に乗る人および降りる人を計算することができる。図1の例においては、Penter(すなわち、改札入場人数)を配分することで、A路線上りホームで列車Tr1に乗車する人数と、A路線下りホームで列車Tr2に乗車する人数と、をそれぞれ計算することができる。また、Pexit(すなわち、改札出場人数)を配分することで、A路線上りホームで列車Tr1から降車する人数と、A路線下りホームで列車Tr2から降車する人数と、をそれぞれ計算することができる。ここで、PenterやPexitを配分するための比率(配分比率)については、改札入出場者の入場駅および出場駅の組み合わせに対して、あらかじめ、経路検索エンジン等で代表的な利用経路を割り当てることで、平均的な配分比率を集計することができる。
また、駅構内に複数の路線が停車し、かつ、乗換客が存在する駅(つまり、同一の駅において列車の乗り換えが発生すると考えられる駅)については、上記の改札入場者数の配分および改札出場者数の配分に加えて、乗換者数も考慮しなければならない。乗換者数についても改札入出場者の入場駅および出場駅の組み合わせに対して、あらかじめ、経路検索エンジン等で代表的な利用経路を割り当て、乗換駅に着目して通過人数を集計することで、平均的な乗換者数を求めることができる。
ここで近年、改札入出場者数のデータを短い時間周期で地上のセンターサーバに伝送し、現在時刻に対して十数分前の改札入出場者数のデータを取得できるオンラインシステムの導入が進んでいる。そして、このような、ほぼリアルタイムに取得できる改札入出場者数のデータを用いて、上記の路線方面への配分を行うことができ、これにより、各ホームの乗車人数や降車人数を、更に高精度に計算することができる。
ただし、例えば列車が運行乱れなどにより、予定どおりに駅ST2に到着しないなどの事象が発生した場合、上記の統計的な路線方面の配分比率を用いた手法では、実際には降りる人がいないホームでも降車人数が計算されてしまうという課題がある。
そこで駅間を走行中の列車の乗員人数a1、a2、b1、b2と、列車乗員人数の統計値(すなわち、前記のa1、a2、b1、b2の統計値)との差分を利用して(つまり、現在の列車の乗員人数の値と、統計上の列車の乗員人数の値と、の数値と数値の間のひらきを利用して)、列車を乗り降りする人数を調整する。すなわち、通常時より駅間の列車の乗員人数が多い場合(つまり、統計値の列車の乗員人数の方が少なくなる場合)は、その路線方面の列車に乗り降りする人数を多くし、その逆に通常より列車の乗員人数が少ない場合(つまり、統計値の列車の乗員人数の方が大きくなる場合)は、その路線方面の列車に乗り降りする人数を少なくするなどの調整を行うことで、上記の課題を解決することができる。
このような観点から、駅ST2の乗車人数Pget_onと降車人数Pget_offのそれぞれに関して、下記の数式2のように考えることができる。すなわち、リアルタイムに取得した改札入出場者数を示すPenter_rt、Pexit_rt、路線方面の配分比率の統計値を示すRenter_sta、Rexit_sta、乗換目的で駅ST2を利用する乗換客のうちで乗換先の列車の乗車人数を示すPtra_geton_sta、乗換元の列車の降車人数を示すPtra_getoff_sta、列車の乗員人数と、列車の乗員人数の統計値との差分を示すTLdiff_rtとすると、下記の数2の関係式が成り立つ。ここで、TLdiff_rtは、実際の列車の乗員人数と、統計値の列車の乗員人数と、の差分(すなわち、実際の列車の乗員人数と、統計値の列車の乗員人数と、のひらき)が適切に評価されれば特に限定されないが、例えば、「当日における列車の乗員人数の平均値÷列車の乗員人数の統計値」で求められる値とされる。図1の例(すなわち、2つの路線を走行する列車に対して乗り降りが発生する場合)では、TLdiff_rtの値は、一例として、列車乗員人数a1と該a1の統計値の商、および、列車乗員人数b1と該b1の商を用いて、決定することができる。この場合、決定したTLdiff_rtの値を用いて、列車Tr1に運行乱れなどが発生した場合であっても、より確からしい計算を行うことができる。
上記の数1および数2の関係式は、現在の駅構内における滞留人数を推計するだけでなく、未来の時刻での駅構内における滞留人数の予測にも拡張することができる。
未来の時刻での駅ST2における総滞留人数をPpred_stayとする場合、Ppred_stayは、予測したい時刻での駅ST2における乗車人数であるPpred_get_onと、予測したい同時刻での駅ST2における降車人数であるPpred_get_offの和になると考えられる。従って、下記の数3の関係式が成り立つ。
同様にして、未来の時刻での駅ST2における乗車人数の予測値であるPpred_get_onと、未来の同時刻での降車人数の予測値であるPpred_get_offは、未来の時刻に対して予測した改札入出場者数を示すPpred_enter、Ppred_exit、路線方面の配分比率の統計値を示すRenter_sta、Rexit_sta、乗換目的で駅ST2を利用する乗換客のうちで、乗換先の列車の乗車人数を示すPtra_geton_sta、乗換元の列車の降車人数を示すPtra_getoff_sta、列車の乗員人数と、列車の乗員人数の統計値との差分を示すTLdiff_rtとすると、数4の関係式によって求められる。
ここで、未来の時刻に対する改札入出場者数であるPpred_enter、Ppred_exitは、下記の数5の関係式から求められる。すなわち、Ppred_enter、Ppred_exitは、改札入出場者数データの過去分から求めた統計値であるPenter_sta、Pexit_staにイベント開催時に増加が見込まれる改札入出場者数であるPeventを加算した値を基準値とする。そして、リアルタイムに取得した改札入出場者数であるPenter_rt、Pexit_rtとの差分であるPenter_diff_rt、Pexit_diff_rtで調整することによって求められる。
ここで、Penter_diff_rtは、例えば、リアルタイムに取得したPenter_rtと現在時刻の(Penter_sta+Pevent)との商で求めることができる。すなわち、統計値とイベント需要から求めた入場者数の予測値に対して、現在の改札入場者数との比率を求め、比率が高ければ(予測していた値より、現実の数値の方が多ければ)、この先もその傾向がしばらく続くものとして、入場者数の予測値が多くなるように調整する。Pexit_diff_rtについても、リアルタイムに取得したPexit_rtを用いて、Penter_diff_rtの場合と同様にして求めることができる。
上記の説明より、数3~数5の式を、未来の時刻での滞留人数を予測するための予測モデルとして利用することができる。
図2は、駅の滞留人数を推定するシステムの全体構成図である。近年、多くの鉄道の駅において、自動改札機(102)が設置されるようになり、鉄道を利用する乗客(利用者101)は、非接触型ICカードや、あるいは同等の機能を持つ携帯端末、磁気乗車券を、自動改札機(102)に読み取らせることにより、駅への入場、駅からの出場を行っている。自動改札機(102)で読み取った情報は、ネットワーク(107)を介して、鉄道事業者(116)が管理する履歴管理サーバ(108)へ送信される。また、列車(103)からは、前記の列車無線システムを介して、車両位置データや乗員人数データ(列車の乗員人数)などが履歴管理サーバ(108)に送信される。
次に、本実施形態での駅滞留人数推定システム(105)について詳しく説明する。なお、本実施形態を説明する際に直接関係しない車両、自動改札機(102)などの機能や構成、データ処理技術については説明を省略する。
駅滞留人数推定システム(105)は、データサーバ(111)、計算サーバ(112)、情報配信サーバ(113)からなる。これらのサーバ群(111、112、113)からなる駅滞留人数推定システム(105)は、ネットワーク(107、114)を介して、鉄道事業者(116)や情報利用者(115)と通信することができる。ここで、情報利用者(115)は、駅の滞留人数について、駅滞留人数推定システム(105)に照会する者である。従って、情報利用者(115)は、一例として、駅の利用者(101)であってもよい。また、駅滞留人数推定システム(105)は、改札通過履歴やリアルタイムの車両情報を収集、蓄積し、分析処理を行うことができる。
車両位置データや列車乗員人数データ、改札通過データは、データの蓄積と同時、もしくは一時間おきや一日おきなど適当なタイミングで、ネットワーク(107)を介して、必要な部分に関してデータサーバ(111)へ送信される。そして、データサーバ(111)は、ネットワーク(107)を介して車両位置・列車乗員人数(123)、改札入出場者数(124)をそれぞれの更新間隔に従って受信し、サーバ内のデータ格納部(121)に記録する。
また、受信したデータは集計され、列車乗員人数や改札入出場者数の統計値(125)として、データ格納部(121)に記録される。データサーバ(111)には、駅および路線のネットワーク情報を表す駅・路線情報(122)や、イベント開催時の見込みの動員人数であるイベント見込み人数(126)、駅の滞留人数の計算結果である滞留人数計算結果(127)などのデータも記録される。なお、駅・路線情報(122)やイベント見込み人数(126)に変更があった場合、適宜にシステムの外部から入力され、データサーバ(111)は、データの更新と記録を行う。
計算サーバ(112)は、データサーバ(111)に蓄積されたデータ群を用いて、駅の滞留人数を算出する処理と、その結果を格納する処理を行う。計算サーバ(112)は、主にネットワークインタフェース(I/F(A))(130)、CPU(131)、メモリ(132)、記憶部(133)からなる。
ネットワークインタフェース(I/F(A))(130)は、ネットワークに接続するためのインタフェースである。
記憶部(133)は、例えばハードディスクドライブやCD-ROMドライブ、フラッシュメモリなどの記憶装置である。記憶部(133)には、列車乗員人数集計プログラム(134)、乗降人数配分比率更新プログラム(135)、乗換人数更新プログラム(136)、改札入出場者数予測プログラム(137)、駅の滞留人数計算プログラム(138)などのプログラム群と、計算処理の過程で得られた結果を格納するデータ格納部(139)が含まれている。なお、記憶部(133)は、複数の記録装置から構成されてもよく、複数の記録装置に各種プログラム、各種データを分割して記録するようにしてもよい。
各プログラム群(134~138)が実行される際には、計算サーバ(112)は、分析対象となるデータをデータサーバ(111)から読み出してメモリ(132)へ一時的に格納し、CPU(131)で各プログラム(134~138)をメモリに読み出して実行する。これにより、各種機能を実現する。これらのプログラム(134~138)は、車両位置データや乗員人数データを新たに取得し、データサーバ(111)に格納されたタイミングで実行してもよいし、数秒おき、数分おきなどあらかじめ、決められた時間間隔に従って(つまり、決められた時間間隔でのタイミングで)、自動的に処理を実行してもよい。
本実施形態では計算や制御等の機能は、記憶装置に格納されたプログラムがプロセッサによって実行されることで、定められた処理を他のハードウエアと協働して行う。なお、計算機などが実行するプログラムまたはその機能を実現する構成を、本明細書では「機能」、「手段」、「部」、「モジュール」等と呼ぶ場合がある。
情報配信サーバ(113)は、ネットワークインタフェース(I/F(B))(145)、CPU(146)、メモリ(147)、記録装置(148)を備える。
ネットワークインタフェース(I/F(B))(145)は、ネットワークに接続するためのインタフェースである。
記録装置(148)は、各種プログラム、各種データを記録することができ、例えば、ハードディスクドライブやCD-ROMドライブ、フラッシュメモリなどの記録媒体である。なお、複数の記録媒体に各種プログラムが記録されてもよい。また、各種データを分割し、分割されたデータが複数の記録媒体に記録されてもよい。
情報配信サーバ(113)は、利用者の照合、画面表示に関する条件設定、駅の滞留人数推定結果の参照を行うためのサーバである。システム運用者(119)、鉄道事業者(116)、情報利用者(115)は、情報端末(117、118、120)を用いて、ネットワーク(114、151)を介して情報配信サーバ(113)にアクセスすることができる。
記録装置(148)には条件取得プログラム(141)と、情報配信プログラム(142)と、が含まれる。CPU(146)は、記録装置(148)に記録されている各種プログラム(141、142)をメモリ(147)に読み出して実行することにより各種機能を実行する。情報配信サーバ(113)からの情報は、基本的に各情報利用者(115)等が能動的にアクセスしたタイミングで取得される。
また、駅滞留人数推定システム(105)を運用するシステム運用者(119)は、情報端末(120)を用いてネットワーク(151)を介し、各種の蓄積データの構成や状況、計算サーバ(112)の状況や計算結果、情報利用者(115)からの検索リクエスト状況などを確認することができる。
図3は、データサーバ(111)内に格納される駅・路線情報(122)のデータ構造について示した図である。駅・路線情報(122)は、駅ID(201)、路線・方面ID(202)、停車順序(203)、路線名(204)、ホーム名(205)、番線名(206)、緯度(207)、経度(208)などの情報を含み、各路線の停車駅や、路線、駅の地理的な位置情報などを表すデータである。
駅・路線情報(122)は、変更があった場合に、鉄道事業者(116)もしくはシステム運用者(119)がシステムの外部から入力することで、その内容が更新され記録される。また、例えば、駅・路線情報(122)が曜日によって異なるような場合には、複数のテーブルを保持しておき、保持された複数のテーブルが、データ処理の対象日の曜日に応じて切り替えられてもよい。
図4は、データサーバ(111)内に格納される車両位置・列車乗員人数(123)のデータ構造について示した図である。車両位置・列車乗員人数(123)は、路線・方面ID(221)、列車ID(222)、取得日時(223)、駅1(224)、駅2(225)、乗員人数(226)などの情報を含み、車両から新たなデータを受信したタイミングで更新される。なお、車両位置・列車乗員人数(123)は、履歴管理サーバ(108)からデータを受信したタイミングで更新されてもよい。
取得日時(223)は、列車から車両情報を受信した時刻を表す。また駅1(224)および駅2(225)は、列車がどの駅間に在線しているかを表す。駅1(224)と駅2(225)が同一である場合は、列車が駅1(224)に停車中であることを表す。乗員人数(226)は、駅1(224)から駅2(225)を走行している間に、その列車に乗っている乗客の数を表す。
乗員人数(226)は、例えば列車の荷重センサから総重量のデータをそのまま受信し、データサーバ(111)が格納時に人数の値に変換してもよい。すなわち、乗員人数(226)は、列車から新たなデータを受信するタイミングで更新されてもよい。また、例えば、履歴管理サーバ(108)が総重量のデータを人数の値に変換し、既に人数の値に変換されたデータが、データサーバ(111)に出力されてもよい。乗員人数(226)は、例えば、一人あたりの体重が60kgであると仮定して、総重量のデータが示す重量を前記の体重で割って得られる商より計算することができる。
車両位置・列車乗員人数(123)に関する情報は、例えば、30秒おきなど一定周期で取得される。データ取得の間隔が非常に短い場合には、同じ駅間でのデータ(つまり、駅1(224)と駅2(225)に変化のないデータ)が何度も伝送されることになる。このとき、データサーバ(111)は、都度、異なるログIDを付与して、それぞれのデータを別々に格納してもよいし、直前に取得したデータと比較して完全に同一であれば、データを格納せずに捨ててもよい。
図5は、データサーバ(111)に格納される改札入出場者数(124)のデータ構造について示した図である。改札入出場者数(124)は、駅ID(231)、改札口ID(232)、日付(233)、時間帯(234)、種別(235)、通過人数(236)などの情報を含む。時間帯(234)の区分は、例えば1分毎、5分毎などのように、あらかじめ定義されているものとし、区分の単位については、システム運用者によってシステムの外部から入力される。種別(235)は、自動改札機(102)の通過の向きを表す情報であり、「入場」もしくは「出場」のうち、どちらかが格納される。
改札入出場者数(124)は、乗客が任意の自動改札機(102)を通過する度に、データサーバ(111)にリアルタイムに受信され、集計されて格納されてもよい。データサーバ(111)は、一例として、一定の更新タイミングに従って一括で受信したデータを処理してもよく、データサーバ(111)側では、その送信タイミングに合わせて格納処理が行われればよい。また、データサーバ(111)は、自動改札機(102)で読み取った情報を、ネットワーク(107)を介して履歴管理サーバ(108)から受信してもよい。
なお、改札入出場者数(124)のデータソースは、上記した自動改札機(102)の通過データに限定されない。例えば、IC乗車券の利用履歴がデータソースであってもよい。また、カメラやセンサから取得される改札の出入り人数がデータソースであってもよい。例えば自動改札機(102)が設置されていない駅や、IC乗車券が利用できない駅については、改札口付近に設置される監視カメラや人感センサなどから取得されるデータに、映像解析・信号解析技術を用いることによって、改札の出入り人数が求められる。また、改札通過人数やIC乗車券の利用履歴の集計処理や、映像解析や信号解析により改札の出入り人数を計算する処理は、適宜のコンピュータで実行されればよく、例えば、データサーバ(111)が処理を実行してもよいし、システムの外部で処理が実行されてもよい。
上記の説明のようにして、改札入場者数は、入場する人数を計数したデータに基づいて取得され、改札出場者数は、出場する人数を計数したデータに基づいて取得される。
図6Aおよび図6Bは、データサーバ(111)に格納される統計値(125)のデータ構造について示した図である。統計値(125)には路線・方面の利用者比率(240)、乗換者数統計値(250)、列車乗員人数統計値(260)、改札入出場者数統計値(270)などが含まれる。
路線・方面の利用者比率(240)は、駅ID(241)、期間(242)、平休(243)、時間帯(244)、改札通過種別(245)、路線・方面ID(246)、乗降種別(247)、比率(248)などの情報を含み、例えば駅ST1で入場した人のうちで、路線・方面ID001の列車に乗車する人の割合を表す。
比率(248)(上記した数式2、4で用いた比率、すなわち、配分比率に対応する。詳細には、乗降種別(247)が乗車の場合には、数式2、4のRenter_staに対応し、乗降種別(247)が降車の場合には、数式2、4のRexit_staに対応する。)を求めるためには、まず、入場駅と出場駅の組み合わせに対して、どの路線方面の列車を利用者が利用するかという経路情報が必要になる。この経路情報は経路検索エンジンなどを活用し、任意の入場駅と出場駅の組み合わせに対して検索処理を実行することで取得できる。一般的に経路検索エンジンにより得られる経路情報には、入場駅から出場駅に至るまでの路線方面のリストと、乗換駅の情報が含まれている。そこで、入場駅と出場駅の組み合わせごとに利用人数の統計値を求めて、経路情報と突き合わせることで、改札を入場した後に、ある路線方面の列車に乗る人が、それぞれ何人いるか、それは改札入場者全体の中で、どの程度の比率であるかを集計することができる。比率を求める一例として、入場駅から出場駅に至るまでの経路情報の取得に併せて、入場駅から出場駅に至るまでの路線方面ごとに、過去データから求めた利用人数の統計値も取得することができる経路検索エンジンを用いることができる。
路線・方面の利用者比率(240)には、ある期間(242)の改札入出場者数(124)を用いて、平休(243)や時間帯(244)の区分ごとに、各駅における路線方面別の乗り降りに関する人数の比率(248)が計算された結果が格納される。しかしながら、入場駅と出場駅の組み合わせごとの経路情報や利用人数は、例えば、ダイヤ改正などの列車の運行状況変化や都市開発の影響などによって、多少変動することが考えられるため、この路線・方面の利用者比率(240)は、定期的に更新する必要がある。
路線・方面の利用者比率(240)において、改札通過種別(245)が入場であれば、乗降種別(247)は乗車になり、改札通過種別(245)が出場であれば、乗降種別(247)は降車になる。例えば、一路線しか停車しないシンプルな駅では、一般的には、上り方面と下り方面の2つの路線・方面ID(246)の列車が停車する。そのため、当該駅において、ある時間帯(244)に改札から入場した改札入場者数は、上り方面の列車に乗車する人数と、下り方面の列車に乗車する人数に分配され、路線方面別の比率(248)の和は1となる。すなわち、同時間帯(244)の乗車において、上り方面と、下り方面と、の相違する2種類の路線・方面ID(246)に係る比率(248)の和は1となる。また、当該駅において、ある時間帯(244)に改札から出場した改札出場者数は、上り方面の列車からの降車の人数と、下り方面の列車からの降車の人数に分配され、路線方面別の比率(248)の和は1となる。すなわち、同時間帯(244)の降車において、上り方面と、下り方面と、の相違する2種類の路線・方面ID(246)に係る比率(248)の和は1となる。図6Aを用いて比率の例について具体的に説明する。例えば、平日の12:00~12:05の時間帯(244)で、路線・方面ID001を上り方面と仮定すると、上り方面に関する乗車の比率(248)は0、6である。そして、平日の同時間帯(244)において、路線・方面ID001とは異なるID(図6Aにおいて不図示)を下り方面と仮定すると、下り方面に関する乗車の比率(248)は0.4(すなわち、1-0.6)である。同様にして、降車についても説明する。図6Aにおいて、例えば、平日の12:00~12:05の時間帯(244)で、路線・方面ID001を上り方面と仮定すると、上り方面に関する降車の比率(248)は0.8である。そして、平日の同時間帯(244)において、路線・方面ID001とは異なるID(図6Aにおいて不図示)を下り方面と仮定すると、下り方面に関する降車の比率(248)は0.2(すなわち、1-0.8)である。
乗換者数統計値(250)は、駅ID(251)、期間(252)、平休(253)、時間帯(254)、乗換前路線・方面ID(255)、乗換後路線・方面ID(256)、人数(257)などの情報を含み、複数の路線があって異なる路線方面の列車への乗り換えが発生し得る駅を対象に、乗換者だけに注目した統計値である。
例えば駅ST2に、路線・方面ID(246)が001と003である列車が停車する場合に、路線・方面IDが001から003への列車の乗換と、その逆方向への列車の乗換が考えられる。乗換者数統計値(250)には、乗換を含む駅を対象に、全ての乗換パターン(乗換前路線・方面ID(255)と乗換後路線・方面ID(256)の組み合わせ)ごとに、それぞれの人数(257)が格納される。ここで、人数(257)は、乗換者の数である。すなわち、人数(257)は、乗換者数統計値(250)上の同一のレコードにおいて、乗換前路線・方面ID(255)の列車から降車する人数(数式2、4のPtra_getoff_staに対応)と、乗換後路線・方面ID(256)の列車に乗車する人数(数式2、4のPtra_geton_staに対応)と、の両方の人数に対応する。
乗換者数の統計値は、路線・方面の利用者比率(240)の計算の場合と同様に、入場駅と出場駅の組み合わせごとに利用人数の統計値を求めて、経路情報と突き合わせることで、計算することができる。なお、入場駅と出場駅の組み合わせごとの利用人数や経路情報は、列車の運行状況や都市開発の影響などによって、多少変動することが考えられるため、この乗換者数統計値(250)も定期的に更新することが望ましい。
列車乗員人数統計値(260)は、駅ID(261)、期間(262)、平休(263)、時間帯(264)、路線・方面ID(265)、乗員人数(266)などの情報を含み、車両位置・列車乗員人数(123)に格納されているレコードのうちで、指定された期間(262)のレコードを対象に集計することで作成される。
改札入出場者数統計値(270)は、駅ID(271)、期間(272)、平休(273)、時間帯(274)、種別(275)、人数(276)などの情報を含み、改札入出場者数(124)に格納されているレコードのうちで、指定された期間(272)のレコードを対象に集計することで作成される。
なお、改札入出場者数統計値(270)は、過去の改札通過データのパターン分類結果や、平均値などの公知の推定手法を使って求めることもできる。推定手法については、特許文献(特開2010-061321号公報)にも例が示されている。他にも例えば、過去の同一または類似の条件(同一日時、天候、その他イベント等)のデータから推定したデータ、あるいは、予測モデルを用いて推定した値を用いることもできる。
図7は、データサーバ(111)に格納されるイベント見込み人数(126)のデータ構造について示した図である。イベント見込み人数(126)は、駅ID(281)、改札口ID(282)、日付(283)、開始・終了時刻(284)、持続時間(285)、種別(286)、利用人数(287)などの情報を含み、イベント開催時に最寄り駅を利用すると思われる入場者数または出場者数の増加分を表すデータである。
イベント会場の最寄り駅に改札口が複数あり、会場へのアクセスの良さなどの観点から、改札口の利用比率に明らかに偏りが出ると予想されるときには、駅ID(281)以外に改札口ID(282)も指定し、イベント開催による最寄り駅の利用人数(287)の需要増加を細かく表現してもよい。例えば、駅ST1において2つの改札口G1およびG2があり、改札口G1と改札口G2の利用比率に明らかに偏りが出ると予想されるときには、駅ST1の改札口G1の利用人数(287)および駅ST1の改札口G2の利用人数(287)が、それぞれ別々にイベント見込み人数(126)上で表現されてもよい。
開始・終了時刻(284)は、イベント開催やイベント終了により、最寄り駅の利用人数に初めて変化が表れる時刻もしくは変化が終わる時刻を表す。例えば、イベント自体の開始時刻が16:30かつ、イベント会場が最寄り駅のすぐそばに位置している場合、最寄り駅の出場者数は、イベント開始時刻である16:30直前まで多くなることが想像される。しかし、イベント参加者の全員が開始時刻間際に来場するわけではなく、もう少し早い時間に最寄り駅を出場し、イベント会場付近で待機する人もいると考えられる。その時間幅が持続時間(285)の値であり、例えば120分など分単位で格納される。イベント終了後の利用者の流れも同様に考えることができ、イベント終了時刻の直後に最寄り駅から入場し、帰路につく人もいれば、会場付近で少し時間をつぶしてから、最寄り駅に入場する人もいると考えられる。イベント見込み人数(126)は、変更があった場合に、鉄道事業者(116)もしくはシステム運用者(119)がシステムの外部から入力し、更新されて記録される。
図8は、データサーバ(111)に格納される滞留人数計算結果(127)のデータ構造について示した図である。滞留人数計算結果(127)は、駅ID(291)、日付(292)、時間帯(293)、ホーム名(294)、番線名(295)、乗降種別(296)、人数(297)などの情報を含み、各駅および各番線の乗車人数もしくは降車人数を表すデータである。時間帯(293)の区分は、適宜に設定してもよいが、計算処理の簡便性を考慮して、改札入出場者数(124)の時間帯区分および統計値(125)の時間帯区分と一致していることが望ましい。
図9は、車両位置・列車乗員人数(123)のデータと、列車乗員人数集計プログラム(134)と、を用いて、列車乗員人数統計値(260)を計算する手順を説明する図である。
計算サーバ(112)は、まず、データサーバ(111)内の駅・路線情報(122)を読み込み、駅ID(201)および路線・方面ID(202)の組み合わせを取得する(処理ステップS101)。
計算サーバ(112)は、集計対象の期間および時間帯の情報をプログラム(134)の外部から取得する(処理ステップS102)。
計算サーバ(112)は、データサーバ(111)の車両位置・列車乗員人数(123)のデータから取得日時(223)を参照し、処理ステップS102で取得した集計対象期間および時間帯に該当するデータ期間および時間帯に含まれるレコードを読み込んで抽出する(処理ステップS103)。
計算サーバ(112)は、路線・方面ID(221)、駅2(225)の組み合わせ、および、平休の区分ごとにレコードを分類し、分類したレコードを用いて乗員人数(226)の平均値を区分ごとに求める。そして、その計算結果が集計された列車乗員人数統計値(260)を、計算結果を記録するデータ格納部(139)に格納する(処理ステップS104)。なお、処理ステップS104では、乗員人数(266)の平均値が、取得日を考慮して求められてもよく、例えば、当日における列車の乗員人数(226)の平均値が求められてもよい。
図10は、列車の乗員人数に関して当日と統計値との差分(当日と統計値のひらき)を考慮しながら、改札入場者数を各路線方面に配分して更新された乗車人数(入場して列車に乗車する人数)を求め、改札出場者数を各路線方面に配分して更新された降車人数(降車して出場する人数)を求める処理手順を説明する図である。図10の処理においては、乗降人数配分比率プログラム(135)を用いた処理が実行される。
計算サーバ(112)は、まず、プログラム(135)の外部から、乗降人数の計算対象とする駅IDの情報を取得し、データサーバ(111)内の駅・路線情報(122)を読み込み、駅ID(201)および路線・方面ID(202)の値から、計算対象の駅に停車する列車の路線・方面ID(202)のリスト(一覧)を取得する(処理ステップS201)。
計算サーバ(112)は、取得した全ての路線・方面ID(202)について以降の処理を繰り返す。計算対象の駅および計算対象の路線・方面ID(202、221)に一致する、当日における列車の乗員人数(226)の平均値を取得する。なお、上記した列車乗員人数集計プログラム(134)の処理(すなわち、処理ステップS104の処理)において、当日における列車の乗員人数(226)の平均値を求めた場合、処理ステップS104の結果から、当日における列車の乗員人数(226)の平均値を取得してもよい。これに加えて、列車乗員人数集計プログラム(134)により求めた、統計値(125)に含まれる列車乗員人数統計値(260)を読み込み、計算対象の駅および計算対象の路線・方面ID(202、265)に一致する乗員人数(266)の値を取得する(処理ステップS202)。
計算サーバ(112)は、上記の処理ステップS202により取得した2つの値(当日における列車の乗員人数(226)の平均値と列車の乗員人数(266)の統計値)を用いて、当日と統計値との差分を表す値であるTLdiff_rtを計算する。TLdiff_rtは、例えば、「当日における列車の乗員人数(226)の平均値÷列車の乗員人数(266)の統計値」で求めることができる(処理ステップS203)。
計算サーバ(112)は、上記のTLdiff_rtの値を用いて、比率(248)の更新を行う。計算サーバ(112)は、統計値(125)に含まれる路線・方面の利用者比率(240)を読み込み、更新する対象の駅ID(241)、対象の期間(242)および対象の時間帯(244)、対象の路線・方面ID(246)を含むレコードを抽出する。そして、乗車の比率(248)と降車の比率(248)それぞれに、TLdiff_rtを掛けることで、比率(248)を更新する。(処理ステップS204)。詳細には、乗車の比率(248)にTLdiff_rtを掛けることで(上記の数式2、4で説明すると、Renter_staにTLdiff_rtを掛けることで)、乗車の比率(248)が更新される。また、降車の比率(248)にTLdiff_rtを掛けることで(上記の数式2、4で説明すると、Rexit_staにTLdiff_rtを掛けることで)、降車の比率(248)が更新される。ここで、更新する対象の期間および対象の時間帯は、プログラム(135)の外部から指定されるものとする。このようにして、配分比率が更新される。
計算サーバ(112)は、データサーバ(111)内に格納された改札入出場者数(124)から、乗車する人数の計算対象となる駅の改札入場者数(すなわち、乗車する人数の計算対象となる駅ID(231)において、種別(235)が「入場」である通過人数(236)の値)を取得する。そして、上記の処理ステップS204で更新した乗車の比率(248)を取得した計算対象駅の改札入場者数に掛け、更新された人数(すなわち、入場して列車に乗車する人数)を求める(処理ステップS205)。すなわち、上記の数式2、4で説明すると、Penter_rtに、更新した乗車の比率(248)である(Renter_sta×TLdiff_rt)を掛ける処理を行う。計算サーバ(112)は、同様にして、データサーバ(111)内に格納された改札入出場者数(124)から、降車する人数の計算対象となる駅の改札出場者数を取得し、上記の処理ステップS204で更新した降車の比率(248)を取得した計算対象駅の改札出場者数に掛け、更新された人数(すなわち、列車から降車して出場する人数)を求める(処理ステップS206)。すなわち、上記の数式2、4で説明すると、Pexit_rtに、更新した降車の比率(248)である(Rexit_sta×TLdiff_rt)を掛ける処理を行う。
図11は、列車の乗員人数に関して当日と統計値との差分(当日と統計値のひらき)を考慮しながら、乗換人数を更新する処理手順を説明する図である。図11の処理においては、乗換人数更新プログラム(136)を用いた処理が実行される。
計算サーバ(112)は、まず、プログラム(136)の外部から、乗換人数の計算対象とする駅IDの情報を取得して、データサーバ(111)内の駅・路線情報(122)を読み込み、駅ID(201)および路線・方面ID(202)の値から、計算対象の駅に停車する路線・方面ID(202)のリスト(一覧)を取得する(処理ステップS301)。
計算対象となる駅に2つ以上の路線があり、当該駅が異なる路線方面の列車への乗り換えが発生し得る駅である場合(ただし、同じ路線の上り方面の列車と下り方面の列車の間では、乗り換えがないとして)、計算サーバ(112)は、乗り換えが発生し得る駅について、取得した路線・方面ID(202)のリストから乗換前路線・方面ID(255)と乗換後路線・方面ID(256)の組み合わせを作成する。なお、乗り換えが発生し得る駅かどうかについては、駅ID(201、251)を比較したり、路線名(204)を用いた処理を行うことで、適宜に判定することができる。そして、計算サーバ(112)は、以降の処理を繰り返す。計算サーバ(112)は、計算対象の駅、および、乗換前路線・方面ID(255)に一致する、当日における列車の乗員人数(226)の平均値を取得する。これに加えて、統計値(125)に含まれる列車乗員人数統計値(260)を読み込み、計算対象の駅および乗換前路線・方面ID(255)に一致する路線・方面ID(265)の乗員人数(266)の値を取得する(処理ステップS302)。
計算サーバ(112)は、上記の処理ステップS302により取得した2つの値(列車の乗員人数の平均値と統計値)を用いて、当日と統計値との差分を表す値であるTLdiff_rtを計算する。TLdiff_rtは例えば、「当日における列車の乗員人数の平均値÷列車の乗員人数の統計値」で求めることができる(処理ステップS303)。
計算サーバ(112)は、次に統計値(125)に含まれる乗換者数統計値(250)を読み込み、計算する対象の駅ID(251)、計算する対象の期間(252)および対象の時間帯(254)、計算する対象の路線・方面IDが乗換前路線・方面ID(255)と一致するレコードを抽出し、人数(257)の値を取得する。計算サーバ(112)は、取得した人数(257)の値にTLdiff_rtを掛けることで、乗換時の降車人数を求める(処理ステップS304)。上記の数式2、4で説明すると、Ptra_getoff_staに、TLdiff_rtを掛けて更新する処理を行う。
計算サーバ(112)は、同様に、統計値(125)に含まれる乗換者数統計値(250)を読み込み、計算する対象の駅ID(251)、計算する対象の期間(252)および対象の時間帯(254)、計算する対象の路線・方面IDが乗換後路線・方面ID(256)と一致するレコードを抽出し、人数(257)の値を取得する。計算サーバ(112)は、取得した人数の値にTLdiff_rtを掛けることで、乗換時の乗車人数を求める(処理ステップS305)。上記の数式2、4で説明すると、Ptra_geton_staに、TLdiff_rtを掛けて更新する処理を行う。なお、乗換者数を計算する対象の期間(252)および対象の時間帯(254)は、プログラム(136)の外部から指定されるものとする。このようにして、差分を考慮した乗換者数を計算することができ、乗換者数を更新することができる。
図12は、イベント開催時に増加すると思われる利用者数の増加分を考慮して、未来の時刻の改札入場者数を予測する処理手順を説明する図である。改札入場者数の予測を例として説明するが、改札出場者数の予測についても処理手順は同様である。図12の処理においては、改札入出場者数予測プログラム(137)を用いた処理が実行される。
計算サーバ(112)は、まず、プログラム(137)の外部から、未来の時刻の改札入場者数の計算対象とする駅IDと、予測対象日時と、の情報を取得する(処理ステップS401)。
計算サーバ(112)は、次に統計値(125)に含まれる改札入出場者数統計値(270)を読み込み、上記の処理ステップS401で取得した、計算対象の駅と計算対象の日付の平休区分および時間帯に該当するレコードを検索し、改札入場者数の統計値である人数(276)を取得する(処理ステップS402)。
計算サーバ(112)は、次にイベント見込み人数(126)を読み込み、上記の処理ステップS401で取得した、計算対象の駅と予測対象日の日付において、入出の種別(286)が入場であるレコードを検索し、かつ、開始・終了時刻(284)から持続時間(285)が経過するまでの時刻に、予測の対象となる時刻(予測対象日時の時刻)が該当しているかどうかについて判定する。そして、該当レコードがある場合は、該当するレコードから、イベントの開始・終了時刻(284)と持続時間(285)と利用人数(287)の値を取得する(処理ステップS403)。
イベント開催時に増加が見込まれる改札入場者数や改札出場者数の変化は、イベント開始・終了時刻の前後に瞬間的に発生するわけではなく、ある時間幅を持って変化することが想像される。そのため、計算サーバ(112)は、イベントの開始・終了時刻(284)と持続時間(285)を参照し、イベントの開催時に増加することが見込まれる改札の利用人数(287)(図12では、イベント動員人数と記載)の値を各時間帯に配分する(処理ステップS404)。ここで、配分方法の例としては、例えばベータ分布など、統計的な分布に従って、配分する方法を挙げることができる。また、過去に開催されたイベント日の改札入出場者数の値から求めた平均値を用いて配分する方法であってもよい。
計算サーバ(112)は、次に処理ステップS402で取得した改札入場者数の統計値である種別(275)が「入場」の人数(276)に、処理ステップS404で求めた、イベント開催時に増加することが見込まれる改札入場者数を加算し、和Sを求める(処理ステップS405)。なお、改札出場者数の予測を行う場合では、改札出場者数の統計値である種別(275)が「出場」の人数(276)に、処理ステップS404で求めた、イベント開催時に増加することが見込まれる改札出場者数を加算し、和Sを求める。
そして、現在時刻において、改札入場者数の統計値と、イベント開催時に増加することが見込まれる改札入場者数と、の和Sが、リアルタイムに取得した改札入場者数の値と、ある程度の乖離がある場合がある。この場合には、差分Penter_diff_rtを計算し、上記の和Sの値を補正する(処理ステップS406)。ここで、差分Penter_diff_rtは、例えば、「リアルタイムに取得した改札入場者数の値÷(改札入場者数の統計値とイベント開催時に増加することが見込まれる改札入場者数増加分である、処理ステップS405で求められる和S)」で計算できる。改札出場者数の予測を行う場合では、差分Pexit_diff_rtは、例えば、「リアルタイムに取得した改札出場者数の値÷(改札出場者数の統計値とイベント開催時に増加することが見込まれる改札出場者数増加分である、処理ステップS405で求められる和S)」で計算できる。これにより、統計値とイベント需要から求めた改札入場者数の予測値に対して、現在の改札入場者数の比率が高ければ(予測していた改札入場者数より、現実の改札入場者数の方が多ければ)、この先もその傾向が、しばらく続くものとして、改札入場者数の予測値が多くなるように調整することができる。なお、この補正については、予測したい対象日時(予測対象日時)と、現在時刻との間の時間差を考慮し、必要に応じて増幅や減衰させることができる。例えば現在時刻+1時間後までは、Penter_diff_rtの係数をそのまま用いて補正を行うが、現在時刻+1時間先以降は、Penter_diff_rtの係数に0.5を掛けて、重みを半分にして適用するなど、時間経過とともに補正の効果を薄めることができる。改札出場者数の予測を行う場合についても、同様にして、補正の効果を調整することができる。
図13は、駅の滞留人数を計算する処理手順を示す流れ図である。駅の滞留人数計算プログラム(138)は、データサーバ(111)の改札入出場者数(124)が更新されたタイミングか、もしくはあらかじめ定められた間隔に合わせて、実行される。図13の処理においては、駅の滞留人数計算プログラム(138)を用いた処理が実行される。
計算サーバ(112)は、まず、プログラム(138)の外部から計算対象とする駅IDと路線方面の情報を取得する(処理ステップS501)。次に計算対象日時の情報を取得する(処理ステップS502)。処理ステップS502で取得した計算対象日時が未来の時刻である場合、改札入出場者数予測プログラム(137)により、改札入場者数と改札出場者数の予測値(改札入出場者数の予測値)を求める(処理ステップS503)。また、処理ステップS503では、改札入出場者数予測プログラム(137)の処理(改札入場者数の場合は処理ステップS402)で取得される、改札入出場者数の統計値である人数(276)も取得される。すなわち、処理ステップ503は、未来の所定時間帯における滞留人数の計算にあたり、イベント時に増加する改札入場者数(または改札出場者数)と、所定時間帯での改札入場者数(または改札出場者数)の統計値である人数(276)と、の和S(差分により補正された場合は、和Sの補正値)を求めるステップである。その一方で、処理ステップS502で取得した計算対象日時が現在時刻である場合は、リアルタイムに取得される改札入出場者数を取得する(処理ステップS504)。
計算サーバ(112)は、処理ステップS503および処理ステップS504のいずれかで求めた、改札入場者数および改札出場者数に基づき、乗降人数配分比率更新プログラム(135)を呼び出すことにより、配分比率である比率(248)を用いて更新された乗車する人数(入場して列車に乗車する人数)および降車する人数(列車から降車して出場する人数)を取得する。また、計算サーバ(112)は、乗換人数更新プログラム(136)を呼び出すことにより、計算対象の路線方面の列車から乗り降りする人数(更新された乗換人数)を取得する。そして、計算サーバ(112)は、取得した更新された乗車人数と、取得した更新された降車人数と、取得した更新された乗換人数と、を集計して、その結果を滞留人数計算結果(127)に格納する(処理ステップS505)。なお、処理ステップS503で改札入出場者数の予測値を取得した場合、処理ステップS505においては、予測モデル(上述した数3~数5)が取得されて、予測モデルに基づく滞留人数計算結果(127)が求められる。その一方で、計算対象日時が現在時刻である場合は、数式1、2に基づく滞留人数計算結果(127)が求められる。
図14は、情報配信サーバ(113)によって、システム運用者(119)、鉄道事業者(116)、情報利用者(115)向けに生成および配信される、駅の滞留人数表示のための条件設定画面の一例を示した図である。これらの利用者は、情報配信サーバ(113)からの配信データを適宜のディスプレイに表示させて利用することができる。
条件設定画面(1000)において、情報利用者(115)が、ユーザ名入力欄(1001)にユーザ名、対象路線・駅選択欄(1002)に検索対象の路線や駅、対象日選択欄(1003)に検索対象の日付などを直接入力、またはプルダウンメニューなどで選択し、実行ボタン(1004)を押すことによって、情報配信サーバ(113)にリクエストが伝達される。
なお、これらの表示条件(すなわち、条件設定画面(1000)の表示の態様)は、特に限定されず、利用者によって適宜に設定・変更することが可能である。利用者は、例えば設定画面やマウス・キーボードなどの入力インタフェースを用いて、表示条件などを設定・変更することができる。例えば、ユーザ名入力欄(1001)は、必要のない場合、表示自体を省略することができる。また、例えば、対象路線・駅選択欄(1002)については、選択肢が多くなる場合には、まず路線を選択してから次に駅を選ぶなど、段階的な選択を行うことができるように、変更されてもよい。また、対象路線・駅選択欄(1002)や対象日選択欄(1003)については、この画面例では一つの選択肢を選択する場合を示したが、ウィンドウを大きくするなどして、複数の選択肢を同時に選ぶことができるように、変更されてもよい。
図15は、駅の滞留人数を参照するために検索条件が入力され、リクエストされたタイミングで実行される情報配信処理の手順を説明する図である。
情報配信サーバ(113)は、条件取得プログラム(141)の実行において、まず条件設定画面(1000)で入力された条件を取得する(処理ステップS601)。次にユーザ名入力欄(1001)が入力されている場合には、正しくアクセス権限を有しているかの照合を行う(処理ステップS602)。ユーザ名の入力が必要でない場合は、この処理を省略する。アクセス権限を確認した後、情報配信プログラム(142)を呼び出す(処理ステップS603)。
図16は、入力された検索条件に従って配信画面を生成し、配信する処理手順を説明する図である。
情報配信サーバ(113)は、情報配信プログラム(142)の実行において、まず、条件取得プログラム(141)で取得した条件を受け取り(処理ステップS701)、滞留人数計算結果(127)から集計対象の駅および日付に該当するレコードを抽出する(処理ステップS702)。次に抽出したレコードを時系列グラフや地図画面へのマッピングなど、わかりやすい形式に加工し、配信を行う(処理ステップS703)。これらのプログラム(つまり、加工処理に用いるプログラム)は、情報配信サーバ(113)内にあらかじめ用意され、情報配信サーバ(113)は、用途ごとにこれらのプログラムを組み合わせて加工処理することが望ましい。ただし、プログラムを組み合わせないで加工処理が行われてもよいし、クライアント側のコンピュータで加工処理が行われてもよい。
図17は、情報配信サーバ(113)によって生成および配信される提示画面の一例であり、図14で示した条件設定画面からリクエストされ、加工処理が終わったタイミングで配信される画面の例を示した図である。
提示画面(1100)は、例えば日付、時刻が表示される日付・時刻表示領域(1101)、駅の滞留人数や、列車の乗員人数が地図上に表示された混雑状況全体図(1102)、ある特定の駅の滞留人数の予測結果を時系列グラフで表示した混雑予測図(1103)などで構成される。
地図上(ここでは、混雑状況全体図)では、駅や列車シンボルが表示されている。ここで、駅や列車シンボルは、あらかじめ定められた閾値によりレベル分けされた混雑度に応じて、大きさや色を異ならせて表示することができる。これにより、利用者に混雑状況をわかりやすく伝えることができる。
提示画面(1100)には、混雑度に併せて列車の遅延情報などが表示されてもよい。
提示画面(1100)には、ある時間帯もしくは一日を通して、混雑すると考えらえる順に駅がソートされている表が表示されてもよい。ここで、駅をソートする処理は、情報配信サーバ(113)側で行ってもよいし、クライアント側のコンピュータで行ってもよい。
画面(1100)には、全体を俯瞰することができる画像を表示させることができるので、システム運用者(119)や鉄道事業者(116)にとって、運行計画の見直しや混雑している駅の支援策の立案などの業務改善につながることが考えられる。
情報利用者(115)は、マウスやキーボードなどの適宜の入力インタフェースを用いて操作することにより、提示画面(1100)の表示を調節したり、提示画面(1100)の表示を変更したりすることができる。例えば、ホイールボタンなどを利用者が操作することなどによって、地図画面のズームイン/ズームアウトが実行されてもよい。また、マウスで駅や列車のシンボルを選択してクリックすることによって、列車IDや運行実績などの詳細な情報の表示が実行されてもよい。なお、画面の表示を調節/変更するためのプログラムは、利用者側のコンピュータに格納される。
また、タッチパネルに提示画面(1100)が出力される場合、情報利用者(115)は、指や専用ペンで操作してもよい。
また、上記で説明した以外にも、提示画面(1100)の表示態様は、適宜に変更することができる。例えば、混雑状況全体図(1102)の配置と混雑予測図(1103)の配置を変更してもよいし、不要であれば、日付・時刻表示領域(1101)を省略してもよい。また、例えば、「かなり混雑するでしょう。」などの混雑情報を示す文字情報が表示されてもよい。
以上、本発明の実施形態について説明したが、本実施形態では、リアルタイムでのデータ入手が容易な車両の荷重データを活用し、さらに改札等から入退場した乗客のデータで補完することにより、駅の滞留人数を推定することができる。本発明は上記実施形態に限定されるものではなく、種々な変形が可能である。
本実施形態では、駅滞留人数推定システム(105)は、データサーバ(111)、計算サーバ(112)、情報配信サーバ(113)のサーバ群として説明されていたが、駅滞留人数推定システム(105)は、1つのサーバによってこれらのサーバ群の機能を実行できるように構成されていてもよい。また、複数のサーバによってこれらサーバ群の機能を実行できるように構成されていてもよい。
システム運用者(119)、鉄道事業者(116)、情報利用者(115)向け以外でもよく、これらの者以外にも、情報配信サーバ(113)は、データを提供してもよい。