Newer
Older
2018-mituyuki-thesis / mituyuki.tex
@SUZUKI Mitsuaki SUZUKI Mitsuaki on 28 Dec 2018 26 KB 'replace'
\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}\selectfont
   {\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
 更に、``いまどこ?位置検索''等をはじめとした無料のアプリケーションでは共
 有できる数に制限があったり全ての機能を利用するには有料であったりといっ
 たケースが存在する。例として上述の``いまどこ?位置検索''では14日間の試用
 期間では「自動測位機能」および「見守り機能」が利用できなく、また14日目
 以降の利用にはライセンスの購入と月額料の支払いが必要になる\cite{imadoko}。\par
 そこで、特別な外部のアカウントや電話番号等の登録情報を必要としない、 参
 加者の状態を個人単位で制限なくリアルタイムで相互に把握することができる
 アプリケーションが必要だと考えた。

 \section{過去の類似研究の例}
\label{senko}
本研究では災害時に複数人の位置情報を取り扱うことに重点を置くため、過去の研究の中
から災害時の位置情報や複数人の位置情報を扱う取り組みが行われた文献につい
て記述する。\par
松崎らは、スマートホームシステムのホームサーバを利用して地震災害時におけ
る被災状況の確認や被災者の救助支援に応用するシステムを提案してい
る\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{kizon}のようにグループ
 内の全員がお互いに個人間の設定をする必要がある。\par
 また、これらのアプリケーションではお互いに固有のアカウントを把握してい
 る利用者の情報しか得ることができないため、災害時に被災者全体の避難状況
 を把握することは不可能である。

 \begin{figure}[h]
   \begin{center}
    \includegraphics[bb=32 19 829 565,scale=0.3]{kizon.pdf}
    \caption{既存のアプリケーション}
    \label{kizon}
   \end{center}
  \end{figure}
    \subsection{JSON形式}
  JavaScript Object Notation(JSON)とは、データを表現するための記法である。
  表形式では記述が困難な構造のデータを、人間に対しての可読性を残しつつ計
  算機に対して伝達出来るような記法である。
  \subsection{CGI}
  Common Gateway Interface(CGI)とは、 Webサーバとプログラム間のデータの
  送受信の規格で、ブラウザからの要求に応じてプログラムを起動し、その
  結果をブラウザに返すためのインターフェイスである。


 \section{提案するシステム}
そこで、本研究では以下のような機能を導入したシステムを提案する。
  \begin{enumerate}
   \item システム利用者の位置情報を把握できる機能\par
	 利用者がシステムに送信した位置情報のデータを、ブラウザ上のマッ
	 プにリアルタイムで表示する。
   \item 一定範囲の地域内の分布を表示するマップ作成アプリケーション\par
	 災害時に利用者の避難状況を把握できるようにするため、設定した地
	 域内の利用者の分布をブラウザ上のマップに表示する。ここでは個人
	 は特定せず、あくまで分布のみの表示とする。
   \item 個別アカウントによるグループ管理\par
	 利用者個人を判別するためのアカウントを用いて、複数人単位で相互
	 の情報管理を可能にする。
   \item 少人数グループで情報共有する利用者のマップ作成アプリケーション
	 \par
	 上記の少人数グループ内で、個人を判別した上で位置情報を相互にリ
	 アルタイムで管理できるマップをブラウザ上で実現する。

  \end{enumerate}

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

  \subsection{JSON形式}
  JavaScript Object Notation(JSON) とは、データを表現するための記法であ
  る。表形式では記述が困難な構造のデータを、人間に対しての可読性を残しつつ計
  算機に対して伝達出来るような記法である。
  
  \subsection{CGI}
  Common Gateway Interface(CGI)とは、 Webサーバとプログラム間のデータの
  送受信の規格で、ブラウザからの要求に応じてプログラムを起動し、その
  結果をブラウザに返すためのインターフェイスである。
  
  \subsection{データの正規化}
  今回は関係データベース(DBMS)でデータを管理するため、データを正規化する必
  要がある。正規化と
  は、データを効率良く扱うために特定のルールにしたがって整理することであ
  る。以下に正規化の手順について記述する。
  
   \subsubsection{非正規形}
   整理されていない生の状態のデータのことを非正規形と言う。データベースで
   データを管理する際、このように一つの項目(フィールド)内に複数のデータが
   格納されていても複数のデータと認識することはできない。これらのデータを
   データベースが計算機で処理しやすい形式にすることが正規化である。\par
   \begin{table}[h]
    \begin{center}
     \begin{tabular}{|c|c|c|c|}\hline
      00100 & 大根 & 酒田30円30個 & 鶴岡40円40個\\\hline
      00101 & サツマイモ & 三川40円20個 & 鶴岡50円10個\\\hline
     \end{tabular}
     \caption{生のデータ}
    \end{center}
   \end{table}
   
   \subsubsection{第1正規化}
   非正規形において繰り返していたり、フィールド内に複数格納され
   ていたりするデータを別の行(レコード)に分離し、繰り返しを排除する。\par
   \begin{table}[h]
    \begin{center}
     \begin{tabular}{|c|c|c|c|c|}\hline
      cord & items & place & price &  quant\\\hline
      00100 & 大根 & 酒田 & 30円 & 30個 \\\hline
      00100 & サツマイモ & 三川 & 40円 & 20個 \\\hline
      00101 & 大根 & 鶴岡 & 40円 & 40個 \\\hline
      00101 & サツマイモ & 鶴岡 & 50円 & 10個 \\\hline
      %  \label{kuri}
     \end{tabular}
     \caption{繰り返しを排除した形}
    \end{center}
   \end{table}
   更に、テーブルごとにデータを一意に識別するための項目を設定する。このよ
   うなコードのことを主キーという。主キーは複数カラムから構成されることも
   あり、その場合は複合主キーと言う。\par
   \begin{table}[h]
    \begin{center}
     \begin{tabular}{|c|c|c|c|c|c|}\hline
      cord & icord & items & place & price & quant\\\hline
      00100 & 0001 & 大根 & 酒田 & 30円 & 30個 \\\hline
      00100 & 0002 & サツマイモ & 三川  & 40円 & 20個 \\\hline
      00101 & 0001 & 大根 & 鶴岡 & 40円 & 40個 \\\hline
      00101 & 0002 & サツマイモ & 鶴岡 & 50円 & 10個 \\\hline
     \end{tabular}
     \caption{第1正規形}
     \label{daiiti}
    \end{center}
   \end{table}
   
   
   \subsubsection{第2正規化}
   表\ref{daiiti}の第1正規形から部分関数従属性を排除する。関数従属とは、あ
   る属性Xを決めると他の属性Yが一意に決まるような状態のことである。この時、
   Xを決定項、Yを被決定項呼ぶ。部分関数従属とは、このときの被決定項が複数
   の決定項を持っている状態のことである。表\ref{daiiti}の場合、icordが決ま
   ればitemsが決まるが、他の項目が決定しない。そこで、icordを主キーとする
   itemsだけをまとめたテーブルを新規に作成する。第2正規化をすることでテー
   ブルごとの列の数を減らし、データの管理をより単純化する。
   
   \begin{table}[h]
    \begin{center}
     \begin{tabular}{|c|c|}\hline
      icord & items \\\hline
      0001 & 大根  \\\hline
      0002 & サツマイモ \\\hline
     \end{tabular}
     \caption{商品テーブル}
    \end{center}
   \end{table}
   
   \begin{table}[h]
    \begin{center}
     \begin{tabular}{|c|c|c|c|c|}\hline
      cord & icord &  place & price & quant\\\hline
      00100 & 0001 & 酒田 & 30円  & 30個 \\\hline
      00100 & 0002 & 三川 & 40円 & 20個\\\hline
      00101 & 0001 & 鶴岡 & 40円  & 40個 \\\hline
      00101 & 0002 & 鶴岡 & 50円 & 10個 \\\hline
     \end{tabular}
      \label{daini}
      \caption{注文テーブル}
    \end{center}
   \end{table}
  
   \subsubsection{第3正規化}
   第2正規形から推移的関数従属性を排除する。推移的関数従属性とは、被決定
   項または決定項と被決定項の組み合わせによって他の被決定項が一意に決ま
   ることを指す。今回の場合、表\ref{daini}において、icordとplaceが決まれ
   ばpriceも決まるため、別のテーブルを新たに作成する。最終的には表3.6,
   3.7, 3.8の状態になる。
    \begin{table}[p]
     \begin{center}
      \begin{tabular}{|c|c|}\hline
       icord & items \\\hline
       0001 & 大根  \\\hline
       0002 & サツマイモ \\\hline
      \end{tabular}
      \caption{商品テーブル}
     \end{center}
    \end{table}

    \begin{table}
     \begin{center}
      \begin{tabular}{|c|c|c|}\hline
       cord & icord & quant\\\hline
       00100 & 0001 & 30個 \\\hline
       00100 & 0002 & 20個 \\\hline
      00101 & 0001 & 40個 \\\hline
       00101 & 0002 & 10個 \\\hline
      \end{tabular} 
      \caption{注文テーブル}
     \end{center}
    \end{table}
    
    \begin{table}
     \begin{center}
      \begin{tabular}{|c|c|c|}\hline
       icord & place & price\\\hline
       0001 & 酒田 & 30円 \\\hline
       0002 & 三川 & 40円 \\\hline
       0001 & 鶴岡 & 40円 \\\hline
       0002 & 鶴岡 & 50円 \\\hline
      \end{tabular}
      \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{本システムの概観}
 本システムを利用する際の流れは以下の通りである。
\begin{enumerate}
 \item アカウントの作成・ログイン\par
       本システムを利用するための情報を入力しアカウントを作成し、ログイ
       ンする。
 \item グループの作成・加入・選択\par
       指定したユーザ同士で構成されるグループ周辺の設定をする。
 \item 利用端末から情報を送信・取得\par
       ユーザ自身の位置情報・利用時間等の情報をDBMSに送信すると同時に最
       新の情報を取得する。
 \item 取得したデータが反映されたマップの閲覧\par
       取得したデータを元に目的に応じて作成されたマップを閲覧する。
\end{enumerate}

なお、目的がユーザ自身の情報の更新に限る場合グループを選択する必要はなく、自身
の情報のみを更新する機能を利用することができる。利用時の概念図は図
\ref{sys}のようになる。各行程の詳細な手順は次章以降に記述する。

\begin{figure}[h]
 \includegraphics[bb=30 69 561 795,scale=0.5]{system.pdf}
 \caption{システム利用時の概念図}
\label{sys}
\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{有事の際の情報リセット}
  本システムは災害時のみならず、平常時からの利用も考慮している。それに伴
  い、地震等が発生する以前のデータが残っていると地震後に全てのユーザが情
  報を更新しなければ正確な避難情報を得ることができなくなるという事態に陥
  る。そこで、Webスクレイピング
  \footnote{WebサイトからWebページのHTMLデータを収集して、特定のデータを抽出、整形し直すこと。}
  を用いて常時気象庁からデータを取得し、災
  害発生時にその時点よりも前のデータを消去する等の処理を加えることで
  災害時に対応可能にする必要がある\cite{screape}。
  
  
 \section{グループ参加の有無と個人の特定}
 本システムを個人でのみ利用しているユーザに関して、個人を特定する方法が完
 全にない状態になっている。匿名性の保持と言う点では問題はないが、災害時
 を考えた際に個人の特定の必要性に関して懸念される。

 \section{グループ管理のセキュリティ観点}
 現段階の本システムは、ユーザであれば誰でも存在する全てのグループに自由
 に出入りできるようになっている。グループにIDを割り振る、特定のメンバー
 に承認周りの権限を付与する等してグループ管理周辺のセキュリティについて
 整えていく必要がある。
 
 \section{同時利用時のキャパシティ}
 \ref{bunpu}章から、個人の特定を
  目的としない場合の避難所から離れている利用者のばらつき等の視認性においては
  問題なく見えるが、災害時に多くの利用者が同時に利用した場合、またより人口
  の多い場合などの動作に関してプログラムを用いて摸擬的に検証する必要があ
  る。
  
  \renewcommand{\bibname}{参考文献}
\bibliographystyle{junsrt} 
\bibliography{bib} 
  \end{document}