\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{既存のアプリケーション}
現在、Apple社が提供するクラウドサービス``iCloud''の機能である``友だちを探
す''やGoogleが提供している地図・ローカル検索サービス`'Googleマップ''の機能
である``現在地を共有''等の位置情報の共有を目的としたアプリケーションが
存在する。しかし、これらのアプリケーションは利用する度に共有相手の設定
や時間の指定や設定の変更が必要になる。また、個人間の共有を目的にしてい
るため、複数人のグループ等で共有をする際はグループ内の全員がお互いに個
人間の設定をする必要がある。そのため、表\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 ユーザ名
\item クッキー情報
\item グループ加入情報
\item 位置情報
\end{itemize}
ここから本システムを設計していく上で必要なデータを考察しながら追加していく。
\subsubsection{パスワード}
本システムを利用する際、クッキー情報を取得していれば本人の認証を維持す
ることは可能である。しかし、利用端末の故障等の理由から別の端末に変更し
た際や複数端末からの利用をする際にクッキー情報を引き継ぐことができない。
そのため、 クッキーIDとは別に情報を引き継ぐための個別の情報が必要にな
る。
そこで、本システムではクッキーIDとは別にユーザごとのパスワードをユーザ
を認識するための情報として設定する。
\subsubsection{グループマスタ}
複数人数でのグループで情報を共有する際、本システムでは情報の更新頻度等
の設定は個別で行う。しかし、この機能では位置情報とともにユーザ名も表示
するため、作成したグループに全てのユーザが自由に干渉できる設定にすると
プライバシやセキュリティ面の安全性に欠ける。そこで、ユーザの中にグルー
プマスタという役職を割り当て、グループへの参加承認等に関する権限を付与
する必要がある。
\subsubsection{最終利用時刻}
本システムはWeb上のマップ描画によるリアルタイムな情報共有を目的として
いる。ユーザ名と位置情報のみの表示ではマップに表示される他のユーザがい
つ情報を送信したかを知る手段がないためリアルタイムに情報を更新する利点
が失われる。。そこで、本システムでユーザが情報を
送信する際に利用した時刻も送信し、閲覧できるようにする必要がある。
\subsubsection{地域名}
本システムでは災害時のユーザの避難分布を表示する。その際、全ユーザの情
報を表示すると範囲が広く情報過多になる。そこで、一定範囲ごとの地域を設定し、
設定した地域内の利用者の分布を表示する。元段階の本システムでは市町村を
単位としているが、人口等を考慮し更に厳重な条件のもと範囲の単位を設定す
る必要がある。
\subsection{本システムに実装するデータ}
上記の点を踏まえて、本システムでは以下のデータをユーザから取得し、管理
する。
\begin{itemize}
\item ユーザ名
\item パスワード
\item クッキー情報
\item 位置情報
\item グループ加入情報
\item グループ編集権限情報
\item 利用時刻
\item 地域名
\end{itemize}
\section{データの正規化}
本システムは関係データベース(DBMS)でデータを管理するため、データを正規化する必
要がある。正規化とは、データを効率良く扱うために特定のルールにしたがっ
て整理することである。\par
例として、本システムで利用するデータの一部をまとめた表\ref{nama}があ
る。この状態では任意のデータを抽出したり参照したりする際に一度に複数のデータ
が当てはまるため効率的ではない。また、一つのデータを修正するために複数
の箇所を変更する必要があり手間がかかる場合がある。そこで、本研究ではプ
ログラムからデータの参照や抽出を行うため第3正規化まで行う。\par
以下に本システムで利用したデータの正規化の手順について記述する。
\begin{table}[h]
\begin{center}
\caption{生のデータ}
\label{nama}
\begin{tabular}{|c|c|c|c|}\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}
更に、テーブルごとにデータを一意に識別するための項目を設定する。このよ
うなコードのことを主キーという。主キーは複数カラムから構成されることも
あり、その場合は複合主キーと言う。\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
ユーザ自身の位置情報・利用時間等の情報をDBMSに送信すると同時に最
新の情報を取得する。
\item 取得したデータが反映されたマップの閲覧\par
取得したデータを元に目的に応じて作成されたマップを閲覧する。
\end{enumerate}
なお、目的がユーザ自身の情報の更新に限る場合グループを選択する必要はなく、自身
の情報のみを更新する機能を利用することができる。利用時の概念図は図
\ref{sys}のようになる。
\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{アカウントの制約に関して}
本システムは外部の固有アカウントを必要としない設計にしている。そのため、
システムを利用するためのアカウントを最初に作成する必要がある。メイルア
ドレス等の登録を用いないため、ユーザ名を直接ユニークキーとする。
\subsection{アカウントの認証期限に関して}
本システムでは後述のAjaxによる非同期通信を行う以外に、複数ページを経由
したり、システムから離れたりした際にもある程度の間ログイン情報を保持す
る必要がある。そこで、Cookieを利用することでログイン情報を保持する。セ
キュリティ上の問題を踏まえて、永久に保持するのではなく情報は24時間で破
棄する。
\section{JavaScriptを用いた動的なWebの作成}
本システムでは主にJavaScriptを用いて動的なWebページを作成する。
\subsection{Leaflet.jsを用いたマップ作成}
Leaflet.jsとはWeb上で地図を作成・表示するためのオープンソースの
JavaScriptライブラリである。GeoJSONからデータを読み込み、ポップアップ
等の機能を利用したマップを作成することができる。本システムではこれを用
いてOpenStreetMapの地図をベースにしたマップを作成する。
\subsection{Ajaxによる非同期通信}
本システムで利用時に更新する情報は一部であるため、非同期通信で更新する
必要がある情報のみをサーバにリクエストし、更新する。本システムでは以下
のような流れで利用している。
\begin{enumerate}
\item ユーザ自身の位置情報を送信する。
\item CGIでSQL文を実行し、データベースからその時の利用者に必要なデー
タをJSON形式で返す。
\item 受け取ったデータをもとにマップを作成する。
\end{enumerate}
\begin{figure}[h]
\begin{center}
\includegraphics[bb=70 69 808 508,scale=0.25]{ajax.pdf}
\caption{本システムでの非同期通信の例}
\end{center}
\end{figure}
\section{RDBMSによるデータ管理}
前章で延べた通り本システムではRDBMSで各データを管理する。そこからRubyプ
ログラムやCGIよりSQL文を実行することで必要なデータを取り出す形式である。
今回は前章の例に挙げたデータの他にグループのマスタ、クッキー情報のデー
タを加えて正規化を行った以下のテーブルでデータを管理する。
\begin{itemize}
\item ユーザ情報(ユーザ名, パスワード)
\item 設定地域情報(ユーザ名, 設定した地域)
\item クッキー情報(クッキーID, ユーザ名, 最終ログイン時刻)
\item 利用時刻情報(ユーザ名, グループ名, 最終利用時刻)
\item 位置情報(ユーザ名, 取得した経度, 取得した緯度)
\item グループ情報(グループ名, マスター名)
\item グループ加入状況(ユーザ名, 所属するグループ名)
\end{itemize}
本システムで扱うデータのER図は図\ref{ER}の通りである。
\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{システムの実行}
実際に構築したシステムを実行する行程について記述する。
\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を取得する。認証期限は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}のマップ作成に使用する。
\par
% この際、既存のアプリケーションでは複数人で情報を相互に把握する際、図\ref{kizon}の矢印の数だけ登録が必要になるが、本システムでは図\ref{my}のようになる。
% \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}の機能を用いて作成したグループ単位で利用するシステムである。グルー
プメンバーが最後に利用した位置情報、名前、時刻をマップ上のピンで表示す
る。
\begin{figure}[h]
\begin{center}
\includegraphics[bb=0 0 751 746,scale=0.5]{test.pdf}
\caption{グループ利用時の画面例}
\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}
\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