Silviase/jgov_v1.4_full_ann huggingface dataset:
模」を推定し提示するシステムは、良いツールであると考える。もちろん、時間の経過とともに、実際の災害に置き換えて動かなければ意味がないことであるが、予知無しで東海・東南海地震の規模の地震が発生した場合などは、大きな効果を発揮すると思われる。そのなかで、被害想定、応急対応需要量、応急対応項目は災害対策本部または災害対策本部員会議で参加者全員が共通認識をもって初動に取り組む際に必要なものであると思われるので、大型スクリーンなどに投影し皆で確認ができ、必要な情報を切り替えながら表示する方法が望ましいと思われる。被害想定、応急対応需要量、応急対応項目の表示は分かりやすく、表示される内容も適切であると思うが、データは細かいので、データの場所と内容をしっかり把握して会議の場で操作する必要がある。

・携帯電話による被害収集情報表示：携帯電話による被害収集情報表示画面は、携帯電話の普及率が高い現在において有効なツールであると思われる。ただし写真だけでは全てを伝えることは難しいので、メールの本文に情報を付加しその情報もあわせて表示するなど、文字による補足ができるほうが良い。

## ② 本部活動支援システムの利点、また問題点やシステムへの要求事項などについて

現在、発炎した場合は被害想定と部署ごとの応急対応項目は冊子になっているので、それを参照しながら対応を進めることになる。それに比べ会議の場で、「災害状況」「各部署の初動」について共通認識が図れる、本部活動支援システムは非常に有効なツールである。なお、愛知県内の市町村には防災無線の回線を利用した高度情報通信ネットワークが配備されており、県からの指示や連絡はこの端末を行われることになっているので、高度情報通信ネットワークも含んだ表示が行われるほうが良いと考える。

・被害想定システム：被害想定は、分かりやすい表示がされており、防災対策課の職員だけでなく、本部に集う職員は感覚的に被害の程度を把握できると思われるが、被害想定で豊橋市の人口のデータが少なかった。少し前のデータであると考えられるので、できるだけ最新の人口データに更新していただけるとより良い。また市が想定している被害想定結果とシステムから提示される結果が異なっており、双方の結果の整合がとれるとよい。

・システム立ち上げ状況・避難所開設状況：開設する避難所の数が少なければ今回の表示でよいのかもしれないが、本市の場合は第一指定避難所が70か所、第二指定避難所が90か所もあるため、多くの避難所を分かりやすく表示するための方法を工夫する必要がある。例えば地図でエリアごとにアイコンの色分け表示したり、一覧表で表示したり、開設している避難所だけを大きく（又は上段に）表示させるなど。また配備状況・避難所開設通知のシステムにテンキーがついていると非常に便利だと感じる（配備人数、避難者人数の入力など）。

## ③ 災害専用電話班による受付情報の処理、関係班への伝達、措置経過報告の把握に対する支援システムの利点、また問題点や要求事項などについて

これまで、市では避難所を同時に多数開設するような大規模災害に遭遇した経験がないため、避難所からの被害情報の集約は、あまり想定していない。しかし、もし大規模災害が発生した場合は、市民からの電話の対応と同様に、エクセルで集約・整理をすることになると思われる。今回の情報の整理は専用のソフトを使用していたようであるが、エクセルとどこがどのように異なるのか理解できていなかったため、詳しく評価することはできないが、習熟・使用という点から考えると、エクセルのように使い慣れたソフトで何とかすることも悪いことではないと思われる。そういった先入観も踏まえてみると、エクセルと比べ表示では圧倒的なメリットは感じなかった。しかし、災害対応においては、各課で共通のデータを使いながら災害対応にあたるべきであり、必要なデータを各課とやり取りするようなシステムなので、エクセルよりも有効性は高いと考える。ただし、通常業務では使わないソフトであるから、担当職員を決め、使い方を熟知しておくような訓練の実施が必要であると考える。

・大きな問題点は感じなかったが、情報の重複を防ぐ意味でも住所表示から地図を表示するしくみなどはあっても良い。

## ④ 避難所及びその周辺の状況確認、指示等の伝達でのWebカメラやIP電話等の利点や問題点・要求事項について

·Webカメラ：相手の状況が画像で分かるため、現有の音声による情報のやり取りと比較して、迅速・的確な状況確認や円滑な指示等の伝達が可能になると考える。ただし、カメラのある場所の状況しか表示することができないため、「見えている範囲では」ということに留意する必要がある。その点ではNTT DOCOMOのFOMAによる動画送信のように機動力が高くなると、より効果を発揮すると考える。

· IP電話：同報無線のように1対複数の交信が可能なので、一斉通報システムと組み合わせることで、大規模災害時の被害把握に効果を発揮すると考える。

・災害時に箱からWebカメラやIP電話・FAXを出して設置していたが、実際には、普段の業務においてその機械を使用し、災害時にはその機械をそのまま利用すればよいようにしておくのが望ましいと思う（例えば豊
橋市の場合では地区市民館の館長・主事が使用しているPCとネットワークに接続するなど）。災害時だけの使用というのは、使用する人間の習熟度、機械の動作確認の面から考え、使えない可能性が考えられる。また、性能の進化が早い（＝陳腐化するのも早い）IT製品を、更新期間が長くなりがちな行政が導入すべきなのかという根本の問題も検討されるべきである。

・箱から出した電話機、ファックス、Webカメラなどの接続についても、分かっている者は無意識のうちに簡単につないでしまうが、慣れてない者にとっては、どのジャックをどこにつなぐのか非常に困るであろう。また、LANケーブルは「どこに」差しても良いというのは、分かりやすいようでいて、実は不安にさせることなのではないかとも考えてしまった。つまり、何をどこにつなぐのかを分かりやすくするために、「説明書を人れる」または「色の付いたシールを貼っておき、同じ色同士をつなぐ」などの工夫が必要なのではないかと思う。

## ⑤ 避難所からの被害情報・避難情報等の集約、整理に係る本部活動支援システム等の利点や問題点・要求事項について

市全域で大きな被害が出た場合、数多くの避難所が開設されると考えられる。その際に、避難所の状況をどのように把握するのかは大きな問題になる。防災無線又は電話で情報を得ようとすると、情報（例えば避難所開設状況、避難者数など）を70か所から得ようとするとそれだけでも1時間かかってしまうと思われ、音声だけの情報のやり取りは効率が悪い。またファックスは、出力に時間がかかるので、例えば1か所から5枚のファックスが届くと、70か所でやはり受信は1時間くらいかかるであろう。さらに災害対策本部には紙が山積みされ、それの仕分けもかなり苦労すると思われる。

・ファックスの発信場所、記入者、時間、送信枚数とページ数など分類・整理をするための要素が不足していたため、実際の受信では仕分け、整理などが面倒であった。もしファックスを利用するのであれば情報をさらに集約整理したものを送るなどの検討が必要である。

上記の解決策として情報表示システムがあるものと思われるが、もう少し情報の種類を増やし、「○×」と10キーの入力ができれば（さらにそれが電卓の表示のように小さな画面にでも出れば）、簡単でありながら送れる情報の内容が充実しファックスの利用度が減ることが考えられる。また、一斉通報システムと情報表示システムを組み合わせれば、避難所の情報を素早く、簡単に把握できると考える。

·避難所から各町で集めた情報をそのまま本部にファックスで送ってきたため、本部に届くファックスの枚数がかなりあった。送信場所が2か所でも枚数が多かったのだから、全市的に被害が出た場合、ファックスの枚数は莫大なものになるため、送信方法の検討が必要であると思う。また、ファックスは印刷に時間がかかるので、早い出力装置が必要だと思う。さらに、送信元を記入する欄をファックス用紙にあらかじめ作成しておく、できるだけ送信枚数を減らすなどの工夫も必要である。

・被害・避難者情報の提示方法等については理解しやすかったものの、広域表示の場合に道路や鉄道などが表示されていなかったためわかりにくかった。

⑥ 避難指示等の意思決定に係る情報の提示方法、表示による理解度、シミュレーション結果の精度（リアルタイム更新）、計算速度、操作性、総合的な評価（意思決定支援ツールとして使えるか）について

・延焼シミュレーション：人口密集地の中にある避難所が今後も避難所として利用できるのかを検討する材料として、火災延焼シミュレーションは有効であると考えられる。ただし、火点が多数になった場合、それをどのように入力・処理するのか、時間が経過したあとのシミュレーション結果と実際の延焼状況との整合性はとるのか（時間が経つにつれて、予測と実態はある程度ずれてくる可能性がある）といった問題はあると考える。また、ランドマークの少ない場所の地図をアップにした場合どこを表示しているのか分からないので、地名を入れるなど工夫が必要である。

・避難シミュレーション：避難路の実際の状況を確認しているわけではないので、そのルートを避難ルートとして案内することには不安が残る。参考として出すなら地元の経験の方が勝るのではないかということも考えられ、地域住民に説得力のあるルート提示にはならないのではないかと感じた。また、要求から表示までの時間がもっと早いとなおよい。

交通シミュレーション：交通の状況は、地元住民にとっては程度想像がつくものであること、現場を確認しているわけではないこと（災害時に道路の状況把握までできるかどうか？）、状況が短時間で変化する場合もあることなどが考えられるため、あくまでシミュレーションの域はでいないように感じた。また、要求から表示までの時間がもっと早いとなおよい。

⑦ その他、総合的な評価、システム等への要求事項、またシステムの改良に向けたアドバイスなどについて・電源の問題：このようなIT機器を導入し、大規模地震が発生した場合、市役所は非常用電源があるので機器を稼動させることができるが、各避難所には非常用電源がないので、災害時の電源の確保を考える必要がある。また、購入するにも、発電機や非常用電源は高価であり、また発電機は定期的な運転と確認も必要な
「維持に手のかかる」機械である。このような機械を160か所の避難所に展開することは事実上不可能であると考える。そのため、別の電源を検討する必要がある。自動車の12 Vをつないで、これらの機器が動くような仕組みを考えるなど、簡単にこれらの機械が動く電源を確保することも大きな課題として検討いただきたい。

ハードウェアの活用の問題：これらIT機器を災害専用として保管しておくことは、コスト、熟練度、機器の稼動確認などの点から問題があると考える。通常業務のなかで普段から使用し、行政のインフラのひとつとして活用されているものを、災害時には災害用のソフトを起動させて使うような構成が必要である。

ソフトウェアの熟練度の問題：今回の訓練では、普段からこのようなシステムの開発に携わっていて、なおかつ普段からもコンピュータに習熟している方たちが操作したが、実際に発炎したときには、パソコンといえばインターネットとエクセルとワードしか使ったことのないような人が操作をすることが考えられる。また、本部活動支援システムは普段から使うソフトではないため、それぞれの使い方ができるだけ分かりやすく、また分かりにくい部分をヘルプファイルなどで補えるような初心者でも使えるソフトウェアにしておく必要がある。

・本実験で提案した仕組みの有効性：現在の市が持っている情報収集・伝達手段についてみると、有線電話は災害時優先の回線のみ使えると考えた方がよい。防災行政無線・地域防災無線は、非常用バッテリーはあるが、何日も持つような蓄電量ではない、アマチュア無線はどこまでつかえるのか不明（本庁にはあるが、避難所にはない）である。これらを踏まえると、市の一部の地域から被害の一部が伝わってくるだけで、全貌が把握できないことが十分考えられる。また、防災行政無線・地域防災無線が使え（＝電気が使える）、市内全域で被害が発生し160か所の避難所が高い割合で開設されたとすると、各避難所の状況をまとめるだけでも相当の時間がかかることが分かる（何らかの情報を得ようとすると、1分／簡所かかるとしても1～2時間が必要）。つまり大量の情報を収集・伝達するような仕組みにはなっていないのが現状である。今回の実験では、大規模災害が市全域を襲った場合の情報収集手段の方法として、避難所を校区の情報収集・伝達拠点としているが、面積の広い豊橋のような場合には非常に有効な方法であると感じた。特に発災直後の情報が少ない中、できるだけ多くの情報を市全域から収集しようとした場合には、市民館を情報収集・伝達の拠点とすれば、それだけ多くの情報を早く確実に得られることを実感した。ただし、そのためには避難所との情報連絡手段が現在よりも太く確実なバイブである必要がある。しかも、同時に多くの情報を交信し、処理する仕組みが求められる。そのためには今回実験したような仕組みは非常に有効であると考える。

・本実験で提案した仕組みの課題：IT機器は進化のスピードが速く、一方安定度を欠いている部分がある。今回実験で使ったシステムは現在の最先端のものであるが、10年後には陳腐化されていることはほぼ間違いなく、簡単に進入しやすいネットワークになっていたり、ソフトウェアがサポートされていなかったり、部品がなかったり、そうしたことにもなりかねないというアキレス腱を持っていると考える。一方現在の行政が求めているシステムは進んだシステムより安定したシステムである。ある意味「枯れた」システムと言えるかもしれない。長期にわたって安定したシステムができれば、非常に心強いものであると考える。また、コスト、電源といったこともクリアすべき課題であると考える。

## (3) 地域住民への情報提示

① 避離所周辺や市全域の被害状況・避難状況に係る情報の提示方法、表示による理解度、提示した情報の内容、システムの操作性に関する問題点や要求事項などについて

・複数のアイコン（火災、建物被害等）が同時に表示されたときは、被害の多さはすぐ理解できたが、状況を解釈しイメージするには少し時間がかかる。

・地図を表示して説明できたので内容を伝えやすく、また住民も理解できていたように感じた。

・人力した情報がすぐにアップされず、表示されるのに時間を要した。こうした状況になった場合、当システムを熟知していないと表示された情報がいつ時点のものか、正しい情報なのか、判断にまようかもしれない。

## ② 火災の延焼拡大予測について

·火災情報表示は比較的容易に理解でき、状況説明、指示等も行えた。

・粘度については、今回のレベルで充分である。

・実際に消火活動を行った結果が反映されるとよい。

・現状では難しいと思うが、飛び火による延焼予測が考慮されるとよい（なお、飛び火による火点情報が入力された場合には延焼予測は本システムでも可能であると説明）。

## ③ 広域避難、要援護者の搬送について

・避難経路はわかりやすく、十分理解できたと思われるが、実際の状況がわからないため、この結果を信じきってよいのかが不安である。

・表示される経路の情報数が増えると、どれがどの情報かがわかりにくかった。

・代替避難経路等を表示する操作方法がわからなかった。

④ 災害対策本部からの情報の入手・確認について
システムへの要求事項は特にないが、避難所にいる住民にどこまで情報を提供するのか、どの時点でどういう情報を提示するのか、検討する必要があるが、住民が報告した情報への対応については最低限住民側へ提示する必要があろう。

⑤ その他、総合的な評価、システム等への要求事項、またシステムの改良に向けたアドバイスなど

・訓練として考えた場合、今回の実証実験で住民の防災意識が高まったと思う。

・住民と協働した情報収集は災害時に防災関係機関の対応も迅速に行える。

・システムを導入する場合、校区・避難所数が多いため、

費用の問題が発生する。

・大規模災害時における電力遮断時の対応（パッテリー、発電機）。

・入力に要する時間については慣れで一定の短縮は可能であるが、情報が多い場合処理するための時間又は人的負担が必要になる。

今回の実験で被害情報入力表示システムを利用して情報収集・伝達・住民への提供等行ったが、人力操作は容易であった。しかし、実際に入力を行う職員は普段から訓練（練習）しておかないと扱えないものになってしまう。

ハード面から見ると、機器が多く配線も多いため、設置等が容易に行えるか不安。普段からの設置を考えても現実を見ると難しい（市民館等は普段の余裕スペースはあまりない）。

・校区拠点で扱える機能をある程度制約し単純化したほうがよい。また画面上の表示もすっきりさせたほうが操作しやすい。

大規模災害時には記録（災害の記録、災害史など）をとることが必要であり、発災から災害対応、復旧全てにシステムが活用でき、そうした記録、情報を整理できるようになるとよい。

・現有の119番通報システムとの連携ができるとよい。

### 2. システム開発者から見た今後の課題

豊橋市市職員へのヒアリング、アンケートに加え、システム開発者（著者およびプログラム開発業者）に対して実証実験を通してみたシステムの今後の課題についてヒアリングを行った。その結果をまとめると、

電話受付内容・判断・処置・共有を可能とするシステムでは、緊急に対処すべき重要事項が容易に見てとれる表示（大きく、新規のものは点滅などの工夫）とすべきである。

・情報提示システムでは、今後の被害状況の推移把握とそれに基づく的確な意思決定のため、被害集計時系列変化をグラフ化すると共に、実情報に基づく被害数の予測行う機能の開発と提示が必要である。

·避難勧告、指示のタイミングが分からないことから、訓練用としても、延焼予測とそのときの避難経路予測の履歴保存と避難の難易度のグラフ化機能が必要である。

・災害対策本部が実施すべき大局的応急対応項目の実時間自動表示機能を開発する必要がある。

・見やすく、優先度を考慮した応急需要量提示の仕組みが望まれる。

・情報提示システムでの全体被害状況表示における表示レイヤに、鉄道、道路（高速、重要道路）、河川その他のランドマークの情報を設定することが、情報リテラシー向上のために必要である。

・携帯電話による情報収集において、GPSデータに基づき収集経路の軌跡を表示する機能が必要である

・各システム運用者間の連絡のため、Web掲示板やチャットシステムのような文字ベースの連絡ツールがあるとよい。

・情報の流通を検討し応急対応を円滑化するため、情報の流れを保存するログ機能と、それらを分析できる機能を開発する必要がある。

・情報共有化技術については、DBからのデータの入出力、特にシミュレーション結果の参照、参照データの表示制御などについては操作が大変複雑になったことから、操作が直感的にわかるようなユーザーインターフェースの検討、データ管理の見直し、データ定義（スキーマ）の見直しが必要である。
# Experimental Study on Collection, Transmission, and Utilization of Earthquake Damage Information at Toyohashi City

(Abstract)

Shinsaku Zama, Makoto Endo, Ken'ichi Takanashi, Kiminori Araiba, Ai Sekizawa, Masafumi Hosokawa $ ^{*} $ , Jeong Byonpyo $ ^{**} $ , Yoshiaki Hisada $ ^{***} $ , and Masahiro Murkami $ ^{***} $

(Accepted February 5, 2008)

We performed large-scale experiments on simulating disaster information collection, transmission and on utilization for smooth responses against earthquake disaster with collaboration from Toyohashi City, Aichi Prefecture, where is considered to suffer extensive damage from the Tokai and Tonankai Earthquakes with very high probability of the occurrence.

Using disaster information collection/transmission equipments composed of long-distance wireless LAN, a notebook computer, a Web camera and an IP telephone, city staffs could easily input and transmit the information such as fire, collapsed houses and impassable roads, which were collected by the inhabitants participated in the experiment. Headquarters could confirm such information on the map automatically plotted, and also state of each disaster-prevention facility by means of Web-cameras and IP telephones.

Based on the damage information, fire-spreading, evaluation, and traffic simulations were automatically executed at the disaster countermeasure office and their results were displayed on the large screen to utilize for making decisions such as residents' evacuation. These simulated results were simultaneously displayed at each disaster-prevention facility and were served to make people understand the situation of whole damage of the city and necessity of evacuation with optimum timing and access.

According to the evaluation by the city staffs through the experiments, information technology is available for rationally implementing initial responses just after a large earthquake in spite of some improvement on the systems used in the experiments.
研究紹介

# 長距離無線LAN機器を用いた災害対応用情報通信システムの構築

高梨 健一、座問 信作、遠藤 真、新井場 公德、鄭炳表 $ ^{*} $ 、細川直史 $ ^{**} $ 、河関大祐

(平成20年1月31日受理)

市町村レベルの災害対応を目的として、長距離無線LAN機器により情報通信ネットワークを構築し、そのネットワーク上でWebカメラとIP電話を用いて情報伝達を行うシステムを提案している。

本稿では、我々が提案する災害対応用情報通信システムの概要と実証実験の結果について報告する。

### 1. はじめに

近年、情報通信技術（ICT）はめざましく進展を遂げている。従来、災害時における情報の収集および伝達の手段として防災行政無線等が用いられることが多かったが、ICTを活用することで比較的安価に通信ネットワークを構築することが可能となり、より正確な情報を、より迅速に収集し、よりの確に災害対応を行うことができると考えられる。

このような観点から、筆者らは長距離無線LAN（Local Area Network）装置やIEEE（Institute of Electrical and Electronic Engineers）802.11g無線LAN装置を用いた通信ネットワークの構築と、WebカメラやIP（Internet Protocol）電話を用いた情報伝達に関する検討を行っている。

本稿では、まず、2節において提案する情報通信システムの全体構成を示す。また、3節において、提案システムの特徴について紹介するとともに、4節において平成18年度中に行った実証実験の結果について報告する。また、最後にまとめと今後の課題について述べる。

図1 全体システムイメージ図
### 2. システムの全体構成

提案するシステムの全体構成を図1に示す。本システムは、システム全体の基幹として長距離無線LAN装置を中心としたIP通信可能なネットワークを構築し、そのネットワーク上でIP電話やWebカメラを用いた情報伝達を行うシステムである。

### 3. システムの特徴

### 3.1 長距離無線LAN装置を用いたネットワーク構築

近年、半径約50kmの範囲をカバーし最大70Mbpsの通信を可能とすることを目的としたWiMAX（Worldwide Interoperability for Microwave Access）規格など、広い範囲で高速なネットワークアクセスを可能とする技術が盛んに研究開発されている。

そのため、今回、我々は5GHz帯（4.9-5.1GHz）の周波数を用いた長距離無線LAN装置によりネットワーク構築を行うとともに面的な通信可能エリアを確保することとした。下記に、利用機器 $ ^{1)} $ の概要について示す。

なお、従来から拠点間通信を目的として18GHzや26GHzといった高い周波数を用いる無線LAN装置も市場に出回っているが、それらは現段階において5GHz帯を利用する製品に比べて高価であり、基本的に1対1通信用の機器である。市町村のように複数の拠点が点在する場合、高価な1対1通信用機器で結ぶことは、コストの増大につながるため、適切ではないと考えられる。

## (1) 長距離無線LAN裝置（1 対 1 通信用）

本装置は、ビーム幅の鋭い（6度）アンテナを用いており、およそ30kmの距離を隔てて1対1で通信を行う事が可能である。なお、設置状況により異なるものの、30kmの距離を隔てた場合のスループットは、20Mbps程度とされている。装置外観を図2に示す。

## (2) 長距離無線LAN裝置（1 対多通信用）

本装置は、およそ120度の範囲にわたって10数kmの距離を扇状にカバーすることのできる基地局と鋭い指向性（10度）を持つ加入者局から構成される。基地局のカバーする扇状の通信範囲に存在する複数の加入者局との間で1

图 2 長距離無線LAN裝置（1 対 1 通信用）外観

対多の通信を行うことにより、多点間のIP通信網を構築することが可能である。

基地局－加入者局間の通信にあたって、変調方式を64QAM（直交振幅変調：Quadrature Amplitude Modulation）から16QAM、QPSK（四位相偏移変調：Quadrature Phase Shift Keying）、BPSK（二位相偏移変調：Binary Phase Shift Keying）まで無線の状況に応じて自動的に変更することにより、安定した通信を行うことが可能である。機器の外観を図3に示す。

なお、本装置を利用するにあたって、下記の点に留意する必要がある。

・加入者局は受信強度により通信相手の基地局を自動選択する機能を持っている。そのため、中継用に基地局と加入者局を近くに設置すると、局所的にループを形成して通信ができなくなる場合がある。

長距離通信を目的としているため、装置から出力される送信電力が大きい。そのため、設置した機器間の距離が近すぎる場合には、機器間での干渉が起きる場合や、入力電力が大きすぎて信号を正しく受信できなくなる場合がある。

・利用している周波数帯が5GHz帯であるため、電波の直進性が高い。そのため、建物の影や山陰などに不感帯ができやすい。

これらのことから、通信相手や利用周波数について事前の計画を立てるとともに、近距離の通信にはIEEE802.11規格に準拠した無線LAN機器と組み合わせて利用するなど方策を検討する必要がある。

### 3.2 Webカメラを用いた情報収集

Webカメラは、撮影した映像をTCP/IPネットワークを通じて送信することができる装置である。近年、Webカメラにも、赤外画像を撮影可能なものや360度回転可能なもの、高倍率ズームが可能なものや屋外設置を想定した防水仕様のものなど、様々な機能を持った機器が開発・発売されており、遠隔監視など様々な目的で活用されている。Webカメラの価格は、その機能により上下するため

图 3 長距離無線LAN裝置（1 对多通信用）外観

(左：長距離無線LAN裝置基地局 右：同加入者局)
め、利用環境に応じて必要な機能を持つWebカメラを選択することで、効率的にシステムを構築することが可能である。

また、我々は、災害時においても確実な動作を期すために、屋外での利用が想定されるWebカメラについては下記のカメラドームと組み合わせて利用することとした。

## (1) 屋外用力メラドーム

災害時、災害発生地点に臨時にWebカメラを設置するためには、当然のことながらWebカメラを動作させるための電源が必要である。さらに、設置簡所が屋外である場合には、降雨や降雪を考慮しなければならず、Webカメラのみならず電源回路についても確実に防水できる手法が必要である。このことから、我々は、図4に示す屋外用カメラドームを用いることとした。

このカメラドームは、Webカメラを内部に格納することができ、電源回路およびLAN回路もドーム内に収納されているため、雨天でも活用可能である。また、上部は半球状の透明なカバーであるためWebカメラの視界を遮らずに撮影可能であり、通常の三脚に収り付けることも可能なため、可用性に優れたものとなっている。

## (2) 車載用カメラドーム

災害が発生した場合や災害が発生するおそれがある場合には、発生地点または発生予測地点へ退速に駆け付けて状況を画像により伝送することが、防災対策上、有効であると考えられる。その際、両にカメラドームを取り付けておくことができれば、移動中の映像を記録することも可能となり、また、現場に駆け付けると同時に画

図4 屋外用カメラドーム

像の撮影を開始することが可能となると考えられる。そこで、我々は、図5に示す車戯用カメラドームを採用することとした。

車載用カメラドームも、屋外用カメラドームと同様に降雨や降雪の際の利用を想定する必要がある。この車載型カメラドームは、電源およびLANケーブルを内部へ引き込む部分に防水コネクタを使用しており、雨天でも活用可能である。

また、この串戯用カメラドームは、シート状の強力磁石により自動車の車体に取り付けることができ、更に、電源として自動車のシガーライタを用いることも可能なため、走行中でもWebカメラを動作させることが可能となっている。

### 3.3 IP電話を用いた情報伝達

IPネットワークは、そもそも、IPパケットを送受信するためのネットワークであり、IPパケットに格納されていればデータの種別を問われない。そのため、同じIPネットワーク上に画像情報や電子メール、データベースのクエリなど様々な情報を流すことが可能である。

IP電話は、その名のとおり、IPネットワーク上で実現された電話アプリケーションであり、インターネットの普及に伴い一般家庭における活用も進んでいる。また、その一方、企業や学校等においても拠点間の通話をIP電話に切り替えて経費削減を行う事例や、広域内線網の構築に利用される事例など利用が拡大している。

我々の提案するシステムにおいても、長距離無線LAN装置によりIPネットワークを構築していることから、IP電話を利用することも可能である。そこで、我々は機能而から検討を行い、図6，7に示すIP電話システム $ ^{2)} $ を導入することとした。

呼制御サーバは、ネットワーク上の電話番号とIPアドレスの対応を管理する装置であり、端末間の通信を制御する機能を担っている。また、マルチキャストサーバは、マルチキャストルーチングプロトコルの一种であるIGMP

図5 車載用カメラドーム
图 6 IP电话装置

(呼制御サーバ（上）、マルチキャストサーバ（下）)

图 7 IP电话装置

(Internet Group Management Protocol) v2 (バージョン2) $ ^{3)} $ を用いて、マルチキャストグループに登録されたIP 電話端末に対してIPパケット化された音声を配信する機能を持っている。マルチキャストグループの内容を適切に設定することにより、様々なグループに対して同報通信を行うことが可能である。なお、当然のことではあるが、同報通信を利用するためには、ネットワークを構成する機器（ルータ等）がIGMPv2に対応している必要がある。

IP電話端末は、IPパケット化された音声データを再生する機能を持つとともに、通常のアナログ回線のポートも備えており、通常の電話機やファクシミリを接続することも可能である。

### 3.4 無線LAN移動局による迅速な駆け付け

3.2節(1)においても触れているが、災害発生地点や災害発生予測地点に迅速に移動して画像伝送を行うことは、

図8 長距離無線LAN移動局の例

災害対策上、有効であると考えられる。

我々のシステムでは、車両に車戯型カメラドームを搭載するとともに長距離無線LANの加人者局を備えた、長距離無線LAN移動局を提案している。我々の利用した1対多通信用長距離無線LAN装置は面的に通信範囲をカバーするため、城内の基地局を見通せる場所からなら簡易に通信を確保することが可能である。

図8に消防研究センターの公用車を用いて構築した長距離無線LAN移動局の例を示す。

### 3.5 移動型ハイブリッド電源装置を用いた無人監視

例えば、堤防の決壊が予想される箇所などに臨時に通信局を設備し、危険箇所の状況をリアルタイムに災害対策本部に伝達することができれば、効率的かつ有効な災害対応を行うことが可能となると考えられる。しかし、安全性の観点からみると被害発生予測地点に監視員がとどまって監視を行うことは避けるべきであり、無人で長則に監視を続ける体制を構築することが有効であると考えられる。

図9 移動型ハイブリッド電源装置外観
図10 移動型ハイブリッド電源装置 電源 ボックス内部

このことから、我々は、現地で簡易に組み立てが可能であり、なおかつ鉛蓄電池に加えて風力発電機と太陽電池パネルを供えて長期に電源を供給できる装置として、移動型ハイブリッド電源装置を試作した。移動型ハイブリッド電源装置の外観を図9に、電源ポックス内部を図10に示す。

電源ポックスには、鉛蓄電池のほか、風力発電装置や太陽電池パネルを接続するための端子板、さらにAC100Vの電源を取り出すためのインバータを収納する。また、電源ポックスは側面にケープル引き込み口を持っており、降雨の場合にも活用が可能である。

この装置と監視機器および長距離無線LANと組み合わせることにより、長期間にわたり危険箇所の監視を無人で行うことが可能となる。

## 4 ．新潟県見附市における実証実験

我々の提案する情報通信システムの有効性を検証するため、平成18年10月27日に行われた新潟県見附市の水防訓練の際に実証実験を行った。実証実験において構成したネットワークを図11に、地理的な配置状況を図12に示す。なお、見附市役所屋上に設置した1対多用長距離無線LAN装置基地局が水平角120度の範囲をカバーすることから、アンテナの方向を調整するとともに長岡地域振興局屋上に1対多用長距離無線LAN装置加入者局を設置してバックアップ回線を構築した。このため、実際には、見附市役所一長岡地域振興局間には二重の回線が設置されている。

また、災害対策本部や防災拠点、さらに災害発生場所を想定して、見附市役所、総務省消防庁、名木野小学校屋上、嶺崎橋、長距離無線LAN移動局にWebカメラを設置した。このうち、名木野小学校屋上と嶺崎橋については屋外用カメラドームを用い、長距離無線LAN移動局には車載用カメラドームを用いた。Webカメラからの映像は、長距離無線LAN装置を用いて構成した無線ネットワークを利用して伝送し、災害対策本部に設置したPCの画面上表示するとともに、プロジェクターを利用してスクリーン上に投影することとした。

まず、長距離無線LANの性能を検証するために、通信距離の最も長い（約11km）見附市役所－長岡地域振興局間においてスループットを計測した。その結果、1対1通信用長距離無線LAN装置では、実測値で約37Mbpsのスループットを得た。また、バックアップ用に敷設した1対多通信用無線LAN装置では、加入者局から基地局への通信において平均25.4Mbps、逆方向の通信では平均

図11 新潟県見阳市実証実験におけるネットワーク構成図
17.6Mbpsのスループットを得た。

また、カメラ画像の伝送実験として、無線LAN移動局を用いて観音山公園、見附運動公園、農道上の3カ所から見附市役所屋上に設置した基地局と通信を行ってカメラ画像の伝送を行うとともに、各所に固定設置したWebカメラからの映像を災害対策本部で確認し、十分な性能を有していることを検証した。

その一例として、図13に嶺崎橋に設置したWebカメラで撮影した画像を示す。嶺崎橋では、中央の橋脚に危険水位などを示すカラーバー表示がなされており、Webカメラの映像からそれらの水位に達しているか否かを容易に判定できることがわかる。

水防訓練後の市担当職員へ直接行ったヒアリング調査では「長距離無線LAN装置とWebカメラによる水位監視は極めて有用である」との評価を得た一方、防災科学技術研究所が訓練に参加した市職員に対して行った長距離無線LANの有効性についてのアンケート $ ^{4} $ の結果では、「通信の輻軼がなく画像が送信できれば有効」、「防災拠点を直接つなぐシステムとして有効」、「通信が安定していれば有効」という回答であった。

図12 平成18年10月27日新潟県見附市実証実験における全体配置図
このような対照的な回答となったのは、市担当職員には実際にカメラ画像を見てもらうなど十分な情報が与えられていたのに対し、実証実験のシナリオではカメラ操作がなく加工した写真を提示したため実際のカメラ映像がどのようなものとなるかを市職員が認識していなかったことが原因と考えられる。

### 5. おわりに

本稿では、我々の提案する災害対応用情報通信システムについて述べるとともに、平成18年10月に新潟県見附市で行った実証実験の結果について述べた。

今回採用した長距離無線LAN装置は比較的安価であり、設置も容易であることから、災害時の通信確保に有用であると考えられる。ただし、長距離無線LANの設置には、アンテナの固定場所や方向などの情報と電源が必要であり、それらに関する情報を事前に把握しておくことが望ましい。

また、今回の実験では、設置したネットワークのスループットが充分大きかったためWebカメラがその性能を発揮したが、ネットワークの構成次第では一部の回線もしくは機器にデータが集中して状況を十分に伝えられない可能性も考えられる。このことから、敷設にあたってはネットワーク上を流れるデータの量にも考慮して、効率的な運用を行う必要がある。

本研究は振興調整費「危機管理対応情報技術による減災対策」(平成16～18年度)の成果の一部である。

図13 Webカメラによる映像の例

## 参考资料

1）Alvarion社、“BreezeACCESS VL 4.0,”

http://www.alvarion.jp/solutions/government/products

/breezeaccessvl/

2）株式会社エイツー、“LANdeVOICE,” http://www.a-2.co.jp/LANdeVOICE/index.html

3）W. Fenner, “Internet Group Management Protocol, Version 2,” RFC2236, 1997年11月

4）平成18年度科学技術振興調整費「危機管理対応情報技術による滅災対策」成果報告書，2007
# A Construction of the Information System for Disaster Management using Long-Distance Wireless LAN Equipment

(Abstract)

Ken-ichi Takanashi, Shinsaku Zama, Makoto Endo, Kiminori Araiba, Byon-pyo Jeong $ ^{*} $ , Masafumi Hosokawa $ ^{**} $ and Daisuke Kozeki

(Accepted January 31, 2008)

We are proposing an information system for disaster management activity, on which network is constructed by long-distance wireless LAN equipment and is used for information exchange by using Web camera systems and IP phone system. In this paper, we introduce the outline of our system and the result of the experiment.
解說

# GPS測位データを用いたデジタルカメラ写真の整理と活用

河閔 大祐

(平成20年2月8日受理)

デジタルカメラとデータロガー付きのGPSレシーバを携行して記録した、災害調査等の写真とGPSログデータを用いて、写真ファイルに撮影時の位置情報を格納するための処理方法を示す。さらに、GPSログデータとデジタルカメラの画像ファイルを用いて、Google マップならびにGoogle Earthの画面上に、移動の軌跡、写真撮影地点と写真を表示する処理方法を示す。どちらの処理も、Windowsコンピュータおよびフリーソフトウェアで実行できる。地図上に写真を表示する表現方法は調査報告の際のプレゼンテーション資料や写真の整理・保管の手段として活用することができる。

### 1. はじめに

災害調査等における写真撮影は、災害状況の記録のために欠くことができない。しかし、撮影した写真の撮影日時や場所が明確でないと記録資料としての価値を逸する可能性がある。そのため、調査の後で写真ごとに撮影日時と場所を整理する必要があるが総じて時間を要する。特に、場所の特定は、写真撮影時の調査メモや行動の記憶、写真に写り込んだ建造物や地形などから推定する方法が一般的であるが、推定不能な場合もある。

この写真の撮影日時と場所の特定作業を軽減する物として、GPS（Global Positioning System）と電磁コンパスを内蔵したデジタルカメラが市販されている。このカメラを用いると、撮影日時と撮影場所の緯度経度、撮影の方向が响像ファイルの中に理め込まれる。撮影した日時、場所および撮影方向の特定ならびに画像ファイルの整理は、撮影後、カメラに付属するソフトウェアで処理を行うことができる。しかし、GPSや電磁コンパスを内蔵したデジタルカメラは高価であり導入は容易ではない。そこで本稿では、災害調査に一般的なデジタルカメラとデータロガー付きのGPSレシーバを使用し、後刻、写真ファイルとGPSデータファイルをPC上で処理することにより、正確な撮影日時と撮影場所の緯度経度が格納された写真ファイルを簡便に作成する方法を示す。さらに、調査報告等において現場状況の理解を深めることに資する、写真つきの地図を作成する方法を示す。

解説は以下の順に述べる。

第2節 デジタルカメラの写真ファイルフォーマットと GPS測位データ

デジタルカメラの写真ファイルフォーマットの概要と、GPSレシーバの即位調差、測地系の解説。

## 第3節 Exif撮影時刻の修正

撮影日時の信頼性確保とGPSログデータとの照合に必要な、写真ファイル内に格納された時間データの修正方法の解説。

第4節 Exif7 ルへの位置情報の格納

写真ファイルに撮影位置情報を格納する方法の解説。

第5節 地図上での写真および撮影位置の表示

Googleマップに写真撮影位置と写真を表示する方法の解説。

2．デジタルカメラの写真ファイルフォーマットとGPS測位データ

### 2.1 Exifファイル

現在普及しているデジタルカメラは撮影した写真データをExif (Exchangeable image file format) $ ^{1)} $ と呼ばれるファイルフォーマットで記録する。Exifは、デジタルカメラメーカが提案して旧（社）日本電子工業振興協会（JEIDA）（現社団法人電子情報技術産業協会（JEITA））で規格化されたデジタルカメラ用の写真フォーマットであり、写真を構成する画素データの他に、カメラの機種等の諸元、撮影日時、露光条件ならびに撮影位置等の撮影情報を格納するための書式 $ ^{2)} $ が定められている。Exifの撮影情報はデジタルカメラ写真表示ソフトウェアやExif情報表示ソフト $ ^{*1} $ で
閲覧できる。また、Windows-XPコンピュータであれば、写真ファイルのプロパティ表示でExif情報の一部を閲覧できる（図1参照）。Exif規格は、写真撮影位置情報としてGPS測位情報を格納することを前提に、表1の書式を規定している。表1の中で、タグ番号1～6が撮影位置に関する情報である。タグ番号16～17の撮影方位は1台のGPSレシーバでは測位不能である。タグ番号19～26は、被写体の位置、撮影地点からの距離および方位であり、撮影者が携行するGPSレシーバからデータは得られない。

ところで、ExifファイルはJPEGフォーマットもしくはTIFFフォーマットでもある。そため、Exif非対応の画像ソフトでも画像を扱うことはできるが、データを上書き保存するとExif情報が欠落することがあるため注意が必要である。

### 2.2 GPS測位データ

GPS機能のないカメラで写真撮撮影位置情報を取得するには、GPSデータを時系列で受信・記録するロガー機能のついたGPSレシーバが必要である。ロガー機能付GPSレシーバには、図2に示すような様々なものが市販されているが、GPSレシーバ1台を用いる単独測位ではGPS衛星の軌道誤差やGPS信号の電離層遅延誤差等の影響を受けるため、位置測定には10m程度の誤差の生じる可能性がある $ ^{3} $ 。また、建物や地表からの反射波を受信すると、さらに大きな誤差を生じることがある。

GPSレシーバで記録されるデータのうち写真撮影位置に使用できるデータは、緯度、経度および高度の測位データならびに測位時刻である。電磁コンパスを内蔵したGPSレシーバでは方位データを記録するものがあるが、カメラとGPSレシーバが機械的に固定されて一体化していなければ写真撮影方位のデータとして使用することはできない。

GPSレシーバで得られる緯度経度データは、WGS84と呼ばれる世界測地系の座標値である。一方、日本の国土地理院の地図には、改正測量法が施行された2002年4月1日を境に、施行以前の旧日本測地系（Tokyo Datum）で緯度経度が表示されたものと、施行後の、「日本測地系2000（JGD2000 = Japanese Geodetic Datum 2000） $ ^{4} $ 」と呼ばれる測地系で緯度経度が表示されたものが混在する。JGD2000はWGS84とほぼ等しいため、GPSで測定した緯

表 1 Exifで規定されるGPS測位情報書式

タグ	タ グ 名	内 容
0	GPSVersionID	GPSタグのバージョン
1	GPSLatitudeRef	南緯・北緯
2	GPSLatitude	緯度(度、分、秒)
3	GPSLongitudeRef	東経・西経
4	GPSLongitude	経度(度、分、秒)
5	GPSAltitudeRef	高度の単位
6	GPSAltitude	高度(m)
7	GPSTimeStamp	GPS時間(原子時計の時間)
8	GPSSatellites	測位に使用したGPS衛星
9	GPSStatus	GPS受信機の状態
10	GPSMeasureMode	GPS測位モード(2次元、3次元)
11	GPSDOP	測位信頼性
12	GPSSpeedRef	速度単位
13	GPSSpeed	速度
14	GPSTrackRef	進行方向の基準(真方位、磁気方位)
15	GPSTrack	進行方向(度)
16	GPSImgDirectionRef	撮影方向の基準(真方位、磁気方位)
17	GPSImgDirection	撮影方向(度)
18	GPSMapDatum	測位に用いた地图の測地系
19	GPSDestLatitudeRef	目的地の南緯・北緯
20	GPSDestLatitude	目的地の緯度(度、分、秒)
21	GPSDestLongitudeRef	目的地の東経・西経
22	GPSDestLongitude	目的地の経度(度、分、秒)
23	GPSBearingRef	目的地の方角の基準(真方位、磁気方位)
24	GPSBearing	目的地の方角(度)
25	GPSDestDistanceRef	目的地の距離の単位
26	GPSDestDistance	目的地の距離

*1 Exif情報表示ソフト：例えばJpegAnalyzer（http://homepage3.nifty.com/kamisaka/）
図1 Windows XPのExit情報表示例

度経度をJGD2000の地図に適用すれば正確な位置があてはまる。しかし、WGS84の緯度経度をTokyo Datumの地図に適用すると、数百m程度の誤差を生じる。インターネットの地図検索サイトにおいても表2に示すとおり測地系が分かれるため注意が必要である。図3は、消防研究センター通用門位置で、ハンディGPSを用いて得られたWGS84の緯度経度（北緯35度40分27.8秒、東経139度33分49.6秒）をTokyo Datumの地図を用いる地図検索サイトMapion*²に適用した例であるが、位置が北西約470mずれることがわかる。なお、Tokyo Datum（旧日本測地系）の緯度経度とJGD2000（日本測地系2000）の緯度経度を双方向で変換できるプログラム*³が同土地理院から提供されている。なお、第5節で述べる撮影位置の地図表示ではWGS84のGoogle マップを用いる。一部のGPSレシーパには測地系変換機能を有するものもあるが、緯度経度はWGS84で記録することを働める。

一般的に市販されているGPSレシーバのデータの記録方法は、進行方向の変化毎、一定時間間隔毎、一定距離毎などの方法がある。この方法のうち、写真撮影時のGPSデータを参照するためには一定時間間隔毎の記録が適する。記録時間間隔の日安は、経験から、徒歩移動の

図2 ロガー機能付GPSレシーバの例

場合で15～30秒、自動車移動の場合で5～15秒程度が適度であると考える。
### 3. Exif攝影時刻の修正

写真ファイルとGPSログデータの照合は、Exifデータ内の写真撮影時刻に最も近い時刻のGPSデータを参照する方法を用いる。この処理を行うためにはGPSの時刻とデジタルカメラの時計時刻が正確でなければならない。GPSの時刻は衛星に搭載された原子時計を基準としており、協定世界時（UTC）に対して $ 10^{8} $ 秒単位の精度が保たれている。一方、デジタルカメラの内蔵時計の精度は水晶時計程度であり、1日で数秒以上の誤差を生じる可能性がある。そのため、時刻修正を長期間行わないと誤差は蓄積される。また、日付時刻の設定を誤ると大きな誤差を生じることとなる。写真撮影時刻の管理には、撮影開始前にデジタルカメラの内蔵時計を修正する方法と、撮影後にExifファイル内の撮影時刻を修正する方法がある。後者の方法を行うのに適したソフトウェアに、Exif日付時刻情報復元ツールDe4Exif*というフリーソフトがある。このソフトウェアの「代表差分復元」機能を用いると、正確な撮影日時のわかっている写真からExif撮影日時との差を算出し、フォルダー内の全ての写真のExif撮影日時を修正することができる。正確な撮影日時のわかっている写真としては、秒まで読み取れる電波時計を撮影した写真が適する。なお、代表差分復元機能を用いる場合は、撮影期間中にカメラ内蔵時計の時刻修正を行っていてはならない。

た、カシミール3D本体は地図データを持っていないが「地図画像プラグイン」を追加すると、国土地理院が試験公開している地図閲覧サービス「ウォッちず」 $ ^{*6} $ の地形図を閲覧できる。デジカメプラグインならびに地図画像プラグインもカシミール3Dのホームページ上に公開されている。

Exifファイルへの位置情報の格納は、GPSログデータを読み込み、次にデジカメプラグインのブラウザーを起動して位置情報を格納したいExifファイルを指定した後に「GPSデータから位置を推定する」、「アイコン位置をExifとして書き込む」の順に操作ボタンをクリックすることで完了する。この操作例を図4に示す。図4は、デジカメプラグインならびに地図画像プラグインを組み込んだカシミール3DでGPSログデータを読み込んだ後、6個の写真ファイルの撮影位置をGPSログデータから推定した画面である。位置情報の格納された写真ファイルのExifデータ表示例を図5に示す。

### 4.2 GMMの使用例

GMM（本稿執筆時点ではGMM2.exeとして公開中）はGPSログデータとExifファイルを読み込んでGoogleマップやGoogle Earth上に写真表示を行うファイルを生成するソフトウェアであるが、Exifファイルへの位置情報の格納を行うこともできる。GMMは作成者のホームページ*7からフリーソフトウェアとして入手できる。なお、

### 4. Exifファイルへの位置情報の格納

GPSログデータの中からExif時刻に最も近い緯度経度データを検索して、Exifファイルに位置情報として格納する処理には、次のフリーソフトウェアが利用できる。

## ・カシミール3D

## · GMM

### 4.1 カシミール3Dの使用例

カシミール3Dは多機能な地図閲覧ソフトウェアであり、カシミール3Dのホームページ $ ^{*5} $ からフリーウェアとして入手できる。Exifファイルへの位置情報の格納を行うためにはカシミール3D本体のソフトウェアに「デジカメプラグイン」と呼ばれる機能拡張ソフトウェアを追加する必要がある。

表2 インターネット地図検索の測地系（2007年12月現在）

世界測地系 (WGS84)
googleマップ	http://maps.google.co.jp/
国土地理院・地図閲覧サービス	http://watchizu.gsi.go.jp/
(google earth)

日本測地系(Tokyo Datum)
goo地図	http://map.goo.ne.jp/
livedoor 地図情報	http://map.livedoor.com/
MapFan Web	http://www.mapfan.com/
Mapion	http://www.mapion.co.jp/
Yahoo!地図	http://map.yahoo.co.jp/
ゼンリンの詳しい地図サイト	http://www.its-mo.com/
ちず丸	http://www.chizumaru.com/