土木学会論文集F3（土木情報学）, Vol. 67, No. 2, I_170-I_180, 2011.

都市空間における効率的な動線解析の共通基盤のあり方について関本 義秀1・薄井 智貴2・金杉 洋3・増田 祐介4
1正会員

東京大学空間情報科学研究センター 特任准教授（〒277-8568 千葉県柏市柏の葉5-1-5）
1E-mail:sekimoto@csis.u-tokyo.ac.jp

2正会員

東京大学空間情報科学研究センター 特任助教（〒277-8568 千葉県柏市柏の葉5-1-5）
2E-mail:usui@csis.u-tokyo.ac.jp

3非会員

東京大学生産技術研究所 特任研究員（〒153-8505 東京都目黒区駒場4-6-1）
3E-mail:yok@iis.u-tokyo.ac.jp
4非会員㈱長大 社会事業本部（〒114-0013 東京都北区東田端2-1-3）
4E-mail: masuda-y@chodai.co.jp

本研究では，ビジネスレベルでの利活用を念頭に置いた都市空間における多数の人々の位置データの品質の確保とその処理のための共通基盤のあり方をまとめ，人の動きに関して様々なところで行われる調査データの処理負担を軽減することにより，調査の迅速化・低コスト化を実現し，現状の課題や将来像の議論等，より本質的な問題の分析への注力を目指すものである．具体的には，人の流れデータについてのニーズ・シーズを概観し，それらを踏まえ実用レベルでの利活用を念頭においた上で，効率的なデータの処理を行えるような動線解析プラットフォームのWebAPIを定義・実装し，実際のパフォーマンス計測等を行い，実用上，概ね問題ないことを確認した．

Key Words : traffic flow analysis , common platform, people flow, WebAPI

1. はじめに
近年，都市内において，地震や火災発生あるいは大規模イベント開催における混乱に伴う二次的災害
や，ターミナル駅等の交通結節点における混雑などを解消する必要性から，ダイナミックに時々刻々と変動する多くの人々の流動を日常的に把握する必要が出てきている．たとえば公共施設管理者のような，より安全，快適な空間を構築し，適切な交通政策を立案する立場からは，ダイナミックに変化する人々の動きを総合的すなわち面的に把握することが必要不可欠である．また，民間分野においてもたとえば屋外広告では個別空間ごとに見られる頻度が異なる
ため，人の通行量に応じた場所ごとの価格体系等が存在し，無駄のない広告活動を支える重要な情報源となっている．
一方で技術的には，従来のパーソントリップ調査のような統計調査による静的データに加え，各種計測技術の発展により，GPSを用いた個人の移動経路，
CCTVカメラを用いた面的な人数，ICタグを用いた自動改札による駅の乗降客数，携帯電話基地局等へ

I_170の端末登録数，あるいはデパートの時間帯別来場者数など，様々な切り口で人の移動について計測できるようになってきている．また表示手法についても
CG， GIS， CAD技術の進展により，都市圏全体のような広域の二次元空間で多数の人の集中状況を俯瞰したり，ターミナル駅内部のような狭域の三次元空間での局所の人の動きの特性を分析するといった，
よりリアリティを持たせつつ全体を視覚化することも可能になってきている．
しかし，上記のような人々の動きに関する調査・計測の実データをビジネスレベルで流通可能にするには，大量のデータの品質をある程度そろえることが必要であり，調査・計測からデータの加工・蓄積，
表示・提供に至るまで一連の流れをバランスよく効率的に処理することが重要である．しかし実際に，そのような処理プロセスは，非常に重要であり，かつ労力を要する部分であるにもかかわらず，個々のノウハウに依存してその場しのぎ的かつブラックボ
ックス的に行われていることが多く，その結果として，時間的にも費用的にも長期，高コストとなり，

土木学会論文集F3（土木情報学）, Vol. 67, No. 2, I_170-I_180, 2011.

最終的なビジネスレベルの利活用までに行き着くことはなくあまり議論されていないのが現状である．
従って本研究では，ビジネスレベルでの利活用を念頭に置いた大量の人々の位置データの品質の確保とその処理のための共通基盤のあり方について，ニーズ，シーズ，社会的な役割分担などいくつかの主要因からプロトタイプもまじえ概観した．具体的には，人の移動データについての各分野のニーズや，
シーズとしての既存技術や現在の課題を整理した（2 章）．また，それらを踏まえ実用レベルでの利活用を念頭においた上で，効率的なデータの処理を行う「動線解析プラットフォーム」を提案し，基本的な考え方や具体的な関数として WebAPI（API：Application Programming Interface）の構成を説明した（3 章）．その後，パフォーマンスの妥当性やその利用例を説明し（4 章），最後に結論や今後の課題を整理した（5 章）．
なお，著者らは2008年7月に東京大学空間情報科学研究センターの中に「人の流れプロジェクト 注
1)」を立ち上げ，その中で動線解析プラットフォー
ムを運用してきた．本研究はその活動の一環であり，とくに動線解析のための共通基盤のあり方の側面についてまとめたものである．

を調査している 注 6)．また，従来の地域の人口分布
ではなく，時間帯別の人口分布を具体的に算出し，店舗数との関連を見た研究などもある 5)．
c) くらし・防災における利活用
その一方で，災害の観点からの利用もある．東日
本大震災では，首都圏でも交通マヒにより徒歩で帰宅する人で路上があふれかえる帰宅困難者が発生した．帰宅困難者に関するシミュレーションはかねてから例えば新宿区で検討され，PT 調査データなどが使われていたが 注 7)，想定以上の大規模な交通マ
ヒにより，なかなか実態への対応は難しかった．こ
うした状態には今後は，リアルタイムな状況を表す
携帯電話の位置情報や基地局レベルの集計情報などが効果的であろう．
d) 医療・環境における利活用
さらに医療・環境分野ではどうだろうか．公衆衛生の観点では，2009 年の新型感染症を始めとして，人の流れに対して，感染症の拡大状況をシミュレー
ションした研究がある 6,7)．また，2010 年に国土交
通省都市・地域整備局で策定された「低炭素都市づくりガイドライン」では，PT 調査から CO2 排出量削減効果予測の手法がまとめられている注 8)．
(2) データ取得技術の進展
一方で，データ取得技術については折に触れ紹介されている8,9,10)．主なものについて，既存データ／
今後利用可能性のあるデータに，データ取得のタイミングとして定期的／イベント時のみという形に分類して整理を行った（表-1）．とくに最近ではとくにSuica等のIC乗車券や携帯端末に乗降駅，購買状
況などが記録されるようになり，それらを用いた研究11)や，携帯基地局情報を用いた位置情報の収集を行うセルラープローブ技術も欧米の企業で携帯電話会社と連携を取る形で始まってきている12)．
とくにセルラープローブ技術はわかる位置精度としてはかなり粗いものであるが，リアルタイム情報である点や基地局以外に追加のインフラ投資がいらない点で有効であり，広域災害時への適用なども検討も見られる 13)．これらは主に自動車交通を対象にしたものであるが，群衆を対象としたものもRattiら
14)の研究を始めに，Horanontら15)，Urban Computingの分野に広がり始めている．なお，携帯電話を使った人々の流動解析技術の最近の動向は，別途，関本ら16)でもまとめられているため参考にされたい．
また，必ずしも調査機器を用いない形でも近年はインターネットを通じてアンケート調査を行う企業が増加している 注9）．それらは常時モニター（パネル）を数万人～数十万人抱え，様々な形の謝礼によってインセンティブを確保するなどの形態が一般化しており，それらを利用することも可能である．

2. 人の移動に関するデータニーズと技術シーズ
ここでは，まず，人の流れに関するデータのニー
ズと技術シーズ，さらにそれらにもとづくデータ処
理技術について述べる．
(1) 各分野における利活用a) 交通分野における利活用
人の流れのニーズは多岐にわたる．まず交通分野の歴史は古く，パーソントリップ調査（以下，PT
調査と呼ぶ） 注2), 1, 2)や大都市交通センサスのような広域の流動を分析するものに始まり，最近ではある
特定の地域をGPS等の位置特定機器を用いて詳細に分析するようなプローブパーソン調査がある（例えば国内ではプローブパーソン研究会 注 3)，英国 注 4)，
米国 注 5)など）．前者のPT調査等はある一日の行動を調査し，都市全体の中の典型的な流動を見るものである一方，後者のプローブパーソン調査は，複数日間の連続的な調査なども行いやすく，人の属性に
地域の特性に応じた行動分析が行いやすい．
b) マーケティングにおける利活用
さらに，マーケティング・広告などへの利活用もあ る ． と く に ， 屋 外 広 告 （ OOH ： Out Of Home
media）3)，や最近出てきたデジタルサイネージ（電子看板）は，注目を集めることに主眼があるため，人の移動と密接な関係があり，適切な出稿や事後評
価のために民間企業による移動に関する調査統計データの販売なども始まりつつある．例えば，首都圏・関西圏を中心に，JR 東日本では，3 年ごとに 1万人調査が定期的に行われているし 4)，ビデオリサーチ社の「屋外メディア総合調査（SOTO）」では数千人レベルで鉄道・道路・街・店舗などの通過者

I_171

土木学会論文集F3（土木情報学）, Vol. 67, No. 2, I_170-I_180, 2011.

で表現し，人ごとに ID を振ることとした（表-2）．
ただしこの ID はデータ内部の独自 ID であり，あくまで機械的なものである（以降，PID と呼ぶ）．
また，それらのデータは多量であり，(2)以降で述べるような検索やマップマッチングのような基本的な処理がWebAPIとして円滑にできるようにするには，適切なデータベース構造の設計なども必要となる．時空間データベースそのものの研究もWolfson et al.（1999）18)など多数あるものの，ここでは単純な構造で高速な検索を実現するために，該当オブジェクトを時空間検索で特定するための検索用テーブルと，オブジェクト単位の属性や各時空間
位置のデータを保持したテーブルの2層構造とした．
図-2は具体的にSekimoto et al.で実際に調査対象の属性（PERSON）やトリップ（TRIP），サブトリッ
プ（SUBTRIP），各ポイント（POINT）等を含む
PTデータを上記テーブル構成に従って格納した手順である．実際に2011年12月現在で東京都市圏をはじめとして，14都市圏（15調査）のデータを提供して おり， 例えば 東京の PT調 査デー タ（平 成 10年度）は約72万人，すなわち72万PIDのデータがあり，オブジェクトテーブルでは，全PIDをそれぞれ一行ずつ格納し，カラム方向で1日全てを1分ごとの時空間位置に分けている（ただし，データベースソフトの都合上，ここでは，午前と午後で2つのテーブルに分かれている）．また，時空間検索用テーブルでは，とくに時間断面での検索を強化するために，時間ごとにテーブルを分けて作成するとともに，「PIDのみ」「PID，緯度，経度」「PID，メッシュ
番号」に対してインデキシングを行った．

表-1 人の時空間位置に関する様々なデータ取得技術
データ取得
タイミング

定期的

既存のデータGPS

利用可能性のあるデータ

携帯基地局情報

イベント時のみ（センサ設置個所のみ）
カメラ，VICS，ETC，Web調査，POS，Wi-Fi
ICカード，レーザー(3) 時空間データ処理技術の進展(1)のニーズや(2)の技術的シーズをふまえ，デー
タの要件定義を行い，状況に応じた時空間データの作成を行うこととなる．例えば，Sekimoto et al.（2011）17)は断片的な時空間データではあるものの偏りのない大規模なサンプルデータを持つPT調査デー
タを用いて，最短経路ベースでネットワークデータに沿った形で時空間内挿を行った「人の流れデー
タ」を作成している（図-1）．
こうした生データを，ユーザーのニーズに合わせた形で 処理するサービスはクラウドの流れが強まる中で，今後も増えると思われる．Google Transitだ
けでなく，商用のASPサービス注11)なども存在しているが，乗換案内やマップマッチングなど単機能のものが多く，取得データの2次利用がしにくいケー
スも多く，学術的な意味も含めて動線解析全般に使
えるとはいいにくい．従って，技術をキャッチアッ
プしつつ中立的な用途として大学の立場からこうしたサービスを実現することも社会的な役割として重要なものと考えられる．

3. プラットフォームの基本的な考え方
前章のニーズ，シーズを踏まえ，本章では動線解
析プラットフォームの基本的考え方として，データ
定義，データベースや WebAPI の仕様を述べる．

表-2 時空間データの定義
PID
1
...
5
...
5
5
...
5
6
...

(1) データ定義とデータベース仕様
前章のニーズを踏まえると，任意の時刻，任意の空間範囲，任意の人の位置を知りたい一方，調査・計測データは定期的に数分間隔であったり，計測できた時のみになりがちである．従って本研究では，
データの時間解像度を 1 分間隔として稠密にすることを基本とし，データ取得のない時間帯は何かしらの内挿で埋めることとした．また空間は緯度・経度

Time
...
...
0:00
...
8:15
8:16
...
23:59
...
...

Longitude...
...
139.88325...
139.88325
139.87834...
139.88325...
...

Latitude...
...
35.66349...
35.66349
35.66334...
35.66349...
...

図-1 パーソントリップデータを用いた流動再現（Sekimoto et al. (2011)17)をもとに作成．青は鉄道，赤は徒歩，黄緑は自家用車，黄色が自転車による移動）

I_172

土木学会論文集F3（土木情報学）, Vol. 67, No. 2, I_170-I_180, 2011.

時空間検索用テーブル（PID，1分毎，インデクス付）
登録時テーブルPERSONTRIP
SUBTRIP
POINT

ワークテーブル（全時間）（PID毎）

オブジェクトテーブル（全PID分を１つのテーブルに格納）
カラム項目
PID
性別
年齢
住居地（ゾーンコード）
職業
拡大係数
拡大係数その2
時刻T0000のデータ
トリップ番号,サブト
リップ番号, 移動目的
コード, 交通手段コー
ド,経度,緯度（カンマ
区切り）（※1）
時刻T0001のデータ
同上
・・・
時刻T2359（※2）
同上

チェックログテーブル（PID毎）

オブジェクトテーブル（PID毎） 午前

データ型
(桁数)
VC(10)C(1)VC(3)
VC(10)
C(2)N(6,0)
N(6,0)
VC(255)

チェック結果テーブル（PID毎）

午後時空間検索用テーブル（時間ごとにテーブルを作成）

データ例

カラム項目

34748
1
9
10701301
1
12
12

PID
トリップNO
サブトリップNO
日時
経度
緯度
時間間隔
メッシュ番号
オリジナルフラグ
性別
年齢
住所
職業
目的
拡大係数
拡大係数その2
交通手段
出発日時
到着日時
登録日時
調査ID

1,1,99,97,1
30.732647,
33.833945

VC(255)・・・・

VC(255)・・・・（※1）交通手段変化点で2点ある場合は/で区切るものとする（※2）実際には，DBソフトの制約上，午前と午後でテーブルを分けている（※3）VC：可変長文字列，C：固定長文字列，
N：数値（桁数，小数点以下桁数），DATE：日付と時刻（※4）下線のカラム項目は主キー

データ型
(桁数)
VC(10)
N(8)
N(8)
DATE
N(15,10)N(15,10)N(2)VC(15)
C(1)
C(1)
VC(2)
VC(10)
C(2)
C(2)
N(6)
N(6)
C(2)
DATE
DATE
DATE
VC(5)

データ例
63333
2
5
00-10-02
141.583566
42.909082
15235-57-62-1711
1
1
1521711601
11
99
29
29
97
00-10-02
00-10-02
10-01-13
98TKY

図-2 PT調査データをもとに人の流れデータを格納した際のデータベースのテーブル構造（上：各テーブル作成のフロー，下：WebAPIで参照するオブジェクトテーブルと時空間検索テーブル）ービス提供している．

(2) WebAPIの構成
一方で，前節のプラットフォームの利用場面を考えると，大きく分けて，予めきちんとデータベース
化されたデータをユーザーが効率的に使うための「データ提供機能」と，ユーザーが持つデータを自らマップマッチングや得られない時間帯の空間デー
タを何らか補間する「データクリーニング機能」がある．具体的には，前者はデータの時空間検索のような機能が必要とされ，後者はマップマッチング，
経路検索，時空間内挿，データチェック等の機能が必要である．実際の利用場面では，あるアルゴリズ
ムを実装するために様々な基本的な処理関数を組み合わせて使えるよう，こうした関数が一通り準備されていることが重要であり，本研究ではこれらの関数をWebAPIとして用意することとした（表-3）．
詳細は(4)以降で説明するが「人の流れプロジェク
ト」サイト内でもWebAPI仕様書として公開するとともに，「時空間データクリーニングサービス」と「時空間データ提供サービス」の2種類に分け，サ(3) 利用するインフラデータ
前節で述べたような様々な処理には道路や鉄道のネットワークや時刻表等，いくつかなインフラに関する基盤データが必要となる．ここでは，道路と鉄道のネットワークデータとしてDRMデータ（Digital
Road Map：デジタル道路地図協会）注12)を用いる．
DRMデータは全道路まで含めると全国で総延長約89万kmをカバーし，約487万リンク存在している（2011年3月末）．
なお，DRMデータの道路部はノード・リンクの位相構造を構成するネットワーク以外に幾何形状の豊かさを確保するために，1つのリンクにいくつかの補間点が存在している．従って，道路の経路探索にはノード・リンクの位相構造を用いる一方，マップマッチングや時空間内挿の一部では，幾何形状の詳細さを確保するために補間点を用いる．
その一方で，DRMデータは鉄道のネットワーク

I_173土木学会論文集F3（土木情報学）, Vol. 67, No. 2, I_170-I_180, 2011.

はあるものの位相構造やそれに伴う所要時間等の属性はなく，路線の幾何構造のみである．従って，鉄道の経路探索では，何らかの時刻表データベースが必要であるものの，時刻表データベースそのものは非常に高価であるため，本研究では「駅すぱあと（㈱ヴァル研究所）」注13)の鉄道経路所要時間デー
タを用いる．ただし，所要時間データのみを利用する欠点として，鉄道の運行がない，または非常に少ない時間帯でもすぐに移動してしまう点が挙げられる．また，マップマッチングや時空間内挿の一部は道路と同様にDRMの幾何構造のデータを用いる．
このように，鉄道の場合，経路を求める時刻表と時
空間内挿等で用いる幾何構造は全く違うデータであるため，駅名の表現等が多少異なり，組み合わせて使う場合は注意が必要となる．本研究では，これらをつなぐ対応テーブルを作成している．
なお，日本国内だけでなく，海外で同様のことを行う際にもこうしたインフラデータは必要であり，極力汎用的なものが使えるとよい．最近はボランテ
ィアによって整備が進みつつある，フリーのOpen
Street Mapデータ（OSMデータ）注14)が位相構造を構築しやすいため，本研究ではそれをネットワークデータとして用いる．これらネットワークデータの位相構造や幾何構造の量についてSekimoto et al. を元に東京とハノイの比較をまとめたものが表-4である．

表-3 主要なWebAPIの仕様概略
API
マップマ
ッチング

任意点の道路近傍点取得【GetNearestRoadPoint】

経路探索

道路の経路探索（点座標指定）【GetRoadRoute】

鉄道の経路探索（駅指定，点座標指定）【GetRailRoute】

時空間内
挿

データ検
索

機

入力／出力

能

入力

任意の点座標より，道路
ネットワークにおけるその位置の近傍座標を，ネットワークの補間点レベルで取得する．
任意の点座標（起点，終点，経由点）より，それら地点を結ぶ道路上の最短経路を取得する．
任意の駅（起点，終点，
経由点）より，それら地点を結ぶ鉄道上の最短経路を取得する．

鉄道の経路探索（鉄道駅までの道路の経路探索含む）【GetMixedRoute】
時空間内挿の実施【GetSTInterpolatedPoint】

任意の点座標（起点，終点，経由点）より，それら地点を結ぶ道路及び鉄道経路を取得する．
任意の時空間位置（起点，終点の時空間位置）
より，それらを内挿する
時空間位置を取得する．

時空間検索に該当する
PID リストの取得【GetPIDList】

時空間内挿済みの登録
PT データ，検索条件に一致する PID リストを取得する

PID に該当するオブジェ
クトデータの取得【GetFlowData】

時空間内挿済みの登録
PT データから，PID を指定し，該当する PID の指
定時間範囲分のデータセットを取得する．
時空間内挿済みの登録
PT データから，指定した検索条件と一致する
人々の時空間位置に関する情報を取得する．
時空間内挿済みの登録
PT データから，指定した検索条件と一致する
人々の時空間位置に関す
る情報について，ネット
ワークデータを背景とした画像として取得する．

時空間位置情報の取得【GetDistributionData】

時空間位置画像の取得【GetDistributionImage】

出力・近傍点座標・道路種別
・路線番号
・2 次メッシュコード

・点座標
・道路種別
・路線番号

[必須]
[ｵﾌﾟｼｮﾝ][ｵﾌﾟｼｮﾝ]

・起点座標
・終点座標
・経由点座標・道路種別
・路線番号
・出力経路数・起点駅（駅名または座標）
・終点駅（駅名または座標）
・位置単位指定（駅名または座標）
・経由駅（駅名または座標）
・出発／到着日時
・起点座標
・終点座標
・経由点座標[必須][必須][ｵﾌﾟｼｮﾝ][ｵﾌﾟｼｮﾝ][ｵﾌﾟｼｮﾝ][ｵﾌﾟｼｮﾝ]
[必須]
[必須]
[必須]

・起点日時
・終点日時
・起点座標
・終点座標
・内挿時間間隔・調査 ID・時空間範囲・属性
・オブジェクトの選択[全数かランダムサンプル]
・指定条件 通過または滞在・調査 ID
・PID
・開始日時
・終了日時

[必須]
[必須]
[必須]
[必須]
[ｵﾌﾟｼｮﾝ][必須][必須][ｵﾌﾟｼｮﾝ][ｵﾌﾟｼｮﾝ]・調査 ID・検索条件（*1）[ｵﾌﾟｼｮﾝ][ｵﾌﾟｼｮﾝ]・時空間位置座標リスト
・レスポンスリスト

・調査 ID・検索条件（*1）[ｵﾌﾟｼｮﾝ][ｵﾌﾟｼｮﾝ]
[必須]
[必須]

・出力画像

[ｵﾌﾟｼｮﾝ][ｵﾌﾟｼｮﾝ][必須][必須][ｵﾌﾟｼｮﾝ][ｵﾌﾟｼｮﾝ]
[必須]
[必須]
[必須]
[必須]

・経路座標リスト
・経路延長

・経路座標リスト
・通過駅
・駅出発／到着日時

・経路座標リスト
・通過駅
・時空間位置座標リスト

・PID リスト（区切り文字つき）

・時空間位置座標リスト（指定時間範囲分）*1 検索条件は，以下の通りである．実際に指定する値等詳細については動線解析プラットフォーム WebAPI 仕様書を参照のこと．
【空間指定（任意）】中心座標（経度，緯度），距離単位指定，縦距離，横距離 【日付指定（必須）】日付，時刻 【属性指定（任意）】交通手段，性別，年齢

I_174

土木学会論文集F3（土木情報学）, Vol. 67, No. 2, I_170-I_180, 2011.
表-4 インフラデータの構成例（東京都市圏とハノイ都市圏のケース）
都市圏
東京都市圏
ハノイ都市圏道路
位相構造
約 133 万ノードと約 191 万リンク（DRM）
約 5,600 ノード と 3,600 リンク（OSM）

鉄道
幾何構造

位相構造

幾何構造

約 678 万補間点（DRM）

1,455 駅（DRM）

約 5 万補間点（DRM）

約 2.4 万補間点（OSM）

---

---

(4) マップマッチング機能
マップマッチング機能は，GPS データなどのクリーニングを念頭に，道路ネットワークデータ（DRM データ）に対して行い，最も近い補間点を含むリンクの垂線の足を取得している（"GetNearestRoadPoint"）．なお探索は入力点より1km 以内の範囲に対して行い，半径 1km 以内にネットワークデータが見つからない場合はエラーとなる．
もともと歩行者のためのマップマッチングのアルゴリズムとして小島ら 19)，三輪ら 20)などがあり，
例えば時間的に連続した GPS データの場合は，位置的に近傍のネットワークを重点的に探索すること
によって効率化が得られる場合もあるものの，大量の様々な場所の位置データを処理することもあり得るため，本研究は該当する補間点の検索を効率化するために，DRM データを 2 次メッシュ単位でテーブルを分けることで対応している．
ただし，本研究の場合，高速道路を走行した場合
は，IC 以外の場所でマッチングしてしまうこともあるため，その点は今後改良が必要である．

時空間内挿機能は，前節の経路探索で求められる
位相構造レベル（道路で言えばノードレベル，鉄道
でいえば駅レベル）に比べ，より詳細な時間間隔を入力した時（例えば 1 分間隔）は，ノード間や駅間を直線，あるいは道路や鉄道の幾何構造に沿って内挿することになるため，計算時間も多くなるものの
詳細性・リアリティが保たれる． 図-3 は 3 つのサブトリップを持つある人の動きをサブトリップごとに 1 分間隔で時空間内挿したものである．
このような機能については，おそらく従来は経路探索の範囲で行われていたと思われるが，多数の移動体の分布を時間断面で見たいという場合は各時間ごとに位置情報を求めなおす必要があり，とくに都
市内の道路や建物が密集している空間の場合は，単純な直線内挿を行うと，道路や鉄道上を通らず，建物内を突き抜けるような移動が多発してしまい，こうした分布が混在しないことが重要であり，必要性が高いにも関わらずそのような研究はなかったといえる．
(7) 時空間検索機能
時空間検索機能は，サーバーに何らか格納されている人の時空間データを時間・空間・属性で，検索し該当 PID を取り出すものである．(1)でも触れたように，例えば東京都市圏の人の流れデータは 72
万人分の 1 分間隔の時空間位置データが属性とともに格納されており大変膨大であるため，時空間検索用テーブルとオブジェクトテーブルの 2 種類のテーブルで効率化し，それぞれの検索にも実時間で対応できるようにしている．
また，時空間検索の利用をいくつかのタイプに分けて，WebAPI（GetPIDList）の挙動をまとめたものが表-5 である．時間を限定して，時間断面での人の分布状態を求めるタイプ 1，空間を限定し，そこを通過・滞在する人（来街者調査（図-4）やセンサ
ス観測地点などを想定）を求めるタイプ 2，属性を絞った形で検索を行うタイプ 3 などがある．さらに，
タイプ 2 の通過・滞在はそれぞれ，少しでも通った
人，ずっといた人と本研究では定義している（タイプ 4）．そして，ランダムでサンプル抽出した人の挙動を見るようなこともできる（タイプ 5）．
GetPIDList で当該 PID を特定した後，その PID のオブジェクトデータ（例えば一日の動き）を取り出すものが GetFlowData である．図-4 は来街者調査のイメージで，東京都市圏の人の流れデータ（平成10 年度）の登録データ 72 万人の中から朝 9 時に渋(5) 経路探索機能
経路探索機能は，任意の起終点・経由点を入力しそれらを結ぶ道路上の最短経路を返す"GetRoadRoute"と，任意の駅を入力しそれらを結ぶ
鉄道上の最短経路を返す"GetRailRoute"と，長距離
移動は鉄道を使いつつ，最寄までは道路を使って移動する"GetMixedRoute"の 3 種類を用意している．
道路上の最短経路を求める際には(3)で述べたように，DRM の位相構造（ノード・リンク）を用い，鉄道上の最短経路を求める際には「駅すぱあと」の鉄道経路所要時間データを用いている．
なお，道路の経路探索は基本的には時間最短であり，アルゴリズムレベルでは，現在はシンプルに
Djikstra 法で最短経路探索を用いて行っているが処理速度の都合上，全国のネットワーク分は全てオンメモリで処理している．また，各リンクの通行における所要時間はリンク長／速度であるが，速度は，
PT 調査のように予め交通手段がわかっている場合
は，付録の表-1 のような道路種別と交通手段に応じた速度を用いている．
(6) 時空間内挿機能
時空間内挿機能（"GetSTInterpolatedPoint"）は，2地点の時空間位置を入力し，それらを結ぶ最短経路を与えた時間の中で等速度で移動するとし，指定した時間間隔で時空間位置列を返すものである．

I_175

土木学会論文集F3（土木情報学）, Vol. 67, No. 2, I_170-I_180, 2011.
Station(11:45)Sub trip 2(Railway)Home(11:42)

11:42 (Lat1,Lon1)
11:43 (Lat2,Lon2)
11:44 (Lat3,Lon3)
11:45 (Lat4,Lon4)
11:46 (Lat5,Lon5)
11:47 (Lat6,Lon6)
11:48 (Lat7,Lon7)
11:49 (Lat8,Lon8)
11:50 (Lat9,Lon9)
11:51 (Lat10,Lon10)
11:52 (Lat11,Lon11)
11:53 (Lat12,Lon12)
11:54 (Lat13,Lon13)

Sub trip 1(Walking)

Office(11:54)

Station(11:49)Sub trip 3(Walking)

Railwaygeometry(Green line)(a)
Railway rough route(Blue line)
Walkingrough route(Red line)Road
topology(Gray line)Road
geometry(Gray line)(c)
Railway
topology(Green line)(b)
図-3 ある人のトリップのサブトリップの OD の時空間位置から 1 分間隔の位置を求めたもの時空間内挿の例（Sekimoto et al.を引用）

谷駅を中心とした 1km の矩形範囲内で滞在している人（通過は含めない）を GetPIDList で抽出したところ 538 人が抽出され，GetFlowData を用いて各人の 1 日の経路を赤く描いたものである．渋谷なので，色々な地域から満遍なく人が来ていることがわかる
が，とくに渋谷が都心では西の地域にあるため，やや西方面から来ている人が多いことも読み取れる．

また，基本的には，該当する時空間データそのものを検索・ダウンロードして，それぞれで分析等を行うことを想定するものの，背景地図がない場合などは背景画像とセットで分布状況を画像化することも有用であり，GetDistributionImage はそのようなことを行う WebAPI である．図-5 は，渋谷駅 5km 四方の朝 9 時の分布状況を描いたものである．通勤等
で人が集中していることが読み取れる．
なお，人の流れデータ取得に関わる時空間検索関係は，個人情報保護のため，人の流れプロジェクト内で利用申請が必要なことを補足する．

渋谷駅

図-4 GetPIDList を用いて渋谷の来街者サンプル 538 人の
1 日の経路を描いたもの．（平成 10 年の人の流れデータ 72 万人に対し，朝 9 時に渋谷駅を中心に 1km四方に存在した人を抜き出した．青：鉄道，黄緑：
個人車両，紫：商業車両，赤：徒歩）
図-5 GetDistributionImage を用いて渋谷駅周辺の 5km 四方の朝 9 時の分布状況を描いたもの（赤色の点）

I_176

土木学会論文集F3（土木情報学）, Vol. 67, No. 2, I_170-I_180, 2011.
表-5 時空間検索の主な利用タイプと WebAPI の挙動特性
検索のタイプ（タイプ 1）
時間を限定して時空間検索する

利用イメージ
時間断面での人の分布状態を求める（タイプ 2）
空間を限定して時空間検索するある場所を通過・滞在する人をカウントする（来街者調査やセンサス観測地点でのカウントなど）（タイプ 3）
属性による検索（タイプ 4）
通過と滞在を区別して検索する

ある属性の人を取り出す
少しでも通った人をカウント（通過），常にいた人をカウン
トする（滞在）サンプル抽出した人の挙動を見る（タイプ 5）
ランダムに人を取り出す

表-6 実験システムの諸元

GetPIDList の挙動
時間ごとに検索テーブルがあるので時間の特定は容易．空間範囲が全域の場合
は特定は不要であるが結果出力に時間がかかる．
時間範囲が長期にわたる時
は複数のテーブルをあたるので，その分時間がかかる．空間範囲がピンポイン
トであれば，2 次メッシュレ
ベルで少数に特定できるので早い．広域を対象とするとやや時間がかかる．
各属性で絞っている

滞在の場合，全ての時間範
囲内で存在していることを確認するため時間がかかる．
PID をランダムにしている

4. ケーススタディ(1) システムの概要
本システムは，HTTPリクエストベースでやり取りすることとし，WebサーバとDBサーバを組み合
わせ，Java1.6をベースに構築した（詳細は図-6，表-6を参照のこと）．

Java
etc ...

HTTPﾚｽﾎﾟﾝｽ(text/xml)

連携AP（ 利用側）

HTTPﾘｸｴｽﾄ(Postﾒｿｯﾄﾞ )HTML
ActiveXJava
etc ...

HTTPﾚｽﾎﾟﾝｽ(text/xml)

（
経
コ 路
探
ア
モ索
、
ジ座
ュ 標
ー変
ル換
等
）

Windows Server 2003

動線解析プラットフォーム
DBサーバ
Oracle 10g
Standard Edition

DB/IF

HTML
ActiveX

動線解析プラットフォーム
WEBサーバWEB API

HTTPﾘｸｴｽﾄ(Postﾒｿｯﾄﾞ )Web Server (Apache+Tomcat)

連携AP（ 利用側）

DB

ミドル
ウェア
OS・ハ
ードウ
ェア

Web サーバ
Apache 2.2.3
Tomcat 6.0.24
OS: Windows Server 2003
CPU: インテル Xeon
2.4GHz×16
メモリ：4GBDB サーバ
Oracle Standard Edition
10g
OS: Windows Server 2003
CPU: インテル Xeon
1.87GHz×2
メモリ：4GB(2) 各機能の速度
次にここでは，各基本的なWebAPIの処理速度の結果をまとめた．まずは表-7では，表-3で挙げた各
WebAPIに対し，複数回のリクエストを投げ，平均的な応答速度をまとめたものである．任意の位置から道路上の最近隣点を返す"GetNearestRoadPoint"は，他のAPIに比べるとシンプルな機能であるため，1秒以内となっている．一方で， "GetRoadRoute" や"GetRailRoute"は近隣の道路や鉄道ネットワークを探しつつ経路探索を行うため，数秒程度かかる．さらに，"GetMixedRoute"や"GetSTInterpolatedPoints"などは，いくつかの交通モードが混じった経路を返したり，時空間内挿を行い時間解像度（ここでは，1分）に応じて間の座標を算出しているため，重い処理で，10秒を超えている．
次に，とくに人の流れデータの時空間検索としてよく用いられる"GetPIDList"について，検索条件によって応答速度も変わり得るため，いくつか変化させて応答速度を算出したものが表-8である．検索時の空間的な範囲は，一次～三次メッシュの3種類，
時間が2分，1時間，24時間の3種類とし，また，通過と滞在のそれぞれを調べた．結果としては，当初の想定どおり，空間的に狭く絞るほど，時間的に短い間に絞るほど，検索速度は速くなる．また，滞在の方が全時間その空間にいることを調べることが必要になるため，時間はかかっている．

Windows Server 2003

図-6 システム構成
表-7 基本機能の処理速度
各WebAPI

テスト内容

秒数
0.79s
/ 0.49s

GetNearestRoadPoint

5.83s/ 2.73s

GetRoadRoute

GetRailRoute

一次メッシュ内（5339：関東／5033：四国）にラン
ダムに1000回の点（あるいは起終点）をとり実施

GetMixedRoute
GetSTInterpolatedPoints
GetPIDList
GetFlowData
GetDistributionData
GetDistributionImage（駅の通過人数を想定するようなもの）
・時間検索（10分） ・空間検索（駅周辺など）
PIDを指定して24時間分のトリップを取得する
一次メッシュ内（5339，98TKY／5033，97KCH）に
ランダムに1000回の中心点をとり実施
一次メッシュ内（5339，98TKY／5033，97KCH）に
ランダムに10回の中心点をとり実施

I_177

備考
1km以内に近傍点が見つからないケースがある（1000回中233回／771回）．
ルートが見つからない（起点または終点の1km以内に近傍点が見つからない）
ケ ー ス が あ る （ 1000 回 中 302 回 ／ 651
回）．秒数はルートがある時の平均．

1.67s/ 3.00s15.35s/ 19.97s
15.35s/ 16.33s

ルートが見つからないものはなかった※※詳細は表-8を参照

0.56s
0.36s
/ 0.16s
142.5s/ 139.8

インデクス作成時の値－ルートが見つからないケースがある（1000回中2回／6回）．

5km四方のデータ取得
5km四方のデータ取得

土木学会論文集F3（土木情報学）, Vol. 67, No. 2, I_170-I_180, 2011.
表-8 時空間検索（GetPIDList）に関する処理速度と検索時空間範囲の関係
上段：検索結果の人数（人），下段：検索秒数（秒）
時間範囲
空間範囲
メ
ッ
シ
ュ

緯
度
経
度

2分
（8 時～8 時 1 分 59 秒）
通過
滞在

1 時間
（8 時～8 時 59 分）
通過
滞在

24 時間
（0 時～23 時 59 分）
通過
滞在

一次メッシュ
（5339）

551,956/ 9.02551,518/ 13.22561,935/ 132.18

546,619/ 169.58

タイムアウト

二次メッシュ
（533945）

36,609/ 0.5835,577/ 1.1464,942/ 24.00

27,625/ 23.02

タイムアウト

三次メッシュ
（53394525）
中心座標（35.666669, 139.500001）
矩形範囲（縦 74271m×横 91143m）

763/ 0.05574/ 1.02

7,212/ 4.56371/ 1.70553,045/ 14.38

552,590/ 12.38

562,903/ 281.81

547,659/ 279.42

タイムアウト

中心座標（35.708335, 139.687549）
矩形範囲（縦 9279m×横 11314m）

36,651/ 1.7835,592/ 1.1264,945/ 40.38

27,645/ 38.38

タイムアウト

中心座標（35.687503, 139.69375）
矩形範囲（縦 928m×横 1134m）

759/ 0.99575/ 0.197174/ 7.88371/ 1.36

また，応答時間の絶対値はやや広域のケースとして時空間範囲を1時間，2次メッシュなどにした場合
は通過で24秒である．これはリアルタイムとはいかないまでも様々な分析を行う実用上の観点からいくと有効だと思われる．ただし，時間範囲を24時間としてしまうと，1次メッシュや2次メッシュの範囲だと，タイムアウト（300秒以上）となってしまう．
あまりに広域のケースだと今のところは難しいがこ
うした検索範囲はもとのフルデータそのものに近いものであり，別途一括ダウンロードで対応している．
(3) 都市圏全体の人の流れデータ構築に要する時間
ここでは，時空間検索のもととなる人の流れデー
タセットやそれに関わるテーブル構築にどの程度時間がかかっているかを，平成10年度の東京都市圏
PTデータで概観する．表-9はその処理に数を工程ごとにまとめたものである．最初は，PTデータはマ
スターデータがゾーンであるため，それらをジオコーディングし，緯度経度に変換したり，不明データが含まれるPIDについては除外をする必要がある．
ここの部分では，PTの調査ゾーンからうまくジオ
コーディングができないケースや不明データが多数含まれる場合の処理がたまにもあるため，こうしたエラーケースは手作業で補っている．
また，それ以降は基本的に自動処理となっている．
まずは各ODの時空間位置や交通機関を記録しているサブトリップ単位で，時空間内挿を行っている．
この時空間内挿はGetSTInterpolatedPointsなどの汎用的なWebAPIというよりは，高速化のためにPT用に特化したローカル関数で処理を行っているものの，3ヶ月程度かかっている．これは72万人で割ると1人あたりに要する処理時間は約10秒となる（1人あたりのサブトリップは4～5つ程度である）．これには，
サブトリップ中の移動を時空間内挿するだけではな
く，停滞している時間帯も座標を埋めることにも時間を費やしている．従って，各テーブルの作成時間
も数日ずつかかってしまうが，これらは後の時空間検索を極力高速化するためには，やむを得ない処理と考えている．

I_178

23,818/ 111.05

23,692/ 179.64

19/ 108.48

19/ 163.77

表-9 東京PTデータの処理工程
各工程
マスターデータからゾーンをジオコーディング
して緯度経度に変換やイレギュラーデータ除外
ジオコーディング済みPTデータから時空間内挿による人の流れデータの作成（約72万人分）※
ワークテーブルの作成
時空間検索用テーブルの作成（1440つのテーブル）
時空間検索用テーブルへのインデックスの作成
オブジェクトテーブルの作成（2つのテーブル）
チェック用テーブルの作成

処理日数数日（手作業有）
84日
14日
7日
0.5日
7日
7日

※ただし，ネットワークを介さない内部関数としてAPIを利用(4) WebAPIの利用頻度
このプラットフォームは無料で利用でき，2008年7月以来，研究者を中心に150名程度のユーザー登録
行われている．ここではログに記録されているうちの2010年7月から2011年8月まで（ただし，2011年5月は節電に配慮してサービスを停止）の約1年の各WebAPIの利用状況を見て，各処理関数の認知のされ方，使われる度合いを分析する．
実際にはプラットフォームの特性上，常時使っていることはなく，該当データを検索，ダウンロード
した後は各自の計算環境で使うことが多いが，各WebAPIの利用回数をまとめたものが表-10である．
具体的には，道路上の最近隣点を取得する"GetNearestRoadPoint"や時間断面での人々の分布状況を取得する"GetDistributionData"，該当する人の1日の移動状況を取り出す"GetFlowData"などが多くなっており，表-7で示した処理時間の短いものや，その機能が比較的シンプルで理解されやすいものに利用が集まるようである． なお，表 -10は現在は「人の流れプロジェクト」の事務局自体が利用している回数も含まれており，今後は分離した上での分析も必要である．

土木学会論文集F3（土木情報学）, Vol. 67, No. 2, I_170-I_180, 2011.
表-10 各WebAPIの利用回数
API名
GetNearestRoadPoint
GetRoadRoute
GetRailRoute
GetMixedRoute
GetSTInterpolatedPoints
GetPIDList
GetFlowData
GetDistributionData

注9) たとえば料金が公開されているものでは，㈱マクロミルなど
注10) Google transit ：www.google.co.jp/transit
注11) たとえばナビッピ位置情報ASPサービス（㈱ナビッピドットコム）など
注12) DRM: Digital Road Map（財団法人デジタル道路地図協会）：http://www.drm.jp/（アクセス：2011年10月21日）．
注 13) 駅 す ぱ あ と （ 株 式 会 社 ヴ ァ ル 研 究 所 ） ：http://ekiworld.net/（アクセス：2011年10月21日）．
注14) OpenStreetMap：http://www.openstreetmap.org/（アクセス：2011年10月21日）．

利用回数
55,066
339
70
21
668
1,976
284,638
1,976,487

5. まとめ本研究では，都市空間における効率的な動線解析の共通基盤のあり方について，動線解析プラットフ
ォームを構築し，共用性が高いと思われる処理関数
をWebAPIとして定義・実装を行い，パフォーマン
ステストを行い，実用上問題ないことを確認した．
今回は少ないサーバで実装していたが，今後，利用の増加，さらなる高速化に備えてサーバー側の分散化等を図っていくとともに，継続的にユーザーの利用状況等の分析も行ってみることとしたい．

参考文献

謝辞
本研究では，動線解析プラットフォームについては，初期の構築時点で国土技術政策総合研究所情報基盤
研究室にお世話になりました．また，東京都市圏パーソントリップデータについては，国土交通省のか
たがたにお世話になりました．この場を借りてお礼を申し上げます．また，本研究は，日本学術振興会
科学研究費若手研究（A）の補助を受けています．
ここに感謝の意を表します．

付録
注1) 人の流れプロジェクト ：http://pflow.csis.u-tokyo.ac.jp/（アクセス：2011年10月21日）．
注2) パーソントリップ調査：
http://www.mlit.go.jp/crd/tosiko/w_pt/index.html（アクセス：2011年10月21日）．
注3) プローブパーソン研究会：
http://www.probe-data.jp/（アクセス：2011年10月21日）．
注 4) Department for Transportation, UK.：The Use of GPS to
Improve Travel Data., 2003.
http://www.dft.gov.uk/rmd/project.asp?intProjectID=10883（アクセス：2011 年 10 月 21 日）．
注 5) Ram M. Pendyala.：Measuring Day-to-Day Variability
in Travel Behavior Using GPS Data., 2003.
http://www.fhwa.dot.gov/ohim/gps/index.html（アクセス：2011 年 10 月 21 日）．
注6) ビデオリサーチ社の屋外メディア総合調査(SOTO)：
http://www.videor.co.jp/service/oohmedia/soto.htm（アクセス：2011年10月21日）．
注7) 新宿区における帰宅困難者対策報告書：
http://www.city.shinjuku.tokyo.jp/bousai/kitakusien/kitaku.ht
ml（アクセス：2011年10月21日）．
注8) 低炭素都市づくりガイドライン（案）
http://www.mlit.go.jp/crd/city_plan/teitanso.html（アクセス：2011年10月21日）．

I_179

1) 国土交通省都市・地域整備局都市計画課都市交通調査
室：都市圏 PT 調査の経緯・実績と今後の課題，交通工学，Vol.37，No.2，pp.21-26，2002.
2) 中村，兵頭，山村，紺屋：JICA 都市交通開発調査デー
タベースの紹介－世界 11 都市のパーソントリップデー
タ－，交通工学，Vol.39，増刊号，pp.39-43，2004.
3) 交通／OOH 活用パーフェクトガイド，宣伝会議，2007
年 1 月 25 日号別冊，宣伝会議，2007.
4) JR 東日本企画：移動者マーケティング動く標的（消費編），宣伝会議，2000.
5) 島崎康信，関本義秀，柴崎亮介，秋山祐樹：人の流れによる時間帯別人口と店舗数との相関関係についての研究，都市計画学会都市計画論文集，Vol.44，No.3，
pp.781-786，2009.
6) Ohkusa Y., & Sunagawa, T.：Application of an individualbased model with real data for transportaation mode andlocation to pandemic influenza, Jounal of Infect Chemother,Vol.13, 380-389, 2007.
7) 江島啓介，鈴木秀幸，合原一幸：東京都市圏パーソン
トリップ調査データに基づく新型インフルエンザ感染
伝播の数理モデリング，運輸と経済，Vol.70，No.1，
54-62， 2010.
8) 羽藤英二：「交通を測る新技術 ヒト，モノ，環境」 第4 回 人の行動を測るプローブ調査の実施と展望，交通工学，Vol.39(2)，pp.85-91，2004.
9) 牧村和彦：高度情報機器を用いた歩行者行動モニタリ
ングと移動支援，交通工学，Vol.35，No.4，pp.40-45，
2000.
10) 内田敬：人を対象とする位置特定ベース情報サービスの動向と交通工学への応用可能性，交通工学，Vol.39，
No.6，pp.31-38， 2004.
11) 今井龍一, 井星雄貴, 濱田俊一, 中村俊之, 牧村和彦：動線データを用いたバス走行改善の検討支援に関する研究，土木計画学研究・講演集，Vol.43，2011.
12) 嶋田実：米欧における交通渋滞予測のための携帯プローブ利用の動き，KDDI 総研 R&A，2006 年 9 月第 1 号，
2006.
13) 八木浩一：広域災害時の交通状況監視を目的とした 4帯電話基地局情報の解析手法の開発，第５回 ITS シン
ポジウム 2006，2006.
14) Ratti, C., et al：Mobile Landscapes: using location datafrom cell phones for urban analysis, Environment andPlanning B: Planning and Design, Vol. 33, No. 5, pp.727748, 2006.

土木学会論文集F3（土木情報学）, Vol. 67, No. 2, I_170-I_180, 2011.
付録表-1 道路の経路選択時に用いた道路種別，移動手段ごとの移動速度
道路種別

道路種別コ
ード

徒歩

自転車

移動速度（時速：単位km）※ただし，-1は利用しないことを示す．
原動機付
自転車

自動二輪
タクシー

乗用車

軽乗用車

貨物
自動車

自家用
バス

路線バス

都市間高速

1

-1

-1

-1

80

100

100

100

90

90

都市高速

2

-1

-1

-1

60

70

70

70

60

60

国道

3

6

10

30

50

50

50

50

50

50

主要地方道

4

6

10

30

40

45

45

45

45

45

主要市道

5

6

10

30

40

45

45

45

45

45

県道

6

6

10

30

40

40

40

40

40

40

市道

7

6

10

30

30

30

30

30

30

30

街路

8

6

10

30

30

30

30

30

30

30

その他

9

6

10

30

30

30

30

30

30

30

15) Horanont, T., & Shibasaki, R. ： An Implementation of
Mobile Sensing for Large-Scale Urban Monitoring,
Proceedings of the International Workshop on Urban,
Community, and Social Applications of Networked Sensing
Systems (UrbanSense 2008), 2008．
16) 関本義秀，Horanont, T., 柴崎亮介：＜解説＞携帯電話を活用した人々の流動解析技術の潮流，情報処理，
Vol.52, No.12, pp.1522-1530, Dec. 2011．
17) Yoshihide Sekimoto, Ryosuke Shibasaki, Hiroshi Kanasugi,
Tomotaka Usui and Yasunobu Shimazaki, PFLOW:
Reconstruction of people flow recycling large-scale social
survey data, IEEE Pervasive Computing, Vol.10, No.4,
pp.27-35, Oct.-Dec. 2011.

18) Wolfson, O., Sistla, A.P., Xu, B., Zhou, J., Chamberlain, S.
(1999). DOMINO: databases for moving objects tracking.
Proceedings of ACM Symposium on the Management of Data
(SIGMOD), Philadelphia, pp. 547-549.
19) 小島英史，羽藤英二：プローブパーソンデータによるオンラインマッチングアルゴリズム，土木計画学研究
発表会・講演集，Vol.29 (CD-ROM)，2004.
20) 三輪富生，木内大介，山本俊行，薄井智貴，森川高
行：低コストプローブカーデータのオンラインマップ
マ ッ チ ン グ 手 法 の 開発 ， 交通 工 学 ， Vol.44 ， No.3 ，pp.100-110，2009．
(2011. 10. 21 受付)

STUDY OF INFORMATION PLATFORM
FOR PEOPLE FLOW ANALYSIS IN URBAN AREA
Yoshihide SEKIMOTO, Tomotaka USUI, Hiroshi KANASUGIand Yusuke MASUDA
This study considers an information platform for people flow analysis in urban area. The platform,
which can keep a certain quality of location data of many people even in the buisuiness operation scene,
aims at an acceleration of person traffic investigation or real-time monitoring, by the reduction of dataprocessing loads which have been done in various urban managers.
Concretely we design WebAPI for web service supporting various kinds of analysis such as map
matching or spatio-temporal interpolation etc. for people flow, after arrangement of the needs of location
data of people in a public and private field, and the seeds such as existing technologies and problems.
Actually we implement the platform which can process the data effectively, and measure the performanceof each WebAPI function, and analyse application status of registered users.

I_180