\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{災害時を想定した複数人での活動を支援するシステムの構築}
  \author{廣瀬研究室 4年 c1151073 鈴木光明}
  \date{平成30年1月15日}
  \maketitle
  \begin{center}
%   \fontsize{11pt}{11pt}\selectfontd
   {\bfseries 概要}
  \end{center}

  %  \abstract{
   近年、GPS内蔵型携帯電話等の位置情報を計測できる情報端末が広く普及して
  いる。しかし、近年の熊本地震や北海道胆振地震をはじめと
  する災害時にその機能が有効に活用されていないのが現状である。現在位置情
  報を利用したガイドシステムは存在するが、利用者同士のコミュニケーショ
  ンや情報共有が念頭に置かれていない場合が多い。また、従来災害時に用いら
  れている伝言板等のシステムでは携帯電話とPCとの連携が取れず、避難者の立
  場が考慮されていないことが問題視されている。\par
   そこで、個人単位で位置情報を発信できる点に着目し、災害時における避難
  者の位置情報の共有の簡易化を図るWebアプリケーションを構築する。また、外部か
  らの匿名性を保持した上で、設定したグループ内における個人間での情報の相
  互共有を可能にし、災害時に家族等の少人数のコミュニティ内で活用できるよ
  うな機能も構築する。また、その機能を応用し、フィールドワーク等複数人の
  位置情報を相互に確認したいような場面でも利用できるようなシステムを構築
  する。(441文字)
   \\  
\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}
   \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}
   \caption{システム利用時に必要な設定数の差}
   \label{system}
  \end{center}
 \end{table}

\chapter{システムの構築環境}
本研究で開発するシステムの環境について記述する。
  % \section{用語解説}
  % システムを提案する上で必要となる用語の解説を記述する。

  % \subsection{JSON形式}
  % JavaScript Object Notation(JSON) とは、データを表現するための記法であ
  % る。表形式では記述が困難な構造のデータを、人間に対しての可読性を残しつつ計
  % 算機に対して伝達出来るような記法である。
  
  % \subsection{CGI}
  % Common Gateway Interface(CGI)とは、 Webサーバとプログラム間のデータの
  % 送受信の規格で、ブラウザからの要求に応じてプログラムを起動し、その
  % 結果をブラウザに返すためのインターフェイスである。
  
  \section{データの正規化}
  今回は関係データベース(DBMS)でデータを管理するため、データを正規化する必
  要がある。正規化と
  は、データを効率良く扱うために特定のルールにしたがって整理することであ
  る。以下に正規化の手順について本システムで利用したデータの一部を用いて
  記述する。
  
   \subsubsection{非正規形}
   整理されていない生の状態のデータのことを非正規形と言う。データベースで
   データを管理する際、このように一つの項目(フィールド)内に複数のデータが
   格納されていても複数のデータと認識することはできない。これらのデータを
   データベースが計算機で処理しやすい形式にすることが正規化である。\par
   \begin{table}[h]
    \begin{center}
     \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}
     \caption{生のデータ}
    \end{center}
   \end{table}
   
   \subsubsection{第1正規化}
   非正規形において繰り返していたり、フィールド内に複数格納され
   ていたりするデータを別の行(レコード)に分離し、繰り返しを排除する。\par
   \begin{table}[h]
    \begin{center}
     \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}
     \caption{繰り返しを排除した形}
    \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}
     \begin{tabular}{|c|c|}\hline
      name & pass \\\hline
      太朗 & hogehoge  \\\hline
      花子 & gehogeho \\\hline
      鈴木 & pasuwa-do \\\hline
     \end{tabular}
     \caption{パスワードテーブル}
    \end{center}
   \end{table}
   
   \begin{table}[h]
    \begin{center}
     \begin{tabular}{|c|c|}\hline
      name & local \\\hline
      太朗 & 鶴岡  \\\hline
      花子 & 酒田 \\\hline
      鈴木 & 鶴岡 \\\hline
     \end{tabular}
     \caption{地方テーブル}
    \end{center}
   \end{table}

   \begin{table}[h]
    \begin{center}
     \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}
      \caption{ユーザ情報テーブル}
    \end{center}
   \end{table}
  
   \subsubsection{第3正規化}
   第2正規形から推移的関数従属性を排除する。推移的関数従属性とは、被決定
   項または決定項と被決定項の組み合わせによって他の被決定項が一意に決ま
   ることを指す。今回の場合、表\ref{daini}において、nameとgroupが決まれ
   ばその他のデータが決まるため、別のテーブルを新たに作成する。検索の効
   率を考慮して部分的に正規化の程度を敢えて落とした状態のままにする場合
   もある。最終的には表3.6~3.9の状態になる。
    \begin{table}[p]
     \begin{center}
      \begin{tabular}{|c|c|}\hline
       name & pass \\\hline
       太朗 & hogehoge  \\\hline
       花子 & gehogeho \\\hline
       鈴木 & pasuwa-do\\ \hline
      \end{tabular}
      \caption{パスワードテーブル}
     \end{center}
    \end{table}

   \begin{table}[h]
    \begin{center}
     \begin{tabular}{|c|c|}\hline
      name & local \\\hline
      太朗 & 鶴岡  \\\hline
      花子 & 酒田 \\\hline
      鈴木 & 鶴岡 \\\hline
     \end{tabular}
     \caption{地方テーブル}
    \end{center}
   \end{table}

   \begin{table}[h]
    \begin{center}
     \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}
      \caption{位置情報テーブル}
    \end{center}
   \end{table}


   \begin{table}[h]
    \begin{center}
     \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}
      \caption{利用時刻テーブル}
    \end{center}
   \end{table}

  
 \section{作業環境}
  開発は以下の環境で行う。
  \begin{itemize}
   \item Ruby 2.3.0
   \item Leaflet.js 1.3.4
   \item SQLite3
  \end{itemize}
  
  
  % \section{扱うデータ}
  % \label{data}
  % 今回は正規化を行った以下のテーブルでデータを管理する。
  % \begin{itemize}
  %  \item user(ユーザ名, パスワード)
  %  \item users(クッキーID, ユーザ名, 最終ログイン時刻)
  %  \item ginfo(グループ名, グループの管理ユーザ名)
  %  \item gmember(ユーザ名, 所属するグループ名)
  %  \item latlng(グループ名, ユーザ名, 取得した経度, 取得した緯度)
  %  \item lastlaln(ユーザ名, 最後に取得した経度, 最後に取得した緯度)
  %  \item time(ユーザ名, グループ名, 取得した時刻)
  %  \item local(ユーザ名, 設定した地域)
  % \end{itemize}
    

\chapter{システムの設計}
本システムの設計について記述する。

 \section{RDBMSによるデータ管理}
 前章で延べた通り本システムではRDBMSで各データを管理する。そこからRubyプ
 ログラムやCGIからSQL文を実行することで必要なデータを取り出す形式である。
 本システムで扱うデータのER図は図\ref{ER}の通りである。
 
  \begin{figure}[h]
   \begin{center}
    \includegraphics[bb=0 0 398 436,scale=0.5]{ER.pdf}
    \caption{本システムで扱うデータのER図}
    \label{ER}
   \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}
\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{個人アカウント作成}
  ユーザ名とパスワードと地域の情報を設定し、利用者個人を判別するためのア
  カウントを作成する機能である。アカウント作成時にはユーザ名、パスワード、
  地域の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}
  
