以下、図面を参照して開示の技術の実施形態の一例を詳細に説明する。なお、機能が同じ働きを担う構成要素及び処理には、全図面を通して同じ符号を付与し、重複する説明を適宜省略する場合がある。
スマートフォン等の情報機器及びソーシャルメディアの普及と共に、誰もが様々な場所で発生した事象を即座に発信し、発信した情報を共有してコミュニケーションをとる機会が増えている。従って、例えば災害が発生した場合、災害現場を目撃したソーシャルメディアのユーザは、ソーシャルメディアを通じて災害が発生したことを知らせる情報を発信する場合がある。
こうしたソーシャルメディアの持つ即時性、情報発信性、及び情報共有性を利用して、近年では、ソーシャルメディアを防災ツールの1つとして活用しようとする動きが、行政及び企業ともに進められている。
災害はいつどこで発生するかわからないため、災害の発生直後は災害に関する情報が少なく、時間の経過と共に災害に関する情報が増加する傾向にある。従って、迅速な災害対応のため、どこで災害が発生したかを知らせる情報に対する自治体等のニーズは高い。
そこで、災害情報提供機関(以下、提供機関と称す)では、ユーザの発言から発言の発信場所を特定し、災害の発生場所を推定する試みが行われている。
ユーザの発言から発言の発信場所に関する情報を取得する方法には、例えば発言に付加されるGPS(Global Positioning System)情報を利用する方法、又は発言の本文に含まれるランドマーク情報を利用する方法がある。ランドマーク情報とは、例えば駅名及び建物名等といった発言の発信場所を推定することができる情報をいう。その他、発言から発言の発信場所に関する情報を取得する方法には、例えば発言を発信したユーザが予めソーシャルメディアに登録したユーザプロフィール情報に含まれる、自身の居住地域情報を利用する方法がある。
しかし、発言にGPS情報を付加するユーザの割合は、GPS情報を付加しないユーザの割合に比べて少なく、また、発言の本文に必ずしもランドマーク情報が含まれるとは限らない。また、ユーザプロフィール情報に自身の正しい居住地域情報を登録するユーザの割合も、正しい居住地域情報を登録していないユーザの割合に比べて少ない。従って、上記に示した方法を用いても、多くの場合、ユーザの発言から発言の発信場所を取得することは困難である。
そこで、ユーザが発信した過去の発言のうち、既に説明した方法により発信場所が取得できる発言を用いてユーザ毎に生成される位置集計テーブルを利用し、発信場所が不明である発言の発信場所を推定する方法が用いられる場合がある。
図24は、位置集計テーブルの一例を示す図である。位置集計テーブルは、ユーザがどの時間帯にどの場所から何件の発言を発信したか表す履歴情報を示すテーブルである。図24の位置集計テーブルは、例えば1日を朝、昼、夜の3つの時間帯に分け、A市、B町、及びC村の各々の基礎自治体から発信された発言の発信数を示している。
ここで基礎自治体とは、日本の場合、市町村で表される行政単位を指し、日本以外の他国においては、日本の市町村に相当する行政単位をいう。なお、以下では、「基礎自治体」を「自治体」と表す。
図24の例において、朝の時間帯は、C村からの発言の発信数が他の自治体からの発言の発信数に比べて10倍以上となっている。また、昼の時間帯は、A市からの発言の発信数が他の自治体からの発言の発信数に比べて10倍以上となっている。更に、夜の時間帯は、C村からの発言の発信数が他の自治体からの発言の発信数に比べて10倍以上となっている。
仮に、特定の自治体からの発言の発信数が他の自治体からの発言の発信数に比べて10倍以上となる状態を、発信数に偏りがある状態、即ち自治体からの発信数に有意差がある状態とすれば、図24に示す位置集計テーブルには有意差が認められる。従って、提供機関は、図24に示す位置集計テーブルに対応するユーザ(例えばユーザAとする)が、朝及び夜の時間帯はC村にいて、昼の時間帯はA市にいると推定することができる。即ち、提供機関は、ユーザAの発言に位置情報が含まれていない場合であっても、例えば朝の時間帯に発信された発言はC村から発信されたと推定することができる。
一方、図25は、ユーザAとは異なるユーザ(例えばユーザBとする)の位置集計テーブルの一例を示す図である。
図25の位置集計テーブルでは、朝、昼、及び夜の全ての時間帯で特定の自治体からの発言の発信数が他の自治体からの発言の発信数に比べて10倍未満となっているため、発信数に有意差が認められる自治体は存在しない。従って、提供機関は、図25に示す位置集計テーブルから、ユーザBの位置情報が含まれない発言(発信地不明発言)の発信位置を推定することは困難となる。
なお、説明の便宜上、ここでは特定の自治体からの発言の発信数が他の自治体からの発言の発信数に比べて10倍以上となる状態を発信数に有意差がある状態としたが、これは自治体間における発言の発信数の有意差を判定するための一例に過ぎない。各自治体からの発言の発信数に有意差があるか否かの判定は、公知の有意差の判定方法、例えば統計的手法であるカイ2乗検定等を用いてもよい。
一方、各自治体からの発言の発信数に有意差が認められない位置集計テーブルから、発信地不明発言の発信位置を推定する方法として、例えば発信地不明発言の発信位置は、自治体での過去の発言の発信数に応じた確率に従うと仮定する方法が考えられる。
図26は、図25に示す位置集計テーブルに基づいて、時間帯毎に、各自治体でユーザBが発言を発信した確率を示す図である。図26の例では、ユーザBは朝の時間帯にA市から発言を発信する確率が2/3、B町から発言を発信する確率が1/3、C村から発言を発信する確率が0であることを示している。
しかし、図26に示す図は、自治体からの発言の発信数に有意差がみられない位置集計テーブルから算出された、時間帯毎の各自治体における発言の発信確率を示すものである。従って、例えばユーザBは、朝の時間帯に通常はB町にいないが、偶然B町にいてソーシャルメディアに発言を発信したことがあれば、確率的に朝の時間帯にB町から発言を発信することがあると判定されてしまうことになる。
従って、発信地不明発言に対して、再びユーザBが発言することのない自治体から発言が発信されたと推定される場合があり、発信地不明発言の発信位置を精度よく推定することが困難となる。
以下では、ソーシャルメディアの発言に位置情報が含まれない場合であっても、ユーザ毎に発言の発信位置を精度よく推定し、推定した発言の発信位置から、例えば災害の発生位置を推定する例について説明する。なお、ここではソーシャルメディアのうち、例えばソーシャルネットワーキングサービス(Social Networking Service:SNS)を利用するユーザのSNS上の発言(SNSデータ)から、発信地不明発言の発信位置を推定する例について説明する。しかし、ソーシャルメディアはSNSに限定されず、ブログ又は掲示板等、ソーシャルメディアに属する他のメディアに対しても以下に説明する発言の位置推定方法を適用できる。
図1は、本実施形態に係る位置推定システム1の構成を示す図の一例である。
図1に示すように、位置推定システム1は、位置推定装置10、通信回線40、及びSNSサーバ50を含む。位置推定装置10及びSNSサーバ50は、通信回線40に接続され、通信回線40を経由してデータの送受信を行う。
なお、通信回線40の種別に制限はなく、例えばインターネット回線、イントラネット回線、又は専用線等どのような回線の種別であってもよく、更に、有線、無線、又は有線と無線との混在の何れの接続形態であってもよい。
SNSサーバ50は、SNSに登録するユーザのユーザプロフィール情報、及びSNSに登録するユーザが発信したSNSデータを保管する端末である。なお、一例として、SNSサーバ50は提供機関とは異なる機関によって管理運営が行われているものとするが、提供機関が管理運営を行ってもよい。
位置推定装置10は、ユーザ位置推定情報生成部20及び災害推定部30を含む。ユーザ位置推定情報生成部20は、SNSデータからユーザ毎に位置集計テーブルを生成すると共に、後ほど説明する位置推定テーブルを生成する。災害推定部30は、SNSデータのうち、災害に関連するSNSデータ(災害情報)を取得し、位置情報が含まれない災害情報の発信位置を位置推定テーブルから推定して、自治体毎に災害情報発信数を集計する。そして、災害推定部30は、例えば集計した災害情報発信数の変化量から災害が発生したと判定できる場合に、災害の発生位置を自治体単位で推定する。
位置推定テーブルを生成するため、ユーザ位置推定情報生成部20は、SNSデータ収集部21、抽出部22、集計部23、選択部24、及び算出部25の各機能部を含む。また、ユーザ位置推定情報生成部20は、各種データの管理領域であるランドマークDB(Database)26、位置情報集計DB27、及びユーザ位置推定DB28の各DBを含む。
SNSデータ収集部21は、SNSに登録するユーザ毎に、各々のユーザが過去に発信したSNSデータをSNSサーバ50から収集する。
抽出部22は、SNSデータ収集部21で収集されたSNSデータから位置情報及び発信時間情報を抽出し、SNSデータに発信位置及び発信時間を対応付ける。なお、抽出部22は、ランドマーク情報を用いてSNSデータに発信位置を対応付ける必要がある場合、ランドマークDB26に格納されるランドマークテーブルを参照してSNSデータに発信位置を対応付ける。
図2はランドマークテーブルの一例を示す図である。図2に示すように、ランドマークテーブル51は、ランドマーク情報と、ランドマーク情報が存在する自治体名と、を対応づけるテーブルである。例えば図2に示すランドマークテーブル51の例では、SNSデータの本文に「A駅」の語句が含まれる場合、抽出部22は、SNSデータの発信位置としてA市を対応付ける。
集計部23は、抽出部22でSNSデータ毎に対応付けられた発信位置及び発信時間から、1日の各時間帯における自治体毎のSNSデータの発信数を集計し、ユーザ毎に位置集計テーブルを生成する。
図3は特定ユーザにおける位置集計テーブルの一例を示す図である。位置集計テーブル52は、特定ユーザが例えば時間帯1において、A市でa1件、B町でb1件、C村でc1件、D町でd1件、E市でe1件、及びF村でf1件のSNSデータを発信したことを示している。同様に、位置集計テーブル52は、特定ユーザが時間帯2以降の各時間帯に発信した、自治体毎のSNSデータの発信数を示している。なお、時間帯幅の設定方法に制限はなく、例えば各時間帯を1時間幅に設定する等、時間帯幅をどのように設定してもよい。なお、集計部23は、ユーザ毎に生成した位置集計テーブル52を位置情報集計DB27に格納する。
選択部24は、位置情報集計DB27から集計部23で生成したユーザ毎の位置集計テーブル52を取得する。そして、選択部24は、各ユーザの位置集計テーブル52の時間帯毎に、位置集計テーブル52に含まれる複数の自治体から、他の自治体に比べてSNSデータの発信数に有意差が現れる自治体の組み合わせ(自治体セット)を選択する。
算出部25は、選択部24が選択した自治体セットに基づいて、選択した自治体セット内における各自治体のSNSデータの発信比率を算出する。そして、算出部25は、ユーザ毎に、選択した自治体セットと、当該自治体セットが選択された時間帯と、選択した自治体セット内における各自治体のSNSデータの発信比率と、を対応づけた位置推定テーブルを生成し、ユーザ位置推定DB28に格納する。
図4は、特定ユーザにおける位置推定テーブルの一例を示す図である。例えば図4に示す位置推定テーブル54の例では、図3に示した位置集計テーブル52の時間帯1でSNSデータが発信された自治体のうち、A市、B町、及びC村が時間帯1における自治体セットとして選択されたことを示している。また、位置推定テーブル54の例では、時間帯1におけるA市、B町、及びC村のSNSデータの発信総数に対するA市の発信比率がra1、B町の発信比率がrb1、及びC村の発信比率がrc1であることを示している。同様に、位置推定テーブル54は、時間帯2以降の各時間帯における自治体セットと、自治体セット内における各自治体のSNSデータの発信比率と、を示している。
一方、災害の発生位置を推定するため、災害推定部30は、災害情報収集部31、ユーザ位置推定部32、判定部33、及び災害位置推定部34の各機能部を含む。また、災害推定部30は、災害語句DB35及び災害情報集計DB36の各DBを含む。
災害情報収集部31は、SNSデータのうち災害に関連するSNSデータである災害情報と災害情報を発信したユーザ情報を収集する。災害情報の本文には、災害に関連する語句が含まれる傾向があるため、災害情報収集部31は、災害に関連する語句と、災害の種類と、が対応付けられたテーブルが格納された災害語句DB35を参照して、SNSサーバ50から災害情報を収集する。更に、災害情報収集部31は、収集した災害情報に、災害情報を発信したユーザ情報と、災害情報がSNSサーバ50に発信された発信時間と、災害情報で通知される災害の種類と、を対応づける。
ユーザ位置推定部32は、災害情報収集部31で収集した災害情報に含まれるGPS情報、ランドマーク情報、又はユーザ位置推定DB28に格納される位置推定テーブル54を用いて、災害情報の発信位置を推定する。そして、ユーザ位置推定部32は、例えば災害の種別毎に、推定した災害情報の発信位置に対応する自治体毎の災害情報発信数を集計し、集計結果を災害情報集計DB36に格納する。
判定部33は災害情報集計DB36から、ユーザ位置推定部32が集計した、各々の災害の種別に対応した災害情報発信数の集計結果を取得する。そして、判定部33は、集計結果に対して公知のバースト検知手法を適用し、災害情報発信数の変化から、災害の種別に対応した災害が発生しているか否かを判定する。
ここで、バースト検知手法とは、時系列データに対する異常検知の手法の1つで、イベント(この場合、災害情報の発信)の集中的な発生を検知する手法をいう。公知のバースト検知手法として、例えば“Proceedings of the 8th ACM SIGKDD International Conference on Knowledge Discovery and Data Mining, 2002.”に記載されるJon Kleinbergが示した“Bursty and Hierarchical Structure in Streams ”(非特許文献)のバースト検知アルゴリズム等が利用できるが、Jon Kleinbergのバースト検知アルゴリズムと異なる他のバースト検知手法を用いてもよい。
災害位置推定部34は、判定部33で災害が発生していると判定した場合、災害情報集計DB36から災害が発生していると判定された集計結果を取得し、取得した集計結果から災害が発生している自治体を推定する。
次に、図5に、位置推定装置10をコンピュータで実現する場合の構成図を示す。
コンピュータ100は、CPU102、メモリ104、及び不揮発性の記憶部106を含む。CPU102、メモリ104、及び不揮発性の記憶部106は、バス108を介して互いに接続される。また、コンピュータ100は、他の装置とコンピュータ100とを接続し、互いにデータを送受信するためのI/O(Input/Output)110を備え、I/O110はバス108に接続される。また、I/O110には、例えば入力装置112、出力装置114、及び通信装置116が接続される。
入力装置112は、例えばキーボード及びマウス等のユーザがコンピュータ100に指示を与えるためのデバイスを含む。また、入力装置112は、例えばCD−ROM及びフラッシュメモリ等の記録媒体118に記録されるデータを読み取るための読み取り装置を含む。出力装置114は、例えばコンピュータ100での処理結果を表示する表示デバイス、及びコンピュータ100での処理結果を記憶する記憶装置等を含む。また、通信装置116は、通信回線40に接続するためのインターフェースを含み、通信回線40に接続されるSNSサーバ50等の他の情報端末とデータの送受信を行う。なお、記憶部106はHDD(Hard Disk Drive)又はフラッシュメモリ等によって実現できる。
記憶部106には、コンピュータ100を図1に示す位置推定装置10として機能させるための位置推定プログラム120が記憶される。記憶部106に記憶される位置推定プログラム120は、例えばSNSデータ収集プロセス122、抽出プロセス124、集計プロセス126、選択プロセス128、及び算出プロセス130を含む。また、位置推定プログラム120は、例えば災害情報収集プロセス132、ユーザ位置推定プロセス134、判定プロセス136、及び災害位置推定プロセス138を含む。
CPU102は、位置推定プログラム120を記憶部106から読み出してメモリ104に展開し、位置推定プログラム120が有する各プロセスを実行する。
CPU102が、位置推定プログラム120を記憶部106から読み出してメモリ104に展開し、位置推定プログラム120を実行することで、コンピュータ100が図1に示す位置推定装置10として動作する。また、CPU102がSNSデータ収集プロセス122を実行することで、コンピュータ100が図1に示すSNSデータ収集部21として動作する。また、CPU102が抽出プロセス124を実行することで、コンピュータ100が図1に示す抽出部22として動作する。また、CPU102が集計プロセス126を実行することで、コンピュータ100が図1に示す集計部23として動作する。また、CPU102が選択プロセス128を実行することで、コンピュータ100が図1に示す選択部24として動作する。また、CPU102が算出プロセス130を実行することで、コンピュータ100が図1に示す算出部25として動作する。また、CPU102が災害情報収集プロセス132を実行することで、コンピュータ100が図1に示す災害情報収集部31として動作する。また、CPU102がユーザ位置推定プロセス134を実行することで、コンピュータ100が図1に示すユーザ位置推定部32として動作する。また、CPU102が判定プロセス136を実行することで、コンピュータ100が図1に示す判定部33として動作する。また、CPU102が災害位置推定プロセス138を実行することで、コンピュータ100が図1に示す災害位置推定部34として動作する。
また、CPU102が、ランドマーク情報格納領域140に格納された、ランドマークテーブル51を生成する情報をメモリ104に展開することで、メモリ104にランドマークDB26が生成される。また、CPU102が、位置集計情報格納領域142に格納された、位置集計テーブル52を生成する情報をメモリ104に展開することで、メモリ104に位置情報集計DB27が生成される。また、CPU102が、ユーザ位置推定情報格納領域144に格納された、位置推定テーブル54を生成する情報をメモリ104に展開することで、メモリ104にユーザ位置推定DB28が生成される。また、CPU102が、災害語句情報格納領域146に格納された、災害に関連する語句と、災害の種類と、を対応付けた情報をメモリ104に展開することで、メモリ104に災害語句DB35が生成される。また、CPU102が、災害集計情報格納領域148に格納された、災害の種別毎の各自治体における災害情報発信数の情報をメモリ104に展開することで、メモリ104に災害情報集計DB36が生成される。更に、CPU102が、定数格納領域150に格納された各種定数をメモリ104に展開することで、メモリ104に位置推定プログラム120で使用する閾値等の予め定めた値が記憶される。
なお、コンピュータ100は、例えば半導体集積回路、より詳しくはASIC(Application Specific Integrated Circuit)等で実現することも可能である。
次に、本実施形態に係る位置推定装置10の作用について説明する。本実施形態に係る位置推定装置10は、例えば位置推定装置10の利用者が、入力装置112を用いて位置推定装置10に位置推定テーブル54の生成を指示するタイミングで、ユーザ位置推定処理を実行する。
図6は、本実施形態に係る位置推定装置10によるユーザ位置推定処理の流れの一例を示すフローチャートである。
まず、ステップS10において、SNSデータ収集部21は、SNSサーバ50から特定ユーザがこれまでに発信したM件(Mは正の整数)分のSNSデータを取得し、取得したM件分のSNSデータをメモリ104の予め定めた領域に記憶する。
SNSデータの収集には、例えばSNSサーバ50を管理運営する機関から提供されるAPI(Application Programming Interface)を利用することができる。
次に、ステップS20において、抽出部22及び集計部23は、位置集計テーブル生成処理を実行して特定ユーザのSNSデータを収集し、図3に示した特定ユーザの位置集計テーブル52を生成する。
そして、ステップS30において、選択部24及び算出部25は、位置推定テーブル生成処理を実行して、ステップS20の処理で生成した位置集計テーブル52から、図4に示した特定ユーザの位置推定テーブル54を生成する。
更に、ステップS40において、SNSデータ収集部21は、例えば予め収集したユーザリストを参照して、まだSNSデータを取得していないユーザが存在するか否かを判定する。肯定判定の場合には、ステップS10に移行してステップS10〜ステップS40の処理を繰り返し、ユーザ位置推定情報生成部20は、まだSNSデータを取得していないユーザの位置推定テーブル54を生成する。一方、否定判定の場合には、ユーザ位置推定処理を終了する。
次に、ステップS20及びステップS30の各処理について詳細に説明する。
図7は、ステップS20における位置集計テーブル生成処理の流れの一例を示すフローチャートである。
ステップS100において、抽出部22は、ステップS10の処理で収集したSNSデータの中からSNSデータを1件取得する。
ステップS105において、抽出部22は、ステップS100の処理で取得したSNSデータにGPS情報が付加されているか否かを判定する。肯定判定の場合はステップS120に移行し、ステップS120において、抽出部22は、SNSデータからGPS情報を抽出し、GPS情報に含まれる緯度及び経度からSNSデータが発信された自治体を特定して、SNSデータに特定した自治体名を対応付ける。また、抽出部22は、SNSデータからSNSデータの発信時間情報を抽出し、SNSデータに、抽出した発信時間を対応付ける。
一方、ステップS105の判定処理において否定判定の場合には、ステップS110に移行する。
ステップS110において、抽出部22は、ランドマークDB26に格納される図2に示したランドマークテーブル51を参照し、取得したSNSデータの本文に、ランドマークテーブル51に登録されているランドマーク情報が含まれるか否かを判定する。否定判定の場合には、取得したSNSデータから位置情報を抽出する処理を中止してステップS130に移行する。一方、肯定判定の場合にはステップS115に移行する。
ステップS115において、抽出部22は、取得したSNSデータの本文に含まれるランドマーク情報に基づいてSNSデータが発信された自治体を推定し、SNSデータに、SNSデータが発信された自治体名を対応付ける。具体的には、抽出部22は、ランドマークテーブル51からSNSデータに含まれるランドマーク情報に対応した自治体名を取得する。そして、抽出部22は、取得した自治体名をSNSデータが発信された自治体としてSNSデータに対応付ける。また、抽出部22は、SNSデータからSNSデータの発信時間情報を抽出し、SNSデータに抽出した発信時間を対応付ける。
ステップS125において、集計部23は、ステップS115又はステップS120の処理でSNSデータに対応付けられた自治体名及び発信時間から、位置情報集計DB27に格納される位置集計テーブル52の値を更新する。具体的には、集計部23は、位置集計テーブル52で、SNSデータに対応付けられた自治体における、SNSデータに対応付けられた発信時間が含まれる時間帯のSNSデータの発信数を1つ増加する。
なお、集計部23は、位置集計テーブル52の自治体名に、SNSデータに対応付けられた自治体名が含まれない場合、位置集計テーブル52に、SNSデータに対応付けられた自治体名を有する列データを新たに追加する。この場合、集計部23は、追加する列データの各時間帯におけるSNSデータの発信数を0に設定する。そして、集計部23は、位置集計テーブル52で、SNSデータに対応付けられた自治体における、SNSデータに対応付けられた発信時間が含まれる時間帯のSNSデータの発信数を1つ増加する。
ステップS130において、抽出部22は、図6のステップS10の処理で収集したSNSデータのうち、ステップS100の処理でまだ取得していないSNSデータがあるか否かを判定する。
肯定判定の場合にはステップS100に移行して、未取得のSNSデータの各々に対してステップS100〜ステップS130の処理を繰り返すことで、位置推定装置10は、最大M件のSNSデータに基づいた特定ユーザの位置集計テーブル52を生成する。
一方、ステップS130の判定処理で否定判定となった場合には、位置集計テーブル生成処理を終了する。
なお、図7に示した位置集計テーブル生成処理の例では、SNSデータから位置情報を取得するため、GPS情報又はランドマーク情報を利用した。しかし、SNSデータに何れの情報も含まれない場合には、ユーザ位置推定情報生成部20は、SNSデータを発信したユーザのユーザプロフィール情報を取得して、SNSデータから位置情報を取得するようにしてもよい。具体的には、ユーザ位置推定情報生成部20は、APIを用いてSNSサーバ50からSNSデータを発信したユーザのユーザプロフィール情報を取得する。そして、ユーザ位置推定情報生成部20は、ユーザプロフィール情報に含まれるユーザの居住地域が自治体名で登録されている場合には、当該自治体を対応するSNSデータが発信された自治体とみなして、位置集計テーブル52の値を更新する。
次に、図8は、図6に示したステップS30における位置推定テーブル生成処理の流れの一例を示すフローチャートである。なお、位置推定テーブル生成処理の開始前に、位置推定テーブル生成処理で使用する各種変数i、k、及びnの値は、i=1、k=1、及びn=2に初期化されるものとする。
まず、ステップS200において、選択部24は、位置集計テーブル生成処理で生成された特定ユーザの位置集計テーブル52から、時間帯iにおける行データを取得する。
なお、図9は、ステップS200の処理で取得する、時間帯iの行データの一例を示す図である。
ステップS205において、選択部24は、ステップS200の処理で取得した行データから、自治体kのSNSデータ発信数を取得する。
次に、ステップS210において、選択部24は、ステップS205の処理で取得した時間帯iでの自治体kのSNSデータ発信数と、時間帯iでの自治体k以外の他の自治体のSNSデータ発信数の各々と、を比較する。そして、選択部24は、例えばカイ2乗検定等の、比較したい事象に対する発生頻度の偏りを判定する統計的な検定手法を用いて、自治体kのSNSデータ発信数に、他の自治体のSNSデータ発信数に対する有意差が認められるか否かを判定する。
例えば、図3に示した位置集計テーブル52でi=k=1の場合、時間帯1における自治体k、即ちA市のSNSデータ発信数であるa1が、時間帯1における他の自治体のSNSデータ発信数の各々に対して有意差が認められる程度に多いか否かを判定する。仮に、肯定判定の場合には、参照している位置集計テーブル52に対応する特定ユーザは、時間帯1においてA市にいると推定できる。しかし、否定判定の場合には、参照している位置集計テーブル52に対応する特定ユーザは、時間帯1においてA市にいると推定することは統計的に困難である。
従って、ステップS210の判定処理で肯定判定となった場合には、ステップS250に移行し、時間帯iにおいて特定ユーザが存在すると推定される自治体を位置推定テーブル54に登録する。
一方、ステップS210の判定処理で否定判定となった場合には、引き続き特定ユーザが何れの自治体にいるか推定するためステップS215に移行する。
ステップS215において、選択部24は変数kを1つ増加して、SNSデータ発信数に関して有意差を判定する対象を別の自治体に変更する。
そして、ステップS220において、選択部24は、ステップS200の処理で取得した時間帯iの行データに、他の自治体のSNSデータ発信数が含まれるか否かを判定する。肯定判定の場合にはステップS205に移行し、ステップS205〜ステップS220の処理を繰り返すことで、選択部24は、時間帯iの行データから、SNSデータの発信数に有意差が認められる自治体を選択する。
一方、ステップS220の判定処理で否定判定となる場合には、時間帯iにおいて、特定の単一自治体のSNSデータ発信数と、他の自治体のSNSデータ発信数と、の間には有意差がないことを表している。従って、選択部24は、他の自治体のSNSデータ発信数に対して有意差が現れるような自治体の組み合わせを選択する。
そのため、ステップS225では、選択部24は、ステップS200の処理で取得した時間帯iの行データの各要素に対応する複数の自治体をn個選択する組み合わせの中から、未選択の組み合わせを1つ選択する。なお、以降では、選択したn個の自治体の組み合わせを、「要素数nの自治体セット」という。
ステップS230において、選択部24は、時間帯iの行データから、ステップS225の処理で選択した各々の自治体のSNSデータ発信数を取得し、取得したSNSデータ発信数の合計を自治体セットのSNSデータ発信数とする。
図10は、例えばA市及びB町を自治体セットとして選択し、A市及びB町の各々のSNSデータ発信数を自治体セットのSNSデータ発信数とした場合の、時間帯iにおけるSNSデータ発信数を示す図である。この場合、図10に示すように、自治体セットに含まれるA市及びB町を1つの自治体と捉えることができる。
更に、選択部24は、自治体セットのSNSデータ発信数と、時間帯iの行データに含まれる自治体セット以外の他の自治体のSNSデータ発信数の各々と、を比較する。そして、選択部24は、自治体セットのSNSデータ発信数に、他の自治体のSNSデータ発信数に対する有意差が認められるか否かを判定する。
肯定判定の場合、即ち、参照している位置集計テーブル52に対応する特定ユーザが、時間帯iにおいて自治体セットに含まれる自治体にいると推定できる場合には、ステップS250に移行する。
ステップS250の処理は、ステップS210の判定処理で肯定判定となった場合、及び、ステップS230の判定処理で肯定判定となった場合に実行される。即ちステップS250の処理は、時間帯iにおいて、参照している位置集計テーブル52に対応する特定ユーザの位置が推定できた場合に実行される処理である。
ステップS250において、算出部25は、他の自治体のSNSデータ発信数に対して有意差が認められる自治体又は自治体セットに対して、時間帯iにおける各自治体のSNSデータの発信比率を算出する。
図11は、例えば位置集計テーブル52の時間帯1において、A市、B町、及びC村が自治体セットとして選択された状況を示す図である。
この場合、選択された自治体セットにおけるA市の発信比率をra1、B町の発信比率をrb1、C村の発信比率をrc1とすれば、算出部25は発信比率ra1、発信比率rb1、及び発信比率rc1を、それぞれ(1)式〜(3)式に従って算出する。
(数1)
ra1=a1/(a1+b1+c1)・・・(1)
rb1=b1/(a1+b1+c1)・・・(2)
rc1=c1/(a1+b1+c1)・・・(3)
そして、算出部25は、時間帯1において、発信比率ra1、発信比率rb1、及び発信比率rc1を、各自治体と対応づけて図4に示す位置推定テーブル54を生成する。
即ち、位置推定テーブル54に対応する特定ユーザは、時間帯1において、発信比率ra1の割合でA市に存在し、発信比率rb1の割合でB町に存在し、発信比率rc1の割合でC村に存在することがわかる。
なお、ステップS210の判定処理で肯定判定となった場合、他の自治体のSNSデータ発信数に対して有意差が認められる自治体は1つとなる。この場合は要素数1の自治体セットとみなすことができるため、算出部25は、発信比率を1に設定して自治体と対応付け、位置推定テーブル54を生成する。
一方、ステップS230の判定処理が否定判定の場合には、参照している位置集計テーブル52に対応する特定ユーザが、時間帯iにおいて自治体セットに含まれる自治体にいると推定することは統計的に困難である。
従って、否定判定の場合にはステップS235に移行し、ステップS235において、選択部24は、ステップS200の処理で取得した時間帯iの行データにおいて、未選択の要素数nの自治体セットがあるか否かを判定する。そして、肯定判定の場合には、ステップS225に移行して、ステップS225〜ステップS235の処理を繰り返すことで、選択部24は、時間帯iの行データから、SNSデータの発信数に有意差が認められる要素数nの自治体セットを選択する。
一方、ステップS235の判定処理が否定判定の場合、要素数nの自治体セットのSNSデータ発信数と、要素数nの自治体セット以外の他の自治体のSNSデータ発信数と、の間には有意差がないことを表している。
従って、ステップS235の判定処理が否定判定の場合には、ステップS240に移行し、自治体セットに含まれる自治体数を増加することで自治体セットのSNSデータ発信数に有意差が現れるか判定する。
そこで、ステップS240において、選択部24は変数nを1つ増加する。そして、ステップS245において、選択部24は、変数nが閾値N以下か否かを判定する。ここで、閾値Nは自治体の最大組み合わせ数を定義した値であり、例えば閾値Nは、図3に示した位置集計テーブル52の時間帯iの行データに含まれる自治体数未満に設定される。
ステップS245の判定処理が肯定判定の場合には、ステップS225に移行する。そして、ステップS225〜ステップS245の処理を繰り返すことで、選択部24は、要素数nを1つずつ増加させながら、時間帯iの行データからSNSデータの発信数に有意差が認められる要素数nの自治体セットを選択する。
一方、ステップS245の判定処理が否定判定の場合には、参照している位置集計テーブル52に対応する特定ユーザが、時間帯iにどの自治体にいるか推定できないことを意味する。この場合、ステップS255に移行する。
ステップS255において、選択部24は変数iを1つ増加して、次の時間帯の行データから要素数nの自治体を選択する準備を行う。
そして、ステップS260において、選択部24は、ステップS200の処理で参照した、特定ユーザの位置集計テーブル52に、ステップS255の処理で更新した時間帯iの行データが存在するか否かを判定する。肯定判定の場合にはステップS200に移行し、選択部24は、更新した時間帯iにおける特定ユーザの位置を推定し、否定判定の場合には位置推定テーブル生成処理を終了する。
上記に説明した位置推定テーブル生成処理により、図6のステップS10の処理でSNSデータを収集した特定ユーザに対する位置推定テーブル54が生成できる。
なお、ステップS225の処理では、時間帯iにおける行データの各要素に対応する複数の自治体から、要素数nの自治体セットを選択した。しかし、通常、ユーザは各自治体を連続的に移動する。
図12は、各自治体の形状を矩形状に単純化して配置した地図である。地図56には、一例としてA市、B町、C村、D町、E市、及びF村が記載されている。
例えばユーザがA市にいる場合、ユーザはA市から隣接する自治体を経由して各自治体に移動する。従って、要素数n(この場合、nは2以上)の自治体セットが複数選択できる場合、選択部24は、地理的に隣接する自治体を選択する方が、ユーザの移動形態に近い自治体の選択となり好ましい。
例えば、要素数2の自治体セットとして、隣接する自治体であるA市及びB町の自治体セットと、隣接していない自治体であるA市及びC村の自治体セットと、があるとする。この際、A市及びB町の自治体セットに対してSNSデータ発信数の有意差を判定する方が、A市及びC村の自治体セットからSNSデータ発信数の有意差を判定する場合より、効率よくユーザの位置を推定できる場合がある。
なお、選択した自治体セットに含まれる自治体が隣接しているか否かの判定は、例えば選択部24が要素数nの自治体セットを選択する際、隣接自治体テーブルを参照することで可能となる。
図13は、隣接自治体テーブルの一例を示す図である。隣接自治体テーブル58は、自治体と、当該自治体に隣接する自治体と、を対応付けるテーブルである。図13に示す隣接自治体テーブル58の例によれば、A市はB町、E市、及びF村に隣接していることを示している。なお、隣接自治体テーブル58は、メモリ104の予め定めた領域に予め記憶しておけばよい。
また、図14に示すように、時間帯iにおいてA市でのSNSデータ発信数aiと、D町でのSNSデータ発信数diと、を足し合わせると、他の自治体のSNSデータ発信数に対して有意差が認められる状況になるとする。この場合、A市とD町とは隣接していないが、選択部24は、A市及びD町にそれぞれ隣接するF村を含めて、A市、D町、及びF村のように連続的に隣接する自治体を組み合わせた自治体セットを選択してもよい。なお、既にA市及びD町でのSNSデータ発信数の合計(ai+di)で、他の自治体のSNSデータ発信数に対して有意差が認められるため、時間帯iでのF村のSNSデータ発信数は“0”であってもよい。
このように、選択部24は、時間帯iにおいてSNSデータ発信数が“0”の自治体であっても、連続的に隣接する自治体を組み合わせた自治体セットを生成するため、要素数n(nは3以上)の自治体セットに含めることができる。この場合、時間帯iにおいてSNSデータ発信数が“0”の自治体は、位置集計テーブル52に含まれない自治体であってもよいことは言うまでもない。
更に、選択部24は、自治体セットに含まれる各自治体の面積の合計がより小さくなるように、自治体セットを選択する方が好ましい。なぜなら、自治体セットに含まれる各自治体の面積の合計が小さくなるに従ってユーザの位置が絞られ、ユーザの位置を精度よく推定することができるためである。なお、各自治体の面積情報は、メモリ104の予め定めた領域に予め記憶しておけばよい。
例えば、図14に示す例において、A市及びD町にそれぞれ隣接するF村及びE市のSNSデータ発信数は共に“0”であるが、F村の面積がE市の面積より小さいとすれば、選択部24はA市、D町、及びF村のように自治体セットを選択する方が好ましい。
しかし、例えば、図15に示すように、A市、E市、及びD町を通る路線又は幹線道路等の移動ルート60は存在するが、A市、F村、及びD町を通る移動ルートは存在しない場合には、選択部24はA市、D町、及びE市のように自治体セットを選択してもよい。なぜなら、ユーザは、車両又は鉄道等の交通機関を使い、移動ルート60に沿って移動する傾向がある。従って、図15の例では、ユーザは時間帯iにおいてA市、D町、及びF村の自治体セットより、A市、D町、及びE市の自治体セットにいる確率が高いため、選択部24は、A市、D町、及びE市の自治体セットを選択した方が精度よくユーザの位置を推定できる。
なお、自治体間にどのような移動ルート60が存在するかは、選択部24が移動ルートテーブルを参照することで可能となる。
図16は、移動ルートテーブルの一例を示す図である。移動ルートテーブル62は、鉄道及び道路等の交通インフラと、交通インフラが通過する自治体と、を対応付けるテーブルである。例えば移動ルートテーブル62の例によれば、国道W号線は、A市、B町及びC村を通過することを示している。なお、移動ルートテーブル62は、メモリ104の予め定めた領域に予め記憶しておけばよい。
また、算出部25は、図8のステップS250の処理で算出した位置推定テーブル54の内容を更に修正するようにしてもよい。
図17は、例えばユーザCの位置推定テーブル54の一例を示す図である。なお、図17に示す位置推定テーブル54において、記号“−”はデータが存在しないことを表している。
例えば図17に示す位置推定テーブル54は、時間帯2においてユーザCがC村にいる場合があることを示している。一方、図17に示す位置推定テーブル54は、時間帯2より早い時間帯である時間帯1では、ユーザCはA市又はE町にいることを示している。例えば時間帯1が7時以上8時未満の時間帯を表し、時間帯2が8時以上9時未満の時間帯を表す場合、ユーザCはA市又はE町からC村に2時間以内で移動することになる。しかし、如何なる方法を使っても、ユーザCが2時間以内でA市又はE町からC村に移動できないことが明確である場合、算出部25は、時間帯2における自治体セットからC村を削除する。具体的には、算出部25は、時間帯2におけるC村の発信比率rc2を“0”する。更に、算出部25は、ユーザCが2時間以内でA市からE町に移動できると判定できれば、時間帯2においてユーザCがいると推定できる自治体がE町だけとなるため、E町の発信比率re2を“1”にする。
なお、例えば時間帯2でC村、E町、及びF村の自治体セットが選択され、且つ、C村への移動が不可能である場合、C村の発信比率rc2を“0”にすると共に、発信比率rc2を、E町及びF村の発信比率の割合に応じてE町及びF村に比例配分すればよい。
このように、位置推定装置10は、位置推定テーブル54の隣接する時間帯毎に選択された自治体セットの中に、隣接する時間帯で表される期間では移動が不可能な自治体が含まれる場合、自治体セットから移動が不可能と考えられる自治体を削除する。
なお、隣接する時間帯で表される期間とは、隣接する時間帯を1つの時間帯にまとめた場合の開始時間から終了時間までの期間をいう。例えば時間帯1及び時間帯2の例で言えば、時間帯1の開始期間から時間帯2の終了時間までの期間をいう。
更に、図17に示す位置推定テーブル54の例では、時間帯4においてSNSデータの発信数に有意差が認められる自治体セットが選択できなかったため、何れの自治体の発信比率も登録されていない。従って、位置推定装置10は、ユーザCが時間帯4に何れの自治体にいるか推定することができない。
従って、算出部25は、SNSデータの発信数に有意差が認められる自治体セットが選択できなかった時間帯(推定不能時間帯)に隣接する時間帯の自治体の発信比率から、推定不能時間帯でSNSデータを発信したと考えられる自治体の発信比率を算出する。
具体的には、推定不能時間帯に隣接する時間帯の自治体の発信比率を経過時間に応じて比例配分することで、推定不能時間帯における自治体の発信比率を算出する。
例えば図17に示す位置推定テーブル54の例において、時間帯iにおける時刻をtiとすれば、時間帯4における各自治体の発信比率rα4”は(4)式〜(6)式を用いて(7)式のように表される。
(数2)
ra4’=ra3+(ra5−ra3)/(t5−t3)*(t4−t3) ・・・(4)
rd4’=rd3−rd3/(t5−t3)*(t4−t3) ・・・(5)
rc4’=rc5/(t5−t3)*(t4−t3) ・・・(6)
rα4”=rα4’/(ra4+rd4−rc4)・・・(7)
ここで、α=a、b、及びcであり、時間帯iにおける時刻とは、例えば時間帯iの中央の時刻である。具体的には、時間帯3が9時以上10時未満を示す時間帯であれば、時刻t3は9時30分となる。
図18は、図17に示す位置推定テーブル54の例に対して、上記で説明した時間帯2及び時間帯4に対する修正を実行した後の位置推定テーブル54の例を示す図である。図18に示すように、位置推定テーブル54の時間帯2における自治体からC村が削除されてE町だけとなり、また、時間帯4に、時間帯3及び時間帯5の自治体の発信比率から推定した自治体の発信比率が追加される。
従って、位置推定装置10は、自治体間の移動に要する時間と、隣接する時間帯で表される期間と、の関係に基づいて、一度生成した位置推定テーブル54を修正しない場合に比べて、精度よくユーザの位置を推定することができる。また、位置推定装置10は、推定不能時間帯における自治体の発信比率を不明のままとする場合に比べて、精度よくユーザの位置を推定することができる。
次に、図8に示した位置推定テーブル生成処理で生成された位置推定テーブル54を利用して、何れの自治体から発信されたか不明のSNSデータの発信位置を推定し、例えば災害の発生位置を推定する災害発生位置推定処理について説明する。
図19は、災害発生位置推定処理の流れの一例を示すフローチャートである。
ステップS300において、災害情報収集部31はAPIを利用して、SNSサーバ50にSNSデータが存在するか否かを判定する。否定判定の場合、災害情報収集部31は、SNSに登録するユーザからSNSサーバ50にSNSデータが発信されるまで、ステップS300の処理を繰り返し実行する。一方、肯定判定の場合にはステップS305に移行する。
ステップS305において、災害情報収集部31はAPIを利用して、SNSサーバ50から未取得のSNSデータを1件収集する。なお、この際収集するSNSデータは、何れのユーザのSNSデータであってもよい。
次に、ステップS310において、災害情報収集部31は、メモリ104に記憶される災害語句DB35から災害語句テーブルを取得する。
図20は、災害語句テーブル66の一例を示す図である。図20に示すように、災害語句テーブル66は、“氾濫”、“土砂崩れ”、“竜巻”等の災害の発生を連想させる語句と、各々の語句に対応する災害の種別と、を対応付けるテーブルである。
ステップS310において、災害情報収集部31は、ステップS305の処理で収集したSNSデータが、災害語句テーブル66に登録された何れかの災害語句を含む災害情報であるか否かを判定する。否定判定の場合には、ステップS305の処理で収集したSNSデータは災害情報ではないため、ステップS300に移行して新たなSNSデータを収集する。
一方、ステップS310の判定処理で肯定判定の場合には、災害情報収集部31は、災害語句テーブル66から、SNSデータに含まれる災害語句に対応する災害の種類を取得し、ステップS305の処理で収集した災害情報と対応づける。更に、災害情報収集部31は、災害情報を発信したユーザ情報、及び災害情報の発信時間を、ステップS305の処理で収集した災害情報と対応付け、メモリ104の予め定めた領域に記憶する。
ステップS315において、ユーザ位置推定部32は、ステップS305の処理で収集した災害情報にGPS情報が付加されているか否かを判定する。肯定判定の場合には、GPS情報に含まれる緯度及び経度から災害情報の発信位置を自治体単位で推定することができるため、ステップS325に移行する。一方、否定判定の場合には、現時点において災害情報の発信位置が不明であるため、ステップS320に移行する。
ステップS320において、ユーザ位置推定部32は、ランドマークDB26に格納される図2に示したランドマークテーブル51を参照し、取得した災害情報の本文に、ランドマークテーブル51に登録されているランドマーク情報が含まれるか否かを判定する。肯定判定の場合には、災害情報の本文に含まれるランドマーク情報から災害情報の発信位置を自治体単位で推定することができるため、ステップS325に移行する。
ステップS325において、ユーザ位置推定部32は、災害情報集計DB36に格納される災害検知テーブルを用いて、災害の種別の各々に対して、自治体毎に災害情報の発信数を集計する。
図21は、特定の災害の種別における災害検知テーブルの一例を示す図である。災害検知テーブル68は、自治体と、自治体における災害情報の発信数と、を対応付けるテーブルである。例えばA市の災害情報の発信数がSAであり、ステップS305の処理で収集した災害情報がA市から発信されたものと推定される場合、ユーザ位置推定部32は、災害検知テーブル68のA市の災害情報の発信数を(SA+1)にする。
一方、ステップS320の判定処理が否定判定の場合には、現時点において災害情報の発信位置が不明であるため、ステップS330に移行する。
ステップS330において、ユーザ位置推定部32は、ユーザ位置推定DB28から、ステップS305の処理で収集した災害情報を発信したユーザに対応する位置推定テーブル54を取得する。そして、ユーザ位置推定部32は、取得した位置推定テーブル54の時間帯のうち、災害情報に対応付けられた発信時間を含む時間帯に含まれる自治体名及び自治体の発信比率を取得する。
ステップS335において、ユーザ位置推定部32は、災害情報で表される災害の種別に対応した災害検知テーブル68の自治体の発信数に、ステップS330の処理で取得した自治体毎の発信比率を加算する。
図22は、自治体の発信数に発信比率を加算した場合の災害検知テーブル68を示す図である。
例えば、時間帯iにおけるA市の発信比率がrai、B町の発信比率がrbi、及びC村の発信比率がrciであり、発信比率を加算する前のA市の災害情報の発信数が(SA+1)、B町の災害情報の発信数がSB、及びC村の災害情報の発信数がSCであるとする。この場合、図22に示すように、A市の災害情報の発信数は(SA+1+rai)、B町の災害情報の発信数は(SB+rbi)、C村の災害情報の発信数は(SC+rci)となる。
ステップS340において、判定部33は、ステップS325又はステップS335の処理で災害情報の発信数を更新した災害検知テーブル68に対して公知のバースト検知手法を適用する。そして、判定部33は、災害情報の発信数の変化から、災害検知テーブル68に対応する種別の災害が発生しているか否かを判定する。否定判定の場合にはステップS300に移行して、新たなSNSデータを収集する。一方、肯定判定の場合には、判定部33は、例えば災害が発生していることを示す識別子を更新した災害検知テーブル68に対応付け、ステップS345に移行する。
ステップS345において、災害位置推定部34は、災害情報集計DB36から、災害が発生していることを示す識別子が対応付けられた災害検知テーブル68を取得する。そして、災害位置推定部34は、取得した災害検知テーブル68を参照し、災害情報の発信数に対する自治体数の関係を示す発信頻度分布を生成する。
図23は、災害の発生が推定される災害検知テーブル68から生成した発信頻度分布の一例を示す図である。なお、図23に示す発信頻度分布70の縦軸は自治体数、横軸は災害情報の発信数を示す。通常、実際に災害が発生している自治体からの災害情報の発信数は、災害の発生していない自治体からの発信数に比べて多くなる。従って、災害位置推定部34は、例えば災害情報の発信数に関して上位10%に含まれる自治体で災害が発生していると推定する。なお、災害が発生している自治体を推定する際の閾値である“10%”の値は一例であり、他の閾値を用いてもよいことは言うまでもない。
災害位置推定部34は、災害が発生していると推定した自治体の名称等の情報を、例えば図5に示した出力装置114から位置推定装置10の外部に出力してもよい。
以上、図19に示す災害発生位置推定処理により、位置情報が含まれない災害情報であっても、図4に示した位置推定テーブル54を使用して、災害が発生している自治体を推定することができる。
従って、位置推定装置10は、位置情報が含まれる災害情報だけでは公知のバースト検知手法を適用するのにサンプル数が足りない場合であっても、位置推定テーブル54から発信位置を推定した災害情報を利用できるため、より短時間に災害の発生を推定できる。
また、位置推定装置10は、位置情報が含まれる災害情報だけで災害の発生位置を推定する場合に比べて、利用できる災害情報の数が多くなるため、精度よく災害の発生位置を推定できる。
なお、位置推定テーブル54を利用した位置推定サービスの利用範囲は防災関連に限定されない。例えば、位置推定テーブル54から特定の人物の時間帯毎の行動エリアが推定できるため、ユーザの推定位置周辺にある店の広告をユーザが所有するスマートフォン等の情報機器に送信する等、マーケティング分野に適用することができる。その他、位置推定テーブル54は、ユーザの位置を利用して何らかの処理を行う分野であれば、如何なる分野にも適用できることは言うまでもない。
また、図8に示した位置推定テーブル生成処理のステップS225では、選択部24は、他の自治体のSNSデータ発信数に対して有意差が認められるように、要素数nの自治体セットを選択した。しかし、選択部24は、他の自治体のSNSデータ発信数に対して有意差が認められるように、図3に示した位置集計テーブル52の複数の時間帯の中からm個(mは1以上)の時間帯の組み合わせを選択するようにしてもよい。この際、選択部24は、時間帯が連続し、且つ、できるだけ組み合わせる時間帯の数が少なくなるような時間帯の組み合わせを選択することが好ましい。
ここで時間帯が連続するとは、図3に示す位置集計テーブル52の場合、時間帯1、時間帯2、及び時間帯3のように、時間帯に切れ目がない状態をいう。時間帯1及び時間帯3と選択した場合、時間帯1と時間帯3の間に時間帯2による時間の切れ目が入るため、時間帯が連続していない。
また、選択部24は、できるだけ組み合わせる時間帯の数が少なくなるように、位置集計テーブル52から時間帯の組み合わせを選択することで、より短い期間毎にユーザの位置が推定された位置推定テーブル54を生成できる。従って、位置推定装置10は、ユーザの位置をより精度よく推定することができる。
また、選択部24は、他の自治体のSNSデータ発信数に対して有意差が認められるように、位置集計テーブル52の複数の自治体及び複数の時間帯の中から、n個の自治体及びm個の時間帯の組み合わせを選択するようにしてもよい。
この場合、選択部24は、位置集計テーブル52の複数の自治体の中からn個の自治体を選択する際に説明した好ましい選択方法、及び、複数の時間帯の中からm個の時間帯を選択する際に説明した好ましい選択方法を適用することができる。
以上、実施形態を用いて開示の技術を説明したが、開示の技術は各々の実施形態に記載の範囲には限定されない。開示の技術の要旨を逸脱しない範囲で各々の実施形態に多様な変更または改良を加えることができ、当該変更または改良を加えた形態も開示の技術の技術的範囲に含まれる。例えば、開示の技術の要旨を逸脱しない範囲で処理の順序を変更してもよい。
また、実施形態では、位置推定プログラム120が記憶部に予め記憶(インストール)されている態様を説明したが、これに限定されるものではない。開示の技術に係る位置推定プログラム120は、コンピュータ読取可能な記録媒体118に記録されている形態で提供することも可能である。例えば、開示の技術に係る位置推定プログラム120は、CD−ROM、DVD−ROM、及びUSBメモリ等の可搬型記録媒体に記録されている形態で提供することも可能である。また、開示の技術に係る位置推定プログラム120は、フラッシュメモリ等の半導体メモリ等に記録されている形態で提供することも可能である。
以上の実施形態に関し、更に以下の付記を開示する。
(付記1)
コンピュータに、
ソーシャルメディアに発信された情報に紐づけられたユーザ情報毎に、複数の基礎自治体における基礎自治体毎で、且つ、複数の時間帯における時間帯毎に情報発信数を集計し、
前記情報発信数に基づいて、前記ユーザ情報毎に、前記複数の基礎自治体から、他の基礎自治体に比べて前記情報発信数に有意差が現れる基礎自治体の組み合わせを前記時間帯毎に選択し、
前記選択した基礎自治体の組み合わせにおける基礎自治体毎の前記情報発信数から、前記ユーザ情報毎に、前記選択した基礎自治体の組み合わせにおける基礎自治体毎の前記情報の発信比率を前記時間帯毎に算出し、
前記ソーシャルメディアから新たに収集した情報に情報の発信位置を特定する位置情報が含まれない場合、前記新たに収集した情報に含まれる情報の発信時間、及び前記新たに収集した情報を発信したユーザ情報に対応する算出した発信比率に従って、前記新たに収集した情報を発信したユーザの位置を推定する
ことを含む処理を実行させる位置推定方法。
(付記2)
コンピュータに、
ソーシャルメディアに発信された情報に紐づけられたユーザ情報毎に、複数の基礎自治体における基礎自治体毎で、且つ、複数の時間帯における時間帯毎に情報発信数を集計し、
前記情報発信数に基づいて、前記ユーザ情報毎に、前記複数の時間帯から、前記複数の基礎自治体における各基礎自治体の何れかで、他の基礎自治体に比べて前記情報発信数に関する有意差が現れる時間帯の組み合わせを選択し、
前記ソーシャルメディアから新たに収集した情報に情報の発信位置を特定する位置情報が含まれない場合、前記新たに収集した情報に含まれる情報の発信時間、及び前記新たに収集した情報を発信したユーザ情報に対応する選択した時間帯の組み合わせに従って、前記新たに収集した情報を発信したユーザの位置を推定する
ことを含む処理を実行させる位置推定方法。
(付記3)
前記複数の基礎自治体及び前記複数の時間帯の項目のうち、一方の項目に関する組み合わせでは前記情報発信数に関する有意差が現れない場合、前記複数の基礎自治体における各基礎自治体及び前記複数の時間帯における各時間帯の組み合わせの中から、他の基礎自治体に比べて前記情報発信数に関する有意差が現れるような組み合わせを選択する
付記1又は付記2記載の位置推定方法。
(付記4)
前記複数の基礎自治体における各基礎自治体から、他の基礎自治体に比べて前記情報発信数に関する有意差が現れる基礎自治体の組み合わせを選択する場合、地理的に連続するような基礎自治体の組み合わせを選択する
付記1又は付記3記載の位置推定方法。
(付記5)
前記地理的に連続する基礎自治体の組み合わせのうち、面積が他の基礎自治体の組み合わせに比べて小さくなるような基礎自治体の組み合わせを選択する
付記4記載の位置推定方法。
(付記6)
前記地理的に連続する基礎自治体の組み合わせのうち、交通機関の沿線に位置する基礎自治体の組み合わせを選択する
付記4記載の位置推定方法。
(付記7)
前記複数の時間帯における隣接する時間帯のうち、より早い第1の時間帯での前記基礎自治体の組み合わせに含まれる特定の基礎自治体から、より遅い第2の時間帯での前記基礎自治体の組み合わせに含まれる前記特定の基礎自治体と異なる他の基礎自治体に移動するのに要する時間が、前記隣接する時間帯で表される期間より短い場合、前記第2の時間帯における前記基礎自治体の組み合わせから前記他の基礎自治体を削除し、前記第2の時間帯における前記情報の発信比率を再度算出する
付記4〜付記6の何れか1項に記載の位置推定方法。
(付記8)
前記情報発信数に関する有意差が認められない時間帯が存在する場合、前記情報発信数に関する有意差が認められない時間帯に隣接する時間帯における前記情報の発信比率から、前記情報発信数に関する有意差が認められない時間帯における前記情報の発信比率を算出する
付記3〜付記7の何れか1項に記載の位置推定方法。
(付記9)
前記複数の時間帯から、前記複数の基礎自治体における各基礎自治体の何れかで、他の基礎自治体に比べて前記情報発信数に関する有意差が現れる時間帯の組み合わせを選択する場合、時間的に連続するような時間帯の組み合わせで、且つ、期間が他の時間帯の組み合わせに比べて短くなるような時間帯の組み合わせを選択する
付記2又は付記3記載の位置推定方法。
(付記10)
コンピュータに、
ソーシャルメディアに発信された情報に紐づけられたユーザ情報毎に、複数の基礎自治体における基礎自治体毎で、且つ、複数の時間帯における時間帯毎に情報発信数を集計し、
前記情報発信数に基づいて、前記ユーザ情報毎に、前記複数の基礎自治体から、他の基礎自治体に比べて前記情報発信数に有意差が現れる基礎自治体の組み合わせを前記時間帯毎に選択し、
前記選択した基礎自治体の組み合わせにおける基礎自治体毎の前記情報発信数から、前記ユーザ情報毎に、前記選択した基礎自治体の組み合わせにおける基礎自治体毎の前記情報の発信比率を前記時間帯毎に算出し、
前記ソーシャルメディアから新たに収集した情報に情報の発信位置を特定する位置情報が含まれない場合、前記新たに収集した情報に含まれる情報の発信時間、及び前記新たに収集した情報を発信したユーザ情報に対応する算出した発信比率に従って、前記新たに収集した情報を発信したユーザの位置を推定する
ことを含む処理を実行させるための位置推定プログラム。
(付記11)
コンピュータに、
ソーシャルメディアに発信された情報に紐づけられたユーザ情報毎に、複数の基礎自治体における基礎自治体毎で、且つ、複数の時間帯における時間帯毎に情報発信数を集計し、
前記情報発信数に基づいて、前記ユーザ情報毎に、前記複数の時間帯から、前記複数の基礎自治体における各基礎自治体の何れかで、他の基礎自治体に比べて前記情報発信数に関する有意差が現れる時間帯の組み合わせを選択し、
前記ソーシャルメディアから新たに収集した情報に情報の発信位置を特定する位置情報が含まれない場合、前記新たに収集した情報に含まれる情報の発信時間、及び前記新たに収集した情報を発信したユーザ情報に対応する選択した時間帯の組み合わせに従って、前記新たに収集した情報を発信したユーザの位置を推定する
ことを含む処理を実行させるための位置推定プログラム。
(付記12)
前記複数の基礎自治体及び前記複数の時間帯の項目のうち、一方の項目に関する組み合わせでは前記情報発信数に関する有意差が現れない場合、前記複数の基礎自治体における各基礎自治体及び前記複数の時間帯における各時間帯の組み合わせの中から、他の基礎自治体に比べて前記情報発信数に関する有意差が現れるような組み合わせを選択する
付記10又は付記11記載の位置推定プログラム。
(付記13)
前記複数の基礎自治体における各基礎自治体から、他の基礎自治体に比べて前記情報発信数に関する有意差が現れる基礎自治体の組み合わせを選択する場合、地理的に連続するような基礎自治体の組み合わせを選択する
付記10又は付記12記載の位置推定プログラム。
(付記14)
前記地理的に連続する基礎自治体の組み合わせのうち、面積が他の基礎自治体の組み合わせに比べて小さくなるような基礎自治体の組み合わせを選択する
付記13記載の位置推定プログラム。
(付記15)
前記地理的に連続する基礎自治体の組み合わせのうち、交通機関の沿線に位置する基礎自治体の組み合わせを選択する
付記13記載の位置推定プログラム。
(付記16)
前記複数の時間帯における隣接する時間帯のうち、より早い第1の時間帯での前記基礎自治体の組み合わせに含まれる特定の基礎自治体から、より遅い第2の時間帯での前記基礎自治体の組み合わせに含まれる前記特定の基礎自治体と異なる他の基礎自治体に移動するのに要する時間が、前記隣接する時間帯で表される期間より短い場合、前記第2の時間帯における前記基礎自治体の組み合わせから前記他の基礎自治体を削除し、前記第2の時間帯における前記情報の発信比率を再度算出する
付記13〜付記17の何れか1項に記載の位置推定プログラム。
(付記17)
前記情報発信数に関する有意差が認められない時間帯が存在する場合、前記情報発信数に関する有意差が認められない時間帯に隣接する時間帯における前記情報の発信比率から、前記情報発信数に関する有意差が認められない時間帯における前記情報の発信比率を算出する
付記12〜付記16の何れか1項に記載の位置推定プログラム。
(付記18)
前記複数の時間帯から、前記複数の基礎自治体における各基礎自治体の何れかで、他の基礎自治体に比べて前記情報発信数に関する有意差が現れる時間帯の組み合わせを選択する場合、時間的に連続するような時間帯の組み合わせで、且つ、期間が他の時間帯の組み合わせに比べて短くなるような時間帯の組み合わせを選択する
付記11又は付記12記載の位置推定プログラム。
(付記19)
ソーシャルメディアに発信された情報に紐づけられたユーザ情報毎に、複数の基礎自治体における基礎自治体毎で、且つ、複数の時間帯における時間帯毎に情報発信数を集計する集計部と、
前記情報発信数に基づいて、前記ユーザ情報毎に、前記複数の基礎自治体から、他の基礎自治体に比べて前記情報発信数に有意差が現れる基礎自治体の組み合わせを前記時間帯毎に選択する選択部と、
前記選択部で選択した基礎自治体の組み合わせにおける基礎自治体毎の前記情報発信数から、前記ユーザ情報毎に、前記選択した基礎自治体の組み合わせにおける基礎自治体毎の前記情報の発信比率を前記時間帯毎に算出する算出部と、
前記ソーシャルメディアから新たに収集した情報に情報の発信位置を特定する位置情報が含まれない場合、前記新たに収集した情報に含まれる情報の発信時間、及び前記新たに収集した情報を発信したユーザ情報に対応する前記算出部で算出した発信比率に従って、前記新たに収集した情報を発信したユーザの位置を推定するユーザ位置推定部と、
を含む位置推定装置。
(付記20)
ソーシャルメディアに発信された情報に紐づけられたユーザ情報毎に、複数の基礎自治体における基礎自治体毎で、且つ、複数の時間帯における時間帯毎に情報発信数を集計する集計部と、
前記情報発信数に基づいて、前記ユーザ情報毎に、前記複数の時間帯から、前記複数の基礎自治体における各基礎自治体の何れかで、他の基礎自治体に比べて前記情報発信数に関する有意差が現れる時間帯の組み合わせを選択する選択部と、
前記ソーシャルメディアから新たに収集した情報に情報の発信位置を特定する位置情報が含まれない場合、前記新たに収集した情報に含まれる情報の発信時間、及び前記新たに収集した情報を発信したユーザ情報に対応する前記選択部で選択した時間帯の組み合わせに従って、前記新たに収集した情報を発信したユーザの位置を推定するユーザ位置推定部と、
を含む位置推定装置。
(付記21)
前記選択部は、前記複数の基礎自治体及び前記複数の時間帯の項目のうち、一方の項目に関する組み合わせでは前記情報発信数に関する有意差が現れない場合、前記複数の基礎自治体における各基礎自治体及び前記複数の時間帯における各時間帯の組み合わせの中から、他の基礎自治体に比べて前記情報発信数に関する有意差が現れるような組み合わせを選択する
付記19又は付記20記載の位置推定装置。
(付記22)
前記選択部は、前記複数の基礎自治体における各基礎自治体から、他の基礎自治体に比べて前記情報発信数に関する有意差が現れる基礎自治体の組み合わせを選択する場合、地理的に連続するような基礎自治体の組み合わせを選択する
付記19又は付記21記載の位置推定装置。
(付記23)
前記選択部は、前記地理的に連続する基礎自治体の組み合わせのうち、面積が他の基礎自治体の組み合わせに比べて小さくなるような基礎自治体の組み合わせを選択する
付記22記載の位置推定装置。
(付記24)
前記選択部は、 前記地理的に連続する基礎自治体の組み合わせのうち、交通機関の沿線に位置する基礎自治体の組み合わせを選択する
付記22記載の位置推定装置。
(付記25)
前記算出部は、前記複数の時間帯における隣接する時間帯のうち、より早い第1の時間帯での前記基礎自治体の組み合わせに含まれる特定の基礎自治体から、より遅い第2の時間帯での前記基礎自治体の組み合わせに含まれる前記特定の基礎自治体と異なる他の基礎自治体に移動するのに要する時間が、前記隣接する時間帯で表される期間より短い場合、前記第2の時間帯における前記基礎自治体の組み合わせから前記他の基礎自治体を削除し、前記第2の時間帯における前記情報の発信比率を再度算出する
付記22〜付記24の何れか1項に記載の位置推定装置。
(付記26)
前記算出部は、前記情報発信数に関する有意差が認められない時間帯が存在する場合、前記情報発信数に関する有意差が認められない時間帯に隣接する時間帯における前記情報の発信比率から、前記情報発信数に関する有意差が認められない時間帯における前記情報の発信比率を算出する
付記21〜付記25の何れか1項に記載の位置推定装置。
(付記27)
前記選択部は、前記複数の時間帯から、前記複数の基礎自治体における各基礎自治体の何れかで、他の基礎自治体に比べて前記情報発信数に関する有意差が現れる時間帯の組み合わせを選択する場合、時間的に連続するような時間帯の組み合わせで、且つ、期間が他の時間帯の組み合わせに比べて短くなるような時間帯の組み合わせを選択する
付記20又は付記21記載の位置推定装置。
(付記28)
コンピュータに、
ソーシャルメディアに発信された情報に紐づけられたユーザ情報毎に、複数の基礎自治体における基礎自治体毎で、且つ、複数の時間帯における時間帯毎に情報発信数を集計し、
前記情報発信数に基づいて、前記ユーザ情報毎に、前記複数の基礎自治体から、他の基礎自治体に比べて前記情報発信数に有意差が現れる基礎自治体の組み合わせを前記時間帯毎に選択し、
前記選択した基礎自治体の組み合わせにおける基礎自治体毎の前記情報発信数から、前記ユーザ情報毎に、前記選択した基礎自治体の組み合わせにおける基礎自治体毎の前記情報の発信比率を前記時間帯毎に算出し、
前記ソーシャルメディアから新たに収集した情報に情報の発信位置を特定する位置情報が含まれない場合、前記新たに収集した情報に含まれる情報の発信時間、及び前記新たに収集した情報を発信したユーザ情報に対応する算出した発信比率に従って、前記新たに収集した情報を発信したユーザの位置を推定する
ことを含む処理を実行させるための位置推定プログラムを記録したコンピュータ読み取り可能な記録媒体。
(付記29)
コンピュータに、
ソーシャルメディアに発信された情報に紐づけられたユーザ情報毎に、複数の基礎自治体における基礎自治体毎で、且つ、複数の時間帯における時間帯毎に情報発信数を集計し、
前記情報発信数に基づいて、前記ユーザ情報毎に、前記複数の時間帯から、前記複数の基礎自治体における各基礎自治体の何れかで、他の基礎自治体に比べて前記情報発信数に関する有意差が現れる時間帯の組み合わせを選択し、
前記ソーシャルメディアから新たに収集した情報に情報の発信位置を特定する位置情報が含まれない場合、前記新たに収集した情報に含まれる情報の発信時間、及び前記新たに収集した情報を発信したユーザ情報に対応する選択した時間帯の組み合わせに従って、前記新たに収集した情報を発信したユーザの位置を推定する
ことを含む処理を実行させるための位置推定プログラムを記録したコンピュータ読み取り可能な記録媒体。