diff --git a/OSM.pdf b/OSM.pdf new file mode 100644 index 0000000..372edfd --- /dev/null +++ b/OSM.pdf Binary files differ diff --git a/bib.bib b/bib.bib index 80ed020..f7d8552 100644 --- a/bib.bib +++ b/bib.bib @@ -15,8 +15,7 @@ @Misc{imadoko, author = {DailyTimer.net}, title = {いまどこ?オンラインマニュアル}, -note = "\url{http://file.blog.fc2.com/nekonotesoft/manual/imadoco-jp.html}", -year = "2018-12-20", +note = "\url{http://file.blog.fc2.com/nekonotesoft/manual/imadoco-jp.html(参照2018-12-20)}", } @article{nige, diff --git a/mituyuki.pdf b/mituyuki.pdf index f68daf2..e2c5e21 100644 --- a/mituyuki.pdf +++ b/mituyuki.pdf Binary files differ diff --git a/mituyuki.tex b/mituyuki.tex index a80f794..cbc3810 100644 --- a/mituyuki.tex +++ b/mituyuki.tex @@ -3,7 +3,6 @@ \usepackage{url} \usepackage{ascmac} \thispagestyle{empty} - \addtolength{\topmargin}{-2cm} \addtolength{\textheight}{3cm} \addtolength{\textwidth}{1cm} @@ -35,7 +34,7 @@ そこで、個人単位で位置情報を発信できる点に着目し、災害時における避難 者の位置情報の共有の簡易化を図るWebアプリケーションを構築する。また、外部か らの匿名性を保持した上で、設定したグループ内における個人間での情報の相 - 互共有を可能にし、災害時に家族等の少人数のコミュニティ内で活用できるよ + 互共有を可能にし、災害時に家族等の複数人のコミュニティ内で活用できるよ うな機能も構築する。また、その機能を応用し、フィールドワーク等複数人の 位置情報を相互に確認したいような場面でも利用できるようなシステムを構築 する。(491文字) @@ -46,16 +45,16 @@ 本研究の設定する目的とテーマ設定に至るまでの背景について記述する。 \section{テーマ設定の背景} - 日本では近年に見られる熊本地震地震や北海道胆振東部地震をはじめとした、地震や大 + 日本では近年に見られる熊本地震や北海道胆振東部地震をはじめとした、地震や大 雨による洪水等、 多数の被害者が出るような災害が頻繁に起こっている \cite{kisho}。その中で も高齢者をはじめとする災害弱者の逃げおくれによる被害が問題となっ ている\cite{nige}。他にも、電話や交通等のライフラインが混雑するため避難 後の安否確認が困難になる\cite{life}。そこで近年では避難経路の確保や把握 - 等の日常的な活動を行なうことが促進されている。しかし、事前の準備のみな + 等の日常的な活動を行うことが促進されている。しかし、事前の準備のみな らず実際に災害時の状況に陥った際の対応策が必要であると考えた。 そこで、各自が持っている位置情報を発信できる情報端末を利用することで - 被災地の人間の逃げ遅れの確認や、家族等少人数でのコミュニティ内での情報 + 被災地の人間の逃げ遅れの確認や、家族等複数人でのコミュニティ内での情報 の相互共有をする手段の必要性を感じた。\par また、その他にも野外でのフィールドワークを複数人で行う際や集団のツアー 客の自由行動等、予め時間や集合場所を決めていたとしても集団の動向を一目 @@ -65,7 +64,7 @@ いとされている\cite{oni, xEx}。また、Apple StoreやGoogle Playから配布されているアプリケーションの中にも、位置情報を不正に取得 している例が確認されている\cite{alert}。\par - 更に、Google Playでnekonotesoftから配信されている情報共有ソフト``いまど + さらに、Google Playでnekonotesoftから配信されている情報共有ソフト``いまど こ?位置検索''等をはじめとした無料のアプリケーションでは共 有できる数に制限があったり全ての機能を利用するには有料であったりといっ たケースが存在する。例として上述の``いまどこ?位置検索''では14日間の試用 @@ -117,22 +116,31 @@ \subsection{避難後の安否確認} -2016年の熊本地震におけるライフラインの復旧に関して能島は阪神淡路大 +能島によると2016年の熊本地震におけるライフラインの復旧に関して、阪神淡路大 震災や東日本大震災と比べ大幅に短縮され、迅速さにおいてはほぼ飽和状態に達 -していると述べている\cite{life}。しかし、ライフラインの完全な復旧には2週 +していると述べられている\cite{life}。しかし、ライフラインの完全な復旧には2週 間を要しているのが現状であり、その間は十分に外部との連絡を取れない人がい るのが事実である。 \subsection{既存のアプリケーション} +\label{apli} 現在、Apple社が提供するクラウドサービス``iCloud''の機能である``友だちを探 - す''やGoogleが提供している地図・ローカル検索サービス`'Googleマップ''の機能 + す''やGoogleが提供している地図・ローカル検索サービス``Googleマップ''の機能 である``現在地を共有''等の位置情報の共有を目的としたアプリケーションが 存在する。しかし、これらのアプリケーションは利用する度に共有相手の設定 - や時間の指定や設定の変更が必要になる。また、個人間の共有を目的にしてい + や時間の指定等の設定の変更が必要になる。また、個人間の共有を目的にしてい るため、複数人のグループ等で共有をする際はグループ内の全員がお互いに個 - 人間の設定をする必要がある。そのため、表\ref{system}のように人数が増えるほ - ど必要な設定数が増えていくことになる。\par + 人間の設定をする必要がある。そのため、人数が増えるほ + ど必要な設定数が増えていくことになる。具体的には、既存のシステムでは複 + 数人と情報共有する際に利用者全員が自分以外の利用者全員と設定する必要が + あるため、 + 利用者の数を$n$としたときに$n * (n -1)$回の設定が必要になる。それに対して、 + 本システムでは複数人で情報共有をする際、予め作成したグループに利用者が + それぞれ加入する設定を行うのみなため、利用者の数を$n$としたときに$n$回 + の設定が必要になる。 + 実際の数値で考えたときの既存のシステムと本システムの差は表\ref{system} + のようになる。\par また、これらのアプリケーションではお互いにiCloudやGoogleアカウント等の 外部の登録が必要な固有アカウントを把握している利用者の情報しか得るこ とができないため、情報の共有に制限がある。 @@ -188,41 +196,47 @@ \section{必要なデータの考察} 本システムを設計するにあたり必要なデータについて考察する。 \subsection{ベースシステムにおける必要最低限のデータ} - 本システムの設計において、Web上のマップ描画における位置情報の共有 - のみを目的としたシステムを考える。最低限必要なデータは以下の通りである。 + 本システムの設計において、前段階としてWeb上のマップ描画における位置情報の共有 + のみを目的としたシステムを考える。必要なデータは以下の通りである。 \begin{itemize} \item ユーザ名\par 個人を特定するために必要な固有のユーザ名が必要になる。 \item グループ情報\par - 本システムにおける複数人のグループで情報を共有する機能を利用する - 際にグループの作成等の設定に関する情報が必要になる。グループにつ - いての定義は\ref{group}に記述する。 + 本システムにおける複数人で情報を共有する機能を利用する + 際に、共有するユーザ間に共通の情報を付与する必要がある。そこで、 + 本システムではグループという括りの情報を付与し、共通のグループに + 所属するユーザ間で情報を共有する形式を取る。そのため、 + グループの作成等の設定に関する情報が必要になる。 \item 位置情報\par Web上のマップにユーザの位置を表示するために必要になる。 \end{itemize} ここから本システムを設計していく上で必要なデータを考察しながら追加していく。 - \subsubsection{クッキー情報} + \subsubsection{クッキーID} + \label{cookie} + Cookieとは、ユーザ側に各種情報を保持させるためにサーバから送られ、ユー + ザの端末に保存されるファイルである。 本システムはWeb上の複数ページを跨いで利用するため、ページを移動した際 にもユーザの情報を引き継ぐ必要がある。また、一度本システムにログインし たユーザが本システムから別のページに移動した後もログイン状態を保持する 形式にする。そこで、本システムにログインした際にユーザの端末毎に固有の - IDを設定しクッキー情報として保存する。 + IDを設定しCookieに保存し、クッキーIDというデータとして扱う。 \subsubsection{パスワード} - 本システムを利用する際、先述の通りクッキー情報を取得していれば本人の認 + 本システムを利用する際、先述の通りCookieを取得していれば本人の認 証を維持す ることは可能である。しかし、利用端末の故障等の理由から別の端末に変更し - た際や複数端末からの利用をする際にクッキー情報を引き継ぐことができない。 - そのため、 クッキー情報とは別に情報を引き継ぐための個別の値が必要にな - る。 - そこで、本システムではクッキー情報とは別にユーザごとのパスワードをユーザ + た際や複数端末からの利用をする際にCookieを引き継ぐことができない。 + そのため、 本システムのクッキーIDとは別に情報を引き継ぐための個別の値 + が必要になる。 + そこで、クッキーIDとは別にユーザごとのパスワードをユーザ を認識するための情報として設定する。 \subsubsection{グループマスタ} 複数人数でのグループで情報を共有する際、本システムでは情報の更新頻度等 の設定は個別で行う。しかし、この機能では位置情報とともにユーザ名も表示 - するため、作成したグループに全てのユーザが自由に干渉できる設定にすると + するため、作成したグループに全てのユーザが自由に加入できる設定にすると、 + 他ユーザの名前と位置情報を自由に取得できることになり、 プライバシやセキュリティ面の安全性に欠ける。そこで、ユーザの中にグルー プマスタという役職を割り当て、グループへの参加承認等に関する権限を付与 する必要がある。 @@ -231,25 +245,35 @@ 本システムは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 クッキー情報 + \item クッキーID \item 位置情報 \item グループ加入情報 \item グループ編集権限情報 @@ -286,7 +310,7 @@ \subsubsection{非正規形} 表\ref{nama}のように整理されていない生の状態のデータのことを非正規形 - と言う。データベースで + という。データベースで データを管理する際、このように一つの項目(フィールド)内に複数のデータが 格納されていても複数のデータと認識することはできない。これらのデータを 関連性を失わないようにデータベースが計算機で処理しやすい形式にするこ @@ -308,16 +332,17 @@ \label{kuri} \end{center} \end{table} - 更に、テーブルごとにデータを一意に識別するための項目を設定する。このよ - うなコードのことを主キーという。主キーは複数カラムから構成されることも - あり、その場合は複合主キーと言う。\par + さらに、テーブルごとにデータを一意に識別するための項目を設定する。このよ + うな列(カラム)のことを主キーと呼ぶ。主キーは複数カラムから構成されることも + あり、その場合は複合主キーと呼ぶ。今回はnameとgroupが決まれば他のデー + タが一意に決定するためこの二つを複合主キーとする。\par \subsubsection{第2正規化} 表3.2の第1正規形から部分関数従属性を排除する。関数従属とは、あ る属性Xを決めると他の属性Yが一意に決まるような状態のことである。この時、 - Xを決定項、Yを被決定項呼ぶ。部分関数従属とは、このときの被決定項が複数 + Xを決定項、Yを被決定項と呼ぶ。部分関数従属とは、このときの被決定項が複数 の決定項を持っている状態のことである。表3.2の場合、nameが決ま - ればpassが決まるが、他の項目が必ずしも決定しない。そこで、例えばname + ればpassが決まるが、他の項目が必ずしも決定しない。そこで、たとえばname を主キーとする passだけをまとめたテーブルを新規に作成する。このように 第2正規化をする ことでテーブルごとの列の数を減らし、データの管理をより単純化する。 @@ -441,7 +466,7 @@ \item グループの作成・加入・選択\par 指定したユーザ同士で構成されるグループ周辺の設定をする。 \item 利用端末から情報を送信・取得\par - ユーザ自身の位置情報・利用時間等の情報をDBMSに送信すると同時に最 + ユーザ自身の位置情報・利用時間等の情報をRDBMSに送信すると同時に最 新の情報を取得する。 \item 取得したデータが反映されたマップの閲覧\par 取得したデータを元に目的に応じて作成されたマップを閲覧する。 @@ -460,39 +485,204 @@ \end{center} \end{figure} + % \section{個別アカウントの管理} + % 本システムを利用するために必要なアカウント周辺について記述する。 + % \subsection{アカウントの制約に関して} \section{個別アカウントの管理} - 本システムを利用するために必要なアカウント周辺について記述する。 - \subsection{アカウントの制約に関して} 本システムはアカウント作成の際にユーザ名とパスワードと地域のみを設定 する設計で、メイルアドレス等の外部のデータを必要としない。そのため、ユー ザ名を個人を判別するためのユニークキーとする。 - \subsection{アカウントの認証期限に関して} - 本システムでは後述のAjaxによる非同期通信を行う以外に、複数ページを経由 - したり、システムから離れたりした際にもある程度の間ログイン情報を保持す - る必要がある。そこで、Cookieを利用することでログイン情報を保持する。セ - キュリティ上の問題を踏まえて、永久に保持するのではなく情報は24時間で破 - 棄する。 + % \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からデータを読み込み、ポップアップ 等の機能を利用したマップを作成することができる。本システムではこれを用 - いてOpenStreetMapの地図をベースにしたマップを作成する。 + いてOSMの地図をベースにしたマップを作成する。 \subsection{Ajaxによる非同期通信} - 本システムで利用時に更新する情報は一部であるため、非同期通信で更新する - 必要がある情報のみをサーバにリクエストし、更新する。本システムでは以下 + 本システムでは利用時にページ内の全ての情報を更新する必要はないため、一部の + 情報のみを送受信する設計とする。 + また、ユーザが情報 + を送受信する間にも同ページ内のマップを閲覧する等の他の作業をできるよう + にする必要がある。特に、同期通信を行うと情報を送受信する度にマップが更 + 新されるため、ユーザがスムーズにマップを閲覧することができない。 + そこで、非同期通信を用 + いて更新する必要がある情報のみをサーバにリクエストする。本システムでは以下 のような流れで利用している。 \begin{enumerate} \item ユーザ自身の位置情報を送信する。 \item CGIでSQL文を実行し、データベースからその時の利用者に必要なデー タをJSON形式で返す。 - \item 受け取ったデータをもとにマップを作成する。 + \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} @@ -501,43 +691,68 @@ \end{figure} \section{RDBMSによるデータ管理} - 前章で延べた通り本システムではRDBMSで各データを管理する。そこからRubyプ - ログラムやCGIよりSQL文を実行することで必要なデータを取り出す形式である。 + 前章で延べた通り本システムではRDBMSで各データを管理する。そこからCGIより + SQL文を実行することで必要なデータを取り出す。\par - 今回は前章の例に挙げたデータの他にグループのマスタ、クッキー情報のデー + 本システムでは前章の例に挙げたデータの他にグループのマスタ、クッキーIDのデー タを加えて正規化を行った以下のテーブルでデータを管理する。 \begin{itemize} - \item ユーザ情報(ユーザ名, パスワード) - \item 設定地域情報(ユーザ名, 設定した地域) - \item クッキー情報(クッキーID, ユーザ名, 最終ログイン時刻) - \item 利用時刻情報(ユーザ名, グループ名, 最終利用時刻) - \item 位置情報(ユーザ名, 取得した経度, 取得した緯度) - \item グループ情報(グループ名, マスター名) - \item グループ加入状況(ユーザ名, 所属するグループ名) + \label{table} + \item ユーザ情報 user(ユーザ名, パスワード) + \item 設定地域情報 local(ユーザ名, 設定した地域) + \item クッキーID情報 cookie(クッキーID, ユーザ名, 最終ログイン時刻) + \item 利用時刻情報 lasttime(ユーザ名, グループ名, 最終利用時刻) + \item 位置情報 latlng(ユーザ名, 取得した経度, 取得した緯度) + \item グループ情報 ginfo(グループ名, マスタ名) + \item グループ加入状況 gmember(ユーザ名, グループ名) \end{itemize} - \subsection{本システムののER図と解説} + ここではデータ内容の説明をするため分かりやすいカラム名で表記し + た。実際のカラム名は表\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テーブル} - 本システムではアカウント作成の際に名前とパスワードと地方を設定する。 - 地方の設定は1アカウントに一つであり作成時に必ず設定するため1対1の関係 + 本システムではアカウント作成の際に名前とパスワードと地域を設定する。 + 地域の設定は\ref{chiiki}で記述した通り市町村単位で選択する。 + 地域の設定は1アカウントに一つであり作成時に必ず設定するため1対1の関係 である。 \subsubsection{userテーブルとcookieテーブル} - 本システムではログイン時にユーザごとのクッキー情報を作成する。アカウ + 本システムではログイン時にユーザごとのcookieを作成する。アカウ ントを作成し - たのみの状態や、一定時間が経過しクッキー情報が削除された状態ではクッ - キー情報は存在しないため、1対0または1の関係である。 + たのみの状態や、一定時間が経過しcookieが削除された状態ではcookieは存 + 在しないため、1対0または1の関係である。 \subsubsection{userテーブルとlasttimeテーブル} 本システムのいずれかの情報共有の機能を利用し、情報を送信した際にユー ザごとの最終利用時刻をデータベースに登録する。アカウントを登録したの みで情報共有の機能を利用していない際はtimeのデータは存在しないため、1 - 対0または1の関係である、 + 対0または1の関係である。 \subsubsection{userテーブルとlatlngテーブル} 上述のlasttimeテーブルと同様に、アカウントを登録したの みで情報共有の機能を利用していない際はlatとlngのデータは存在しないため、1 - 対0または1の関係である、 + 対0または1の関係である。 \subsubsection{userテーブルとgmemberテーブル} ユーザが複数人グループの情報共有機能を利用する際にグループへの登録が @@ -557,9 +772,11 @@ \end{figure} \chapter{システムの実行} -実際に構築したシステムを実行する行程について記述する。利用時の流れは図 -\ref{sys}のようになる。 - +実際に構築したシステムを利用する際の動作とその時のシステムの動きについて +記述する。利用時の流れは図\ref{sys}のようになる。 +\begin{verbatim} + +\end{verbatim} \begin{figure}[h] \begin{center} \includegraphics[bb=30 69 561 795,scale=0.5]{system.pdf} @@ -577,7 +794,7 @@ ユーザ名とパスワードと地域の情報を設定し、利用者個人を判別するためのア カウントを作成する機能である。アカウント作成時にはユーザ名、パスワード、 地域の3項目を入力する。ユーザ名を個人を判別するためのデータ - とするため、ユーザが既存のアカウントと重複していた際にはエラーを表示す + とするため、ユーザ名が既存のアカウントと重複していた際にはエラーを表示す る。 \begin{figure}[h] @@ -589,7 +806,7 @@ \subsection{ログイン} 作成したアカウントのユーザ名とパスワードを入力し、システムにログインす るための機能である。ユーザのログイン情報を保持するため、ログインと同時 - にクッキーIDを取得する。認証期限は24時間に設定している。 + にクッキーIDを取得する。クッキーIDの有効期限は24時間に設定している。 \section{位置情報を利用した情報共有} 本システムのメインとなる機能である。利用者が意図的に情報を送信したり、 @@ -598,8 +815,8 @@ \subsection{個人の位置情報の送信} \label{kozin} - アカウントを所有するユーザがデータベースに自分の利用情報をデータベース - に送信する機能である。ここで得たデータを元に後述の地域ごとの分布マップ + 本システムにログイン中のユーザが自分の利用情報をデータベース + に送信する機能である。ここで得たデータを基に後述の地域ごとの分布マップ を作成する(\ref{bunpu})。 % \begin{figure}[h] % \begin{center} @@ -608,10 +825,10 @@ % \end{center} % \end{figure} - \subsection{少人数グループでの利用} + \subsection{複数人グループでの利用} \label{shounin} - 特に少人数単位のグループ内で、個人を特定した上で相互に情報を共有するシ - ステムである。災害時に家族等少人数のコミュニティ内でお互いの情報を把握 + 複数人単位のグループ内で個人を特定した上で相互に情報を共有するシ + ステムである。特に、災害時に家族等複数人のコミュニティ内でお互いの情報を把握 するための機能である。この機能は、災害時のみならず、グループワーク等複数人の位 置情報を相互に把握したい状況で利用することも目的とする。この機能を利用 する際に利用者が送信したデータも\ref{bunpu}のマップ作成に使用する。シ @@ -654,8 +871,12 @@ \subsubsection{グループ単位のマップの作成} \ref{group}の機能を用いて作成したグループ単位で利用するシステムである。グルー - プメンバーが最後に利用した位置情報、名前、時刻をマップ上のピンで表示す - る。図\ref{test}は本システム利用時の一例である。 + プメンバが最後に利用した位置情報、名前、時刻をマップ上のマーカで表示す + る。\par + 図\ref{test}は本システムの利用時の一例である。\ref{group}の機能を用い + て作成した``みつゆきの仲間''というグループでmituyukiという名前のユー + ザが位置情報を共有し、testという同じグループのユーザの情報を表示してい + る状態である。 \begin{figure}[h] \begin{center} @@ -667,9 +888,10 @@ \subsection{設定地域内の分布表示} \label{bunpu} - 利用者が\ref{kozin}や\ref{shounin}のシステムを利用した際に発信され - る情報をもとに各利用者が設定した地域分布マップを作成するシステムである。 - ここでは利用者にプライバシやセキュリティ面への考慮からユーザ名等は表 + 災害時に利用者の避難状況を確認することを想定したシステムである。 + ユーザが\ref{kozin}や\ref{shounin}のシステムを利用した際に発信され + る情報を基に、各ユーザが設定した地域ごとの分布マップを作成する。 + ここではユーザのプライバシやセキュリティ面への考慮からユーザ名等は表 示せず、地域内での分布のみを表示する。図\ref{skt}は山形県酒田市の人 口密度をもとにマップを擬似的に作成したものである。 \begin{figure}[h] @@ -680,8 +902,33 @@ \end{center} \end{figure} - \subsection{実験} - なにをどう比較すればいいのか思いつかないので実験が進みません。\par + \section{本システムの有効性} + 以上の点を踏まえ、本研究で提示した問題に対する本システムの有効性を記 + 述する。 + + \subsection{災害時の避難状況の視覚的な確認} + 1.1や2.1で記述した通り、位置情報を発信できる情報端末が普及しているにも + 関わらず、それを用いた利用者同士のコミュニケーションや情報共有が有効に + 活用されていないことが問題視されていた。それに対し、本システムでは災害時 + を想定し、スマートフォン等の携帯端末のみを用いて利用者同士の情報を + Web上のマップに描画することで視覚的に確認できる設計を実現した。 + + + \subsection{完全に独立した設計} + \ref{apli}で記述した通り、既存の類似アプリケーションではiCloudやGoogle + アカウント、電話番号等の外部の情報を所持している必要があった。本システ + ムでは専用のアカウントを作成し、またその際にも外部の情報を必要としない + 設計を実現した。 + + \subsection{簡潔で誰でも使える設計} + 既存のシステムと比べた本システムの複数人数で情報を共有する際のグループ + 作成にかかる行程数の比較は2.1.3で記述した通りである。また、 1.1で + 記述したような既存のアプリケーションと比べ、ライセンスの購入等の必要が + ないため誰でも本システムの機能を自由に利用可能である。 + + + % \subsection{実験} + % なにをどう比較すればいいのか思いつかないので実験が進みません。\par @@ -692,9 +939,10 @@ 利用者から発信された情報を元にリアルタイムでWeb上のマップを描画するシス テムを構築した。それにより、災害時における逃げ遅れ等の二次災害の原因として問題 視されていた避難者との情報共有に関する問題を、指定した地域の避難状 -況を携帯端末から視覚的に確認可能にすることで解決した。\par -また、それにともない複数人のグループ単位で情報を共有できるシステムを構築した。 -それによってなにか解決したか具体的なことは実験をしないと書けません。 +況を携帯端末から視覚的に確認可能にすることで解決した。また、外部の情報を +必要とせず、誰でも制限なく利用できる簡潔なシステムを実現した。 +%また、それにともない複数人のグループ単位で情報を共有できるシステムを構築した。 +% それによってなにか解決したか具体的なことは実験をしないと書けません。 \section{システムへの評価と展望} 本システムへの評価と展望について記述する。 @@ -711,7 +959,7 @@ \subsection{グループ参加の有無と個人の特定} 本システムを個人でのみ利用しているユーザに関して、個人を特定する方法が完 - 全にない状態になっている。匿名性の保持と言う点では問題はないが、災害時 + 全にない状態になっている。匿名性の保持という点では問題はないが、災害時 を考えた際に個人の特定の必要性に関して懸念される。 \subsection{グループ管理のセキュリティ観点} @@ -723,7 +971,7 @@ \subsection{同時利用時のキャパシティ} \ref{bunpu}から、個人の特定を 目的としない場合の避難所から離れている利用者のばらつき等の視認性においては - 問題なく見えるが、災害時に多くの利用者が同時に利用した場合、またより人口 + 問題なく見えるが、災害時に多くの利用者が同時に利用した場合、また、より人口 の多い場合などの動作に関してプログラムを用いて摸擬的に検証する必要があ る。 diff --git a/yamagata.pdf b/yamagata.pdf new file mode 100644 index 0000000..d666458 --- /dev/null +++ b/yamagata.pdf Binary files differ