\documentclass[a4j,11pt]{jbook}
\usepackage{graphicx}
\usepackage{url}
\usepackage{ascmac}
\thispagestyle{empty}
\addtolength{\topmargin}{-2cm}
\addtolength{\textheight}{3cm}
\addtolength{\textwidth}{1cm}
\addtolength{\oddsidemargin}{0.5cm}
\addtolength{\evensidemargin}{-0.5cm}
\usepackage{ulem,color,graphicx,eclbkbox}
\usepackage{multicol}
\begin{document}
\title{非同期通信を利用したWeb上のマップ描画による\\情報共有システムの設
計}
\author{廣瀬研究室 4年 c1151073 鈴木光明}
\date{平成30年1月15日}
\maketitle
\begin{center}
% \fontsize{11pt}{11pt}\selectfontd
{\bfseries 概要}
\end{center}
% \abstract{
近年、GPS内蔵型携帯電話等の位置情報を計測できる情報端末が広く普及して
いる。しかし、近年の熊本地震や北海道胆振地震をはじめと
する災害時の行方不明者や災害弱者の逃げ遅れの状況から見える通りその機能
が有効に活用されていないのが現状である。現在位置情
報を利用したガイドシステムは存在するが、利用者同士のコミュニケーショ
ンや情報共有が念頭に置かれていない場合が多い。また、従来災害時に用いら
れている伝言板等のシステムでは携帯電話とPCとの連携が取れず、避難時に災
害時の状況を確認できる手段がないことから避難者の立
場が考慮されていないことが問題視されている。\par
そこで、個人単位で位置情報を発信できる点に着目し、災害時における避難
者の位置情報の共有の簡易化を図るWebアプリケーションを構築する。また、外部か
らの匿名性を保持した上で、設定したグループ内における個人間での情報の相
互共有を可能にし、災害時に家族等の複数人のコミュニティ内で活用できるよ
うな機能も構築する。また、その機能を応用し、フィールドワーク等複数人の
位置情報を相互に確認したいような場面でも利用できるようなシステムを構築
する。(491文字)
\\
\thispagestyle{empty}
\tableofcontents
\chapter{目的・テーマ設定}
本研究の設定する目的とテーマ設定に至るまでの背景について記述する。
\section{テーマ設定の背景}
日本では近年に見られる熊本地震や北海道胆振東部地震をはじめとした、地震や大
雨による洪水等、 多数の被害者が出るような災害が頻繁に起こっている
\cite{kisho}。その中で
も高齢者をはじめとする災害弱者の逃げおくれによる被害が問題となっ
ている\cite{nige}。他にも、電話や交通等のライフラインが混雑するため避難
後の安否確認が困難になる\cite{life}。そこで近年では避難経路の確保や把握
等の日常的な活動を行うことが促進されている。しかし、事前の準備のみな
らず実際に災害時の状況に陥った際の対応策が必要であると考えた。
そこで、各自が持っている位置情報を発信できる情報端末を利用することで
被災地の人間の逃げ遅れの確認や、家族等複数人でのコミュニティ内での情報
の相互共有をする手段の必要性を感じた。\par
また、その他にも野外でのフィールドワークを複数人で行う際や集団のツアー
客の自由行動等、予め時間や集合場所を決めていたとしても集団の動向を一目
で把握できないのは不便な状況が存在する。宗森らによると
既存の位置情報を使ったガイドシステムでは、その場での交換やチャットなど、
利用者同士のコミュニケーションや情報共有は念頭に置かれていない場合が多
いとされている\cite{oni, xEx}。また、Apple StoreやGoogle
Playから配布されているアプリケーションの中にも、位置情報を不正に取得
している例が確認されている\cite{alert}。\par
さらに、Google Playでnekonotesoftから配信されている情報共有ソフト``いまど
こ?位置検索''等をはじめとした無料のアプリケーションでは共
有できる数に制限があったり全ての機能を利用するには有料であったりといっ
たケースが存在する。例として上述の``いまどこ?位置検索''では14日間の試用
期間では「自動測位機能」および「見守り機能」を利用することができず、また14日目
以降の利用にはライセンスの購入と月額料の支払いが必要になる\cite{imadoko}。\par
そこで、特別な外部のアカウントや電話番号等の登録情報を必要としない、 参
加者の状態を個人単位で制限なくリアルタイムで相互に把握することができる
アプリケーションが必要だと考えた。
\section{過去の類似研究の例}
\label{senko}
本研究では災害時に複数人の位置情報を取り扱うことに重点を置くため、過去の研究の中
から災害時の位置情報や複数人の位置情報を扱う取り組みが行われた文献につい
て記述する。\par
松崎らは、スマートホームシステムのホームサーバ \footnote{家庭内に存在する家電製品や防犯システム等を一律に制御するシステムである。ホームサーバとはその各種センサを制御されているサーバのことである。}
を利用して地震災害時における被災状況の確認や被災者の救助支援に応用するシ
ステムを提案している\cite{smart}。モバイル端末とホームサーバの通信に
よりユーザとホームサーバとの距離を観測することで、在宅情報から生き埋め等
の被災者を特定し、
救助要請マップを作成してシミュレーション実験を行い、研究の有効性
を示した。しかし、ここではホームサーバごとに管理しているため、人数に
誤差が出ることや使用する多数の機器に対し電力を供給し続けなければならない
ことが問題となっている。\par
また、複数人の位置情報を用いた遠隔地での情報共有に関して、宗森らはPDA(携
帯情報端末)とGPSと携帯電話を使用
し、位置情報を用いて遠隔地間で行う鬼ごっこをはじめ複数種の電子鬼ごっこの
実験を行っている\cite{oni}。位置情報を変換することで離れた場所でも問題なく
電子鬼ごっこを行い、実験の結果では位置情報を柔軟に扱ったサービスが受け入
れられている。
\chapter{提案}
現状抱えている問題点を踏まえて、本研究で提案するシステムについて記述する。
\section{現状}
災害時等を想定した際の離れている人同士の安否確認等の情報の相互確認につ
いての現状を記述する。
\subsection{災害時の逃げ遅れによる被害}
渡邊らは、災害時に住民の孤立や逃げ遅れの二次災害による犠牲者の発生を問題
とし、最短避難経路提示システムを開発した\cite{mobile}。そこでは、従来の
災害時の伝言板等のシステムでは携帯電話とPCとの連携がとれず、避難者の立場
が考慮されていないことが問題視されていた。そこで、避難所や交差点にIDと
グループ番号を付加することで、携帯電話を活用し最短の避難経路に誘導するシ
ステムを実現した。また、GPS内蔵型携帯電話が使用できない状況ではWi-Fi付
きノートPCを用い、Google社からWi-FiのアクセスポイントとIPアドレスを基に
測位された現在地を利用することで実測値との誤差を5\%以下で実現した。ここ
から、災害時であっても正確に位置情報を発信・共有可能であることが示され
ている。
\subsection{避難後の安否確認}
能島によると2016年の熊本地震におけるライフラインの復旧に関して、阪神淡路大
震災や東日本大震災と比べ大幅に短縮され、迅速さにおいてはほぼ飽和状態に達
していると述べられている\cite{life}。しかし、ライフラインの完全な復旧には2週
間を要しているのが現状であり、その間は十分に外部との連絡を取れない人がい
るのが事実である。
\subsection{既存のアプリケーション}
\label{apli}
現在、Apple社が提供するクラウドサービス``iCloud''の機能である``友だちを探
す''やGoogleが提供している地図・ローカル検索サービス``Googleマップ''の機能
である``現在地を共有''等の位置情報の共有を目的としたアプリケーションが
存在する。しかし、これらのアプリケーションは利用する度に共有相手の設定
や時間の指定等の設定の変更が必要になる。また、個人間の共有を目的にしてい
るため、複数人のグループ等で共有をする際はグループ内の全員がお互いに個
人間の設定をする必要がある。そのため、人数が増えるほ
ど必要な設定数が増えていくことになる。具体的には、既存のシステムでは複
数人と情報共有する際に利用者全員が自分以外の利用者全員と設定する必要が
あるため、
利用者の数を$n$としたときに$n * (n -1)$回の設定が必要になる。それに対して、
本システムでは複数人で情報共有をする際、予め作成したグループに利用者が
それぞれ加入する設定を行うのみなため、利用者の数を$n$としたときに$n$回
の設定が必要になる。
実際の数値で考えたときの既存のシステムと本システムの差は表\ref{system}
のようになる。\par
また、これらのアプリケーションではお互いにiCloudやGoogleアカウント等の
外部の登録が必要な固有アカウントを把握している利用者の情報しか得るこ
とができないため、情報の共有に制限がある。
% \begin{figure}[h]
% \begin{center}
% \includegraphics[bb=32 19 829 565,scale=0.3]{kizon.pdf}
% \caption{既存のアプリケーション}
% \label{kizon}
% \end{center}
% \end{figure}
\section{提案するシステム}
そこで、本研究では上述の問題点を踏まえて以下のような機能を導入したシステ
ムを提案する。
\begin{enumerate}
\item システム利用者の位置情報を把握できる機能\par
本システムの根本的な機能として、利用者がシステムに送信した位置
情報のデータをブラウザ上のマッ
プにユーザの設定する分単位で更新して表示する。
\item 一定範囲の地域内の分布を表示するマップ作成アプリケーション\par
災害時に利用者の避難状況を把握できるようにするため、設定した地
域内の利用者の分布をブラウザ上のマップに表示する。ここでは個人
は特定せず、あくまで分布のみの表示とする。
\item 個別アカウントによるグループ管理\par
利用者個人を判別するためのアカウントを用いて、複数人単位で相互
の情報管理を可能にする。既存のアプリケーションにおける問題点を
踏まえ、複数人での共有を簡潔な作業で行えるようにする。
\item 複数人グループで情報共有する利用者のマップ作成アプリケーション
\par
上記の複数人グループ内で、個人を判別した上で位置情報を相互に設
定した数分単位で更新・管理できるマップをブラウザ上で実現する。
\end{enumerate}
\begin{table}[h]
\begin{center}
\caption{システム利用時に必要な設定数の差}
\begin{tabular}{|c|c|c|}\hline
利用人数&既存のシステム &本システム \\\hline
2 & 2回 & 2回 \\\hline
3 & 6回 & 3回 \\\hline
4 & 12回 & 4回 \\\hline
n & n(n-1)回 & n回 \\\hline
\end{tabular}
\label{system}
\end{center}
\end{table}
\chapter{システムに必要な情報と構築環境}
本研究で開発するシステムに必要なデータと構築環境について記述する。
\section{必要なデータの考察}
本システムを設計するにあたり必要なデータについて考察する。
\subsection{ベースシステムにおける必要最低限のデータ}
本システムの設計において、前段階としてWeb上のマップ描画における位置情報の共有
のみを目的としたシステムを考える。必要なデータは以下の通りである。
\begin{itemize}
\item ユーザ名\par
個人を特定するために必要な固有のユーザ名が必要になる。
\item グループ情報\par
本システムにおける複数人で情報を共有する機能を利用する
際に、共有するユーザ間に共通の情報を付与する必要がある。そこで、
本システムではグループという括りの情報を付与し、共通のグループに
所属するユーザ間で情報を共有する形式を取る。そのため、
グループの作成等の設定に関する情報が必要になる。
\item 位置情報\par
Web上のマップにユーザの位置を表示するために必要になる。
\end{itemize}
ここから本システムを設計していく上で必要なデータを考察しながら追加していく。
\subsubsection{クッキーID}
\label{cookie}
Cookieとは、ユーザ側に各種情報を保持させるためにサーバから送られ、ユー
ザの端末に保存されるファイルである。
本システムはWeb上の複数ページを跨いで利用するため、ページを移動した際
にもユーザの情報を引き継ぐ必要がある。また、一度本システムにログインし
たユーザが本システムから別のページに移動した後もログイン状態を保持する
形式にする。そこで、本システムにログインした際にユーザの端末毎に固有の
IDを設定しCookieに保存し、クッキーIDというデータとして扱う。
\subsubsection{パスワード}
本システムを利用する際、先述の通りCookieを取得していれば本人の認
証を維持す
ることは可能である。しかし、利用端末の故障等の理由から別の端末に変更し
た際や複数端末からの利用をする際にCookieを引き継ぐことができない。
そのため、 本システムのクッキーIDとは別に情報を引き継ぐための個別の値
が必要になる。
そこで、クッキーIDとは別にユーザごとのパスワードをユーザ
を認識するための情報として設定する。
\subsubsection{グループマスタ}
複数人数でのグループで情報を共有する際、本システムでは情報の更新頻度等
の設定は個別で行う。しかし、この機能では位置情報とともにユーザ名も表示
するため、作成したグループに全てのユーザが自由に加入できる設定にすると、
他ユーザの名前と位置情報を自由に取得できることになり、
プライバシやセキュリティ面の安全性に欠ける。そこで、ユーザの中にグルー
プマスタという役職を割り当て、グループへの参加承認等に関する権限を付与
する必要がある。
\subsubsection{最終利用時刻}
本システムはWeb上のマップ描画によるリアルタイムな情報共有を目的として
いる。ユーザ名と位置情報のみの表示ではマップに表示される他のユーザがい
つ情報を送信したかを知る手段がないためリアルタイムに情報を更新する利点
が失われる。そこで、本システムでユーザが情報を
送信する際に利用した時刻も送信し、閲覧できるようにする必要がある。
\subsubsection{地域名}
\label{chiiki}
本システムでは災害時のユーザの避難分布を表示する。その際、全ユーザの情
報を表示すると範囲が広く、表示されるマーカの数も多くなるため、1画面で確
認するマップの視認性が著しく低下する。そこで、一定範囲ごとの地域を設定し、
設定した地域内の利用者の分布を表示する。現段階では市町村を
単位としているが、人口等を考慮しさらに明確な条件のもと範囲の単位を設定す
る必要がある(図\ref{yamagata})。
\begin{figure}[h]
\begin{center}
\includegraphics[bb=0 0 1169 494,scale=0.3]{yamagata.pdf}
\caption{全ユーザの情報表示時の例}
\label{yamagata}
\end{center}
\end{figure}
\subsection{本システムに実装するデータ}
上記の点を踏まえて、本システムでは以下のデータをユーザの端末から取得し、管理
する。
\begin{itemize}
\item ユーザ名
\item パスワード
\item クッキーID
\item 位置情報
\item グループ加入情報
\item グループ編集権限情報
\item 利用時刻
\item 地域名
\end{itemize}
\section{データの正規化}
本システムは関係データベース(RDBMS)でデータを管理するため、データを正
規化する必
要がある。正規化とは、データを効率良く扱うために特定のルールにしたがっ
て整理することである。\par
例として、本システムで利用するデータの一部をまとめた表\ref{nama}があ
る。この状態では任意のデータを抽出したり参照したりする際に一度に複数のデータ
が当てはまるため効率的ではない。また、一つのデータを修正するために複数
の箇所を変更する必要があり手間がかかる場合がある。そこで、本研究ではプ
ログラムからデータの参照や抽出を行うため第3正規化まで行う。\par
以下に本システムで利用したデータの正規化の手順について記述する。
\begin{table}[h]
\begin{center}
\caption{生のデータ}
\label{nama}
\begin{tabular}{|c|c|c|l|}\hline
太朗 & hogehoge & 鶴岡 & Aグループ38.4, 138.5 12:00 Bグループ38.6,
138.1 13:00\\\hline
花子 & gehogeho & 酒田 & Aグループ38,1, 138.1 13:05\\\hline
鈴木 & pasuwa-do & 鶴岡 & Bグループ38.5, 138.5 14:30\\\hline
\end{tabular}
\end{center}
\end{table}
\subsubsection{非正規形}
表\ref{nama}のように整理されていない生の状態のデータのことを非正規形
という。データベースで
データを管理する際、このように一つの項目(フィールド)内に複数のデータが
格納されていても複数のデータと認識することはできない。これらのデータを
関連性を失わないようにデータベースが計算機で処理しやすい形式にするこ
とが正規化である。\par
\subsubsection{第1正規化}
非正規形において繰り返しや、一つのフィールド内に複数格納され
ているデータを別の行(レコード)に分離し、繰り返しを排除する。\par
\begin{table}[h]
\begin{center}
\caption{繰り返しを排除した形}
\begin{tabular}{|c|c|c|c|c|c|c|}\hline
name & pass & group & local & lat & lng & time\\\hline
太朗 & hogehoge & Aグループ & 鶴岡 & 38.4 & 138.5 & 12:00\\\hline
太朗 & hogehoge & Bグループ & 鶴岡 & 38.6 & 138.1 & 13:00\\\hline
花子 & gehogeho & Bグループ & 酒田 & 38.1 & 138.1 & 13:05\\\hline
鈴木 & pasuwa-do & Bグループ & 鶴岡 & 38.5 & 138.5 & 14:30\\\hline
\end{tabular}
\label{kuri}
\end{center}
\end{table}
さらに、テーブルごとにデータを一意に識別するための項目を設定する。このよ
うな列(カラム)のことを主キーと呼ぶ。主キーは複数カラムから構成されることも
あり、その場合は複合主キーと呼ぶ。今回はnameとgroupが決まれば他のデー
タが一意に決定するためこの二つを複合主キーとする。\par
\subsubsection{第2正規化}
表3.2の第1正規形から部分関数従属性を排除する。関数従属とは、あ
る属性Xを決めると他の属性Yが一意に決まるような状態のことである。この時、
Xを決定項、Yを被決定項と呼ぶ。部分関数従属とは、このときの被決定項が複数
の決定項を持っている状態のことである。表3.2の場合、nameが決ま
ればpassが決まるが、他の項目が必ずしも決定しない。そこで、たとえばname
を主キーとする passだけをまとめたテーブルを新規に作成する。このように
第2正規化をする
ことでテーブルごとの列の数を減らし、データの管理をより単純化する。
\begin{table}[h]
\begin{center}
\caption{パスワードテーブル}
\begin{tabular}{|c|c|}\hline
name & pass \\\hline
太朗 & hogehoge \\\hline
花子 & gehogeho \\\hline
鈴木 & pasuwa-do \\\hline
\end{tabular}
\end{center}
\end{table}
\begin{table}[h]
\begin{center}
\caption{地方テーブル}
\begin{tabular}{|c|c|}\hline
name & local \\\hline
太朗 & 鶴岡 \\\hline
花子 & 酒田 \\\hline
鈴木 & 鶴岡 \\\hline
\end{tabular}
\end{center}
\end{table}
\begin{table}[h]
\begin{center}
\caption{ユーザ情報テーブル}
\begin{tabular}{|c|c|c|c|c|}\hline
name & group & lat & lng & time\\\hline
太朗 & Aグループ & 38.4 & 138.5 & 12:00\\\hline
太朗 & Bグループ & 38.6 & 138.1 & 13:00\\\hline
花子& Bグループ & 38.1 & 138.1 & 13:05\\\hline
鈴木 & Aグループ & 38.5 & 138.5 & 14:30\\\hline
\end{tabular}
\label{daini}
\end{center}
\end{table}
\subsubsection{第3正規化}
第2正規形から推移的関数従属性を排除する。推移的関数従属性とは、被決定
項または決定項と被決定項の組み合わせによって他の被決定項が一意に決ま
ることを指す。今回の場合、表\ref{daini}において、nameとgroupが決まれ
ばその他のデータが決まるため、別のテーブルを新たに作成する。検索の効
率を考慮して部分的に正規化の程度を敢えて落とした状態のままにする場合
もある。最終的には表3.6, 3.7, 3.8, 3.9の状態になる。
\begin{table}[p]
\begin{center}
\caption{パスワードテーブル}
\begin{tabular}{|c|c|}\hline
name & pass \\\hline
太朗 & hogehoge \\\hline
花子 & gehogeho \\\hline
鈴木 & pasuwa-do\\ \hline
\end{tabular}
\end{center}
\end{table}
\begin{table}[h]
\begin{center}
\caption{地方テーブル}
\begin{tabular}{|c|c|}\hline
name & local \\\hline
太朗 & 鶴岡 \\\hline
花子 & 酒田 \\\hline
鈴木 & 鶴岡 \\\hline
\end{tabular}
\end{center}
\end{table}
\begin{table}[h]
\begin{center}
\caption{位置情報テーブル}
\begin{tabular}{|c|c|c|c|}\hline
name & group & lat & lng \\\hline
太朗 & Aグループ & 38.4 & 138.5 \\\hline
太朗 & Bグループ & 38.6 & 138.1 \\\hline
花子& Bグループ & 38.1 & 138.1 \\\hline
鈴木 & Aグループ & 38.5 & 138.5 \\\hline
\end{tabular}
\end{center}
\end{table}
\begin{table}[h]
\begin{center}
\caption{利用時刻テーブル}
\begin{tabular}{|c|c|c|}\hline
name & group & time\\\hline
太朗 & Aグループ & 12:00\\\hline
太朗 & Bグループ & 13:00\\\hline
花子& Bグループ & 13:05\\\hline
鈴木 & Aグループ & 14:30\\\hline
\end{tabular}
\label{daini}
\end{center}
\end{table}
\section{作業環境}
開発は以下の環境で行う。
\begin{itemize}
\item Ruby 2.3.0
\item Leaflet.js 1.3.4
\item SQLite3
\end{itemize}
\chapter{システムの設計}
本システムの設計について記述する。
\section{本システムの概観}
本システムを利用する際の流れは以下の通りである。
\begin{enumerate}
\item アカウントの作成・ログイン\par
本システムを利用するための情報を入力しアカウントを作成し、ログイ
ンする。
\item グループの作成・加入・選択\par
指定したユーザ同士で構成されるグループ周辺の設定をする。
\item 利用端末から情報を送信・取得\par
ユーザ自身の位置情報・利用時間等の情報をRDBMSに送信すると同時に最
新の情報を取得する。
\item 取得したデータが反映されたマップの閲覧\par
取得したデータを元に目的に応じて作成されたマップを閲覧する。
\end{enumerate}
なお、目的がユーザ自身の情報の更新に限る場合グループを選択する必要はなく、自身
の情報のみを更新する機能を利用することができる。システム全体の概念図は
図\ref{gai}の通りである。
\begin{figure}[h]
\begin{center}
\includegraphics[bb=33 37 810 542,scale=0.5]{gainen.pdf}
\caption{システム利用時の概念図}
\label{gai}
\end{center}
\end{figure}
% \section{個別アカウントの管理}
% 本システムを利用するために必要なアカウント周辺について記述する。
% \subsection{アカウントの制約に関して}
\section{個別アカウントの管理}
本システムはアカウント作成の際にユーザ名とパスワードと地域のみを設定
する設計で、メイルアドレス等の外部のデータを必要としない。そのため、ユー
ザ名を個人を判別するためのユニークキーとする。
% \subsection{アカウントの認証期限に関して}
% 本システムでは後述のAjaxによる非同期通信を行う以外に、複数ページを経由
% したり、システムから離れたりした際にもある程度の間ログイン情報を保持す
% る必要がある。そこで、\ref{cookie}で説明したクッキーIDを利用することで
% ログイン情報を保持する。セ
% キュリティ上の問題を踏まえて、永久に保持するのではなく情報は24時間で破
% 棄する。
\section{JavaScriptを用いた動的なWebの作成}
本システムでは主にJavaScriptを用いて動的なWebページを作成する。
\subsection{用語解説}
本章の話をするにあたって必要な用語の解説を記述する。
\subsubsection{JSON}
JavaScript Object Notation(JSON)とは、表形式では記述が困
難なデータを人間に対しての可読性を残しつつ計算機に対して伝達する記法
である。一般的にWebアプリケーションでデータを送信する際に使用さ
れる。以下に本システムで使うデータを用いたJSON形式の例を記述する。
\begin{itembox}[l]{JSON形式の例}
\begin{verbatim}
[
{
"名前": "mituyuki",
"緯度": "138",
"経度": "38",
"時間": "2018-12-28 15:49",
"group" : [
"Agroup",
"Bgroup"
]
}
]
\end{verbatim}
\end{itembox}
\subsubsection{GeoJSON}
GeoJSONとは、JSONを用いて位置情報等の空間データをエンコードしたファイ
ル形式である。GeoJSON形式ではジオメトリ(形状)、フィーチャー(地物)、フィー
チャーコレクション(フィーチャーの集合)の3つのオブジェクトによって固有
の値がそれぞれ決まっている。それぞれのオブジェクトの説明を記述する。
\begin{itemize}
\item フィーチャーコレクションオブジェクト\par
featuresという名前のキーが必要である。valueはフィーチャーオブジェク
トを要素とする配列である。
\item フィーチャーオブジェクト\par
geometryというジオメトリオブジェクトをvalueとするkeyと、
propertiesという任意
のJSONオブジェクトをvalueとするkeyが必須である。
\item ジオメトリオブジェクト\par
位置やマーカの種類等の構成を設定する要素を記述するオブジェクトで
ある。
\end{itemize}
以下にGeoJSON形式の例を記述する。
\begin{itembox}[l]{GeoJSON形式の例}
\begin{verbatim}
[
{
"type": "FeatureCollection",
"features": [
{
"type": "Feature",
"properties": {
"name": "mituyuki",
"description": "あなたとの距離:300m"
},
"geometry": {
"type": "Point",
"coordinates": [
138,
38
]
}
}
]
}
]
\end{verbatim}
\end{itembox}
\subsubsection{OpenStreetMap}
OpenStreetMap(OSM)\footnote{https://www.openstreetmap.org}とは、道路地図等
の地理情報データを誰でも自由に参加・
編集・利用できるようにし、フリーの地理情報データを作成することを目的
にしたプロジェクトである。
\begin{figure}[h]
\begin{center}
\includegraphics[bb=0 0 1289 618,scale=0.3]{OSM.pdf}
\caption{OSMの地図表示例}
\end{center}
\end{figure}
\subsubsection{Ajax}
Asynchronous JavaScript + XML(Ajax)とは、JavaScriptとXMLを使って非同期
にサーバとの通信を行い反映させることである。非同期な通信とは、Webブラ
ウザからサーバに情報を送信する際に、一部の情報のみを送信することでサー
バからのレスポンスを待たずに他の処理を行うことができる形式の通信のこと
である。反対にサーバに
情報を送信する際に全てのデータを送信し、サーバからのレスポンスがあるま
でページ内で他の作業が行えない形式の通信を同期通信という。
\subsection{Leaflet.jsを用いたマップ作成}
Leaflet.jsとはWeb上で地図を作成・表示するためのオープンソースの
JavaScriptライブラリである。GeoJSONからデータを読み込み、ポップアップ
等の機能を利用したマップを作成することができる。本システムではこれを用
いてOSMの地図をベースにしたマップを作成する。
\subsection{Ajaxによる非同期通信}
本システムでは利用時にページ内の全ての情報を更新する必要はないため、一部の
情報のみを送受信する設計とする。
また、ユーザが情報
を送受信する間にも同ページ内のマップを閲覧する等の他の作業をできるよう
にする必要がある。特に、同期通信を行うと情報を送受信する度にマップが更
新されるため、ユーザがスムーズにマップを閲覧することができない。
そこで、非同期通信を用
いて更新する必要がある情報のみをサーバにリクエストする。本システムでは以下
のような流れで利用している。
\begin{enumerate}
\item ユーザ自身の位置情報を送信する。
\item CGIでSQL文を実行し、データベースからその時の利用者に必要なデー
タをJSON形式で返す。
\item 受け取ったデータを基にユーザの設定したグループを判別し、同グ
ループのユーザの位置情報と時間を表示するマップを作成する。
\end{enumerate}
実際に本システム内でAjax通信を用いた部分のプログラムを用いて例示する。
\par
データの送信部分のコードは以下の通りである。
\begin{itembox}[l]{送信部分のJavaScript}
\begin{verbatim}
function submit() {
var conn = new XMLHttpRequest();
conn.open('POST', './getgps.cgi');
conn.setRequestHeader(
'Content-Type', 'application/x-www-form-urlencoded');
conn.send('gname='+encodeURIComponent(gname.value)+'&'+'name='+
encodeURIComponent(name.value)+'&'+'lat='+encodeURIComponent(lat)
+'&'+'lng='+encodeURIComponent(lng));
conn.onreadystatechange = respond;
}
\end{verbatim}
\end{itembox}
送信時の動作の流れは以下の通りである。
\begin{enumerate}
\item サーバに通信リクエストを送るため、XMLHttpRequest(XHR)オブジェクトを生
成
\item サーバに情報を登録するためアクセスメソッドはPOSTを選択し、パスを
指定
\item XHRのメソッドのsetRequestHeaderで送信ヘッダを設定
\item データの変数名と値を記述し送信
\item XHRのメソッドのonreadystatechangeをrespondという関数に代入
\end{enumerate}
アクセス先では送られたデータを基にSQL文を実行し、必要なデータをJSON形式
で返す。
データ受信部分のコードは以下の通りである。
\begin{itembox}[l]{受信部分のJavaScript}
\begin{verbatim}
function respond(str) {
if (this.readyState == 4) {
var resp = JSON.parse(this.responseText);
var MyName = resp['名前']; // 自分の名前
var NameData = resp['namedata']; // DBの名前一覧
var LatData = resp['latdata']; // DBのLat一覧
var LngData = resp['lngdata']; // DBのLng一覧
var LaLn = [parseFloat(LatData[0]), parseFloat(LngData[0])];
}
}
\end{verbatim}
\end{itembox}
送信時の動作の流れは以下の通りである。
\begin{enumerate}
\item readyStateが4(XMR通信完了後)の時にif文を実行
\item JSON形式の文字列を取得
\item それぞれの変数に代入
\end{enumerate}
また、この時に受信したデータを基にプログラムを実行しマップを作成する。
\begin{verbatim}
\end{verbatim}
\begin{figure}[h]
\begin{center}
\includegraphics[bb=70 69 808 508,scale=0.25]{ajax.pdf}
\caption{本システムでの非同期通信の例}
\end{center}
\end{figure}
\section{RDBMSによるデータ管理}
前章で延べた通り本システムではRDBMSで各データを管理する。そこからCGIより
SQL文を実行することで必要なデータを取り出す。\par
本システムでは前章の例に挙げたデータの他にグループのマスタ、クッキーIDのデー
タを加えて正規化を行った以下のテーブルでデータを管理する。
\begin{itemize}
\label{table}
\item ユーザ情報 user(ユーザ名, パスワード)
\item 設定地域情報 local(ユーザ名, 設定した地域)
\item クッキーID情報 cookie(クッキーID, ユーザ名, 最終ログイン時刻)
\item 利用時刻情報 lasttime(ユーザ名, グループ名, 最終利用時刻)
\item 位置情報 latlng(ユーザ名, 取得した経度, 取得した緯度)
\item グループ情報 ginfo(グループ名, マスタ名)
\item グループ加入状況 gmember(ユーザ名, グループ名)
\end{itemize}
ここではデータ内容の説明をするため分かりやすいカラム名で表記し
た。実際のカラム名は表\ref{caram}の通りである。
\begin{table}[h]
\begin{center}
\caption{ \ref{table}のカラム名と実際のカラム名の対応表}
\label{caram}
\begin{tabular}{|c|c|}\hline
ユーザ名 & user\\\hline
パスワード & pass \\\hline
設定した地域 & local\\\hline
クッキーID & cookie \\\hline
グループ名 & group\\\hline
最終ログイン時刻& login \\\hline
最終利用時刻 & time\\\hline
取得した経度& lat \\\hline
取得した緯度& lng \\\hline
マスタ名& master \\\hline
\end{tabular}
\end{center}
\end{table}
\subsection{本システムのER図と解説}
本システムで扱うデータのER図は図\ref{ER}の通りである。以下にそれぞれの
テーブルの関係について解説する。
\subsubsection{userテーブルとlocalテーブル}
本システムではアカウント作成の際に名前とパスワードと地域を設定する。
地域の設定は\ref{chiiki}で記述した通り市町村単位で選択する。
地域の設定は1アカウントに一つであり作成時に必ず設定するため1対1の関係
である。
\subsubsection{userテーブルとcookieテーブル}
本システムではログイン時にユーザごとのcookieを作成する。アカウ
ントを作成し
たのみの状態や、一定時間が経過しcookieが削除された状態ではcookieは存
在しないため、1対0または1の関係である。
\subsubsection{userテーブルとlasttimeテーブル}
本システムのいずれかの情報共有の機能を利用し、情報を送信した際にユー
ザごとの最終利用時刻をデータベースに登録する。アカウントを登録したの
みで情報共有の機能を利用していない際はtimeのデータは存在しないため、1
対0または1の関係である。
\subsubsection{userテーブルとlatlngテーブル}
上述のlasttimeテーブルと同様に、アカウントを登録したの
みで情報共有の機能を利用していない際はlatとlngのデータは存在しないため、1
対0または1の関係である。
\subsubsection{userテーブルとgmemberテーブル}
ユーザが複数人グループの情報共有機能を利用する際にグループへの登録が
必要になる。同時に複数のグループに加入することが可能であり、またグルー
プに全く加入していないユーザも存在するため、1対多の関係である。
\subsubsection{gmemberとginfo}
一つのグループには一人以上のマスタが存在し、マスタのいるグループには
一人以上のメンバーが所属しているため、多対多の関係である。
\begin{figure}[h]
\begin{center}
\includegraphics[bb=0 0 398 436,scale=0.8]{ER3.pdf}
\caption{本システムで扱うデータのER図}
\label{ER}
\end{center}
\end{figure}
\chapter{システムの実行}
実際に構築したシステムを利用する際の動作とその時のシステムの動きについて
記述する。利用時の流れは図\ref{sys}のようになる。
\begin{verbatim}
\end{verbatim}
\begin{figure}[h]
\begin{center}
\includegraphics[bb=30 69 561 795,scale=0.5]{system.pdf}
\caption{システム利用時の流れ}
\label{sys}
\end{center}
\end{figure}
\section{個人アカウントの管理}
本システムを利用する際、利用者を特定するための個人アカウント周辺
の機能に関して記述する。
\subsection{個人アカウント作成}
ユーザ名とパスワードと地域の情報を設定し、利用者個人を判別するためのア
カウントを作成する機能である。アカウント作成時にはユーザ名、パスワード、
地域の3項目を入力する。ユーザ名を個人を判別するためのデータ
とするため、ユーザ名が既存のアカウントと重複していた際にはエラーを表示す
る。
\begin{figure}[h]
\begin{center}
\includegraphics[bb=0 0 477 229,scale=0.9]{make.pdf}
\caption{ログイン画面}
\end{center}
\end{figure}
\subsection{ログイン}
作成したアカウントのユーザ名とパスワードを入力し、システムにログインす
るための機能である。ユーザのログイン情報を保持するため、ログインと同時
にクッキーIDを取得する。クッキーIDの有効期限は24時間に設定している。
\section{位置情報を利用した情報共有}
本システムのメインとなる機能である。利用者が意図的に情報を送信したり、
送信情報をマップ上に表示して共有したりする機能と、そこで得た情報を元に地域ご
とに利用者の分布を表示する機能の大きく2つに分かれる。
\subsection{個人の位置情報の送信}
\label{kozin}
本システムにログイン中のユーザが自分の利用情報をデータベース
に送信する機能である。ここで得たデータを基に後述の地域ごとの分布マップ
を作成する(\ref{bunpu})。
% \begin{figure}[h]
% \begin{center}
% \includegraphics[bb=36 39 814 559,scale=0.4]{gainen1.pdf}
% \caption{個人利用時の概念図}
% \end{center}
% \end{figure}
\subsection{複数人グループでの利用}
\label{shounin}
複数人単位のグループ内で個人を特定した上で相互に情報を共有するシ
ステムである。特に、災害時に家族等複数人のコミュニティ内でお互いの情報を把握
するための機能である。この機能は、災害時のみならず、グループワーク等複数人の位
置情報を相互に把握したい状況で利用することも目的とする。この機能を利用
する際に利用者が送信したデータも\ref{bunpu}のマップ作成に使用する。シ
ステム利用時の流れは図\ref{groupgai}の通りである。
\par
% この際、既存のアプリケーションでは複数人で情報を相互に把握する際、図\ref{kizon}の矢印の数だけ登録が必要になるが、本システムでは図\ref{my}のようになる。
\begin{figure}[h]
\begin{center}
\includegraphics[bb=0 0 751 746,scale=0.5]{group.pdf}
\caption{グループ利用時の流れ}
\label{groupgai}
\end{center}
\end{figure}
% \begin{figure}[h]
% \begin{center}
% \includegraphics[bb=32 19 829 565,scale=0.3]{my.pdf}
% \caption{本システム利用時}
% \label{my}
% \end{center}
% \end{figure}
% \begin{figure}[h]
% \begin{center}
% \includegraphics[bb=32 19 829 565,scale=0.4]{gainen2.pdf}
% \caption{グループ利用時の概念図}
% \end{center}
% \end{figure}
\subsubsection{グループ作成・管理}
\label{group}
少人数グループでの利用をするためのグループを作成・管理する機能で
ある。以下の3つの機能からなる。
\begin{itemize}
\item 新規グループの作成
\item グループへの加入
\item 加入済みグループからの脱退
\end{itemize}
\subsubsection{グループ単位のマップの作成}
\ref{group}の機能を用いて作成したグループ単位で利用するシステムである。グルー
プメンバが最後に利用した位置情報、名前、時刻をマップ上のマーカで表示す
る。\par
図\ref{test}は本システムの利用時の一例である。\ref{group}の機能を用い
て作成した``みつゆきの仲間''というグループでmituyukiという名前のユー
ザが位置情報を共有し、testという同じグループのユーザの情報を表示してい
る状態である。
\begin{figure}[h]
\begin{center}
\includegraphics[bb=0 0 751 746,scale=0.3]{test.pdf}
\caption{グループ単位のマップの表示例}
\label{test}
\end{center}
\end{figure}
\subsection{設定地域内の分布表示}
\label{bunpu}
災害時に利用者の避難状況を確認することを想定したシステムである。
ユーザが\ref{kozin}や\ref{shounin}のシステムを利用した際に発信され
る情報を基に、各ユーザが設定した地域ごとの分布マップを作成する。
ここではユーザのプライバシやセキュリティ面への考慮からユーザ名等は表
示せず、地域内での分布のみを表示する。図\ref{skt}は山形県酒田市の人
口密度をもとにマップを擬似的に作成したものである。
\begin{figure}[h]
\begin{center}
\includegraphics[bb=0 0 1172 485,scale=0.3]{sakata.pdf}
\caption{地域の分布表示の例}
\label{skt}
\end{center}
\end{figure}
\section{本システムの有効性}
以上の点を踏まえ、本研究で提示した問題に対する本システムの有効性を記
述する。
\subsection{災害時の避難状況の視覚的な確認}
1.1や2.1で記述した通り、位置情報を発信できる情報端末が普及しているにも
関わらず、それを用いた利用者同士のコミュニケーションや情報共有が有効に
活用されていないことが問題視されていた。それに対し、本システムでは災害時
を想定し、スマートフォン等の携帯端末のみを用いて利用者同士の情報を
Web上のマップに描画することで視覚的に確認できる設計を実現した。
\subsection{完全に独立した設計}
\ref{apli}で記述した通り、既存の類似アプリケーションではiCloudやGoogle
アカウント、電話番号等の外部の情報を所持している必要があった。本システ
ムでは専用のアカウントを作成し、またその際にも外部の情報を必要としない
設計を実現した。
\subsection{簡潔で誰でも使える設計}
既存のシステムと比べた本システムの複数人数で情報を共有する際のグループ
作成にかかる行程数の比較は2.1.3で記述した通りである。また、 1.1で
記述したような既存のアプリケーションと比べ、ライセンスの購入等の必要が
ないため誰でも本システムの機能を自由に利用可能である。
% \subsection{実験}
% なにをどう比較すればいいのか思いつかないので実験が進みません。\par
\chapter{結論とシステムへの評価}
本システムへの結論・評価としては以下のようなものが挙げられる。
\section{結論}
利用者から発信された情報を元にリアルタイムでWeb上のマップを描画するシス
テムを構築した。それにより、災害時における逃げ遅れ等の二次災害の原因として問題
視されていた避難者との情報共有に関する問題を、指定した地域の避難状
況を携帯端末から視覚的に確認可能にすることで解決した。また、外部の情報を
必要とせず、誰でも制限なく利用できる簡潔なシステムを実現した。
%また、それにともない複数人のグループ単位で情報を共有できるシステムを構築した。
% それによってなにか解決したか具体的なことは実験をしないと書けません。
\section{システムへの評価と展望}
本システムへの評価と展望について記述する。
\subsection{有事の際の情報リセット}
本システムは災害時のみならず、平常時からの利用も考慮している。それに伴
い、地震等が発生する以前のデータが残っていると地震後に全てのユーザが情
報を更新しなければ正確な避難情報を得ることができなくなるという事態に陥
る。そこで、Webスクレイピング
\footnote{WebサイトからWebページのHTMLデータを収集して、特定のデータを抽出、整形し直すこと。}
を用いて常時気象庁からデータを取得し、災
害発生時にその時点よりも前のデータを消去する等の処理を加えることで
災害時に対応可能にする必要がある\cite{screape}。
\subsection{グループ参加の有無と個人の特定}
本システムを個人でのみ利用しているユーザに関して、個人を特定する方法が完
全にない状態になっている。匿名性の保持という点では問題はないが、災害時
を考えた際に個人の特定の必要性に関して懸念される。
\subsection{グループ管理のセキュリティ観点}
現段階の本システムは、ユーザであれば誰でも存在する全てのグループに自由
に出入りできるようになっている。グループにIDを割り振る、特定のメンバー
に承認周りの権限を付与する等してグループ管理周辺のセキュリティについて
整えていく必要がある。
\subsection{同時利用時のキャパシティ}
\ref{bunpu}から、個人の特定を
目的としない場合の避難所から離れている利用者のばらつき等の視認性においては
問題なく見えるが、災害時に多くの利用者が同時に利用した場合、また、より人口
の多い場合などの動作に関してプログラムを用いて摸擬的に検証する必要があ
る。
\renewcommand{\bibname}{参考文献}
\bibliographystyle{junsrt}
\bibliography{bib}
\end{document}
SUZUKI Mitsuaki