車両走行ルート表示装置
【課題】消防車両の過去の走行ルートを時系列で視認しやすく表示する。
【解決手段】本発明は、特定の場所に向かい走行する車両に関連付けて車両の位置を時系列で記憶した車両位置情報と、車両が走行し得る道路に関連付けて道路の位置を記憶した道路位置情報と、に対しアクセス可能な車両走行ルート表示装置であって、車両の位置に基づいて、道路位置情報から車両が走行する道路を抽出し、抽出した道路を表示し、表示した道路に沿って、車両を示す図形を時系列で移動させて表示する制御部を有すること、を特徴とする。
【解決手段】本発明は、特定の場所に向かい走行する車両に関連付けて車両の位置を時系列で記憶した車両位置情報と、車両が走行し得る道路に関連付けて道路の位置を記憶した道路位置情報と、に対しアクセス可能な車両走行ルート表示装置であって、車両の位置に基づいて、道路位置情報から車両が走行する道路を抽出し、抽出した道路を表示し、表示した道路に沿って、車両を示す図形を時系列で移動させて表示する制御部を有すること、を特徴とする。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、車両走行ルート表示装置に関する。
【背景技術】
【０００２】
自治体の消防業務においては、災害現場からの通報を受けると、消防車両及び救急車両が、消防署を出発し、当該災害現場に到着し、消火活動や救助活動を行ったのち、もとの消防署に戻る。当然のことながら、これらの車両が消防署を出発してから災害現場に到着するまでの時間が短いほど、人的・物的被害は少なくて済む。一般的に、当該時間は、消防署から災害現場までの距離に比例する。しかし、消防署から災害現場までのルートは、一般道路であることが殆どであり、地域・季節・時間帯による一般車両の混雑度によって、到着するまでの時間は大きく変化する。そこで、災害が発生した場合にどのルートを通って災害現場に到着するかを、過去の例を分析し日頃よりシミュレーションしておくことは非常に重要である。
例えば、特許文献１には、被介護者を介護施設へ送迎する車両が、乗車中の被介護者が発病した場合、被介護者の掛かりつけの病院まで運搬するルートを車載器に表示することと、最寄りの消防署から出発する救急車両と途中で落ち合うルートを車載器に表示することが開示されている。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２００５−５０１８３号公報（請求項２〜７）
【発明の概要】
【発明が解決しようとする課題】
【０００４】
特許文献１の発明は、まさに被介護者が発病しているその時に、一刻もはやく被介護者を病院に運ぶためには有効である。しかし、過去の走行ルートを履歴情報として保有していない。よって、災害発生前から、災害現場に最も早く到着できる消防署やルートを計画するために、さらには、交通規制や都市計画を含めた社会インフラ自体を計画しておくために、多くのルートを比較検討するようなシミュレーションには向いていない。
【０００５】
そこで、本発明は、消防車両の過去の走行ルートを時系列で視認しやすく表示することを目的とする。
【課題を解決するための手段】
【０００６】
本発明は、特定の場所に向かい走行する車両に関連付けて車両の位置を時系列で記憶した車両位置情報と、車両が走行し得る道路に関連付けて道路の位置を記憶した道路位置情報と、に対しアクセス可能な車両走行ルート表示装置であって、車両の位置に基づいて、道路位置情報から車両が走行する道路を抽出し、抽出した道路を表示し、表示した道路に沿って、車両を示す図形を時系列で移動させて表示する制御部を有すること、を特徴とする。その他の手段については、発明を実施するための形態のなかで説明する。
【発明の効果】
【０００７】
本発明によれば、消防車両の過去の走行ルートを時系列で視認しやすく表示することが可能になる。
【図面の簡単な説明】
【０００８】
【図１】本実施形態に係る消防車両走行ルート管理システムの構成図である。
【図２】本実施形態に係る位置情報履歴データの一例を示す図である。
【図３】本実施形態に係る位置情報を説明する図である。
【図４】本実施形態に係る道路情報データの一例を示す図である。
【図５】本実施形態に係る「ノード」、「道路」及び「施設」の関係を説明する図である。
【図６】本実施形態に係るルート補完の考え方を説明する図である。
【図７】本実施形態に係る位置情報履歴データ作成処理手順のフローチャートである。
【図８】本実施形態に係る走行ルート表示処理手順のフローチャートである。
【図９】本実施形態に係る走行ルート表示処理手順のフローチャート（続き）である。
【図１０】本実施形態に係る対象レコードの一例を示す図である。
【図１１】本実施形態に係る背景レコードの一例を示す図である。
【図１２】本実施形態に係る走行ルート表示画面の一例を示す図である。
【図１３】本実施形態に係る走行ルート表示画面の一例を示す図である。
【図１４】本実施形態に係る走行ルート表示画面の一例を示す図である。
【発明を実施するための形態】
【０００９】
以降、本発明を実施するための形態（「本実施形態」という）を、図等を参照しながら詳細に説明する。
【００１０】
（消防車両走行ルート管理システム）
図１の消防車両走行ルート管理システム１は、データ格納サーバ２、Ｗｅｂサーバ３、車両端末装置４及びユーザ端末装置５を有する。これらは、有線及び／又は無線のネットワーク６を介して相互に接続されている。データ格納サーバ２及びＷｅｂサーバ３は、地域の複数の消防署を統括する本部等に通常１台ずつ設置される。車両端末装置４は、当該地域の複数の消防署に所属する複数の消防車両及び救急車両に通常１台ずつ搭載される。ユーザ端末装置５は、特に設置される場所は限定されないが、消防署及び本部の管理者が使用可能な場所に１又は複数台設置されているものとする。
【００１１】
（データ格納サーバ）
データ格納サーバ２は、一般的なコンピュータであり、中央制御装置１１、主記憶装置１２、補助記憶装置１３、通信装置１４、入力装置１５及び出力装置１６を有する。これらはバスによって相互に接続されている。補助記憶装置１３は、位置情報履歴データ３１及び道路情報データ３２を格納している（いずれも詳細後記）。位置情報管理部２１及び道路情報管理部２２はプログラムである。以降、「○○部は」と主体を記した場合は、中央制御装置１１が、補助記憶装置１３から各プログラムを読み出し、主記憶装置１２にロードしたうえで、各プログラムの機能（詳細後記）を実現するものとする（後記するＷｅｂサーバ３についても同様である）。
なお、「車両位置情報」及び「道路位置情報」には、それぞれ、位置情報履歴データ３１及び道路情報データ３２が相当する。
【００１２】
（Ｗｅｂサーバ）
Ｗｅｂサーバ３もまた、一般的なコンピュータであり、中央制御装置４１、主記憶装置４２、補助記憶装置４３、通信装置４４、入力装置４５及び出力装置４６を有する。これらはバスによって相互に接続されている。位置情報・道路情報取得部５１、マッチング部５２、ルート補完処理部５３及び表示処理部５４はプログラムである。
なお、「車両走行ルート表示装置」には、Ｗｅｂサーバ３が相当する。
【００１３】
車両端末装置４及びユーザ端末装置５もまた、一般的なコンピュータであり、中央制御装置、主記憶装置、補助記憶装置、通信装置、入力装置及び出力装置を有する。これらはバスによって相互に接続されている（図示せず）。車両端末装置４は、消防車に搭乗する消防士が災害現場において操作しやすい携帯型であることが望ましい。
【００１４】
（位置情報履歴データ）
図２に沿って、位置情報履歴データ３１を説明する。
位置情報履歴データ３１においては、車両ＩＤ欄１０１に記憶された車両ＩＤに関連付けて、事案ＩＤ欄１０２は事案ＩＤが、登録時刻欄１０３には登録時刻が、位置欄１０４には位置情報が、動態欄１０５には動態情報が記憶されている。
【００１５】
車両ＩＤ欄１０１の車両ＩＤは、地域の１又は複数の消防署に所属する、消防車両及び救急車両を含む車両を一意に特定する識別子である。ここでは、消防車両についての車両ＩＤには「消」の文字を、救急車両についての車両ＩＤには「救」の文字を、その冒頭部分に付している。なお、消防車両及び救急車両をまとめて、以降単に「車両」と呼ぶことがある。
事案ＩＤ欄１０２の事案ＩＤは、当該地域における個々の事案を一意に特定する識別子である。事案とは、火災、事故、犯罪、自然災害等を含む、車両が出動した機会である。
登録時刻欄１０３の登録時刻は、個々のレコード（行）が位置情報履歴データ３１として記憶された時刻である。登録時刻の間隔は任意である。さらに、ある事案において、登録時刻の間隔が均等である必要はない。ここでは、説明の単純化のために、登録時刻は２分間隔であるとしている。
【００１６】
位置欄１０４の位置情報は、車両が存在する位置を示す２次元座標値であり、ここでは、経度を示す「Ｘ」及び緯度を示す「Ｙ」の組合せである。一般的なＧＰＳ（Global Positioning System）技術によって車両のリアルタイムの位置情報が取得できるものとする。なお、位置情報として、さらに高さ「Ｚ」を加えた３次元座標値を採用してもよい。以降では、２次元座標値の例を説明する。
図３においては、横軸である経度及び縦軸である緯度を座標軸とする平面上に、「災害現場」、「消防署１」、「消防署２」、「消防署３」及び「病院」がプロットされている。災害現場の位置情報は（Ｘ０，Ｙ０）であり、消防署１の位置情報は（Ｘ１，Ｙ１）であり、消防署２の位置情報は（Ｘ２，Ｙ２）であり、消防署３の位置情報は（Ｘ３，Ｙ３）であり、病院の位置情報は（Ｘ４，Ｙ４）である。さらに、「消防署１」から「災害現場」に向かう道路上のある点の位置情報は（Ｘａ，Ｙａ）である。図２の位置欄１０４の位置情報は、このように図３において説明される位置情報である。
【００１７】
図２に戻り、動態欄１０５の動態情報は、車両の活動状況を端的に示す文字列である。ここでは、消防車両についての動態情報として、消防車両が消防署を出発したことを示す「出動」、消防車両が災害現場に向かう道路上にあることを示す「往路」、消防車両が災害現場に到着したことを示す「現着」、消防車両が消火活動中であることを示す「消火中」、消防車両が消火活動を終了し災害現場を出発したことを示す「現発」、消防車両が消防署に戻る道路上にあることを示す「復路」及び消防車両が消防署に到着したことを示す「引揚」が例として存在する。
【００１８】
また、救急車両についての動態情報として、救急車両が消防署を出発したことを示す「出動」、救急車両が災害現場に向かう道路上にあることを示す「往路」、救急車両が災害現場に到着したことを示す「現着」、救急車両が救命活動中であることを示す「処置中」、救急車両が病人等を収容して災害現場を出発したことを示す「現発」、救急車両が病人等を病院に搬送する道路上にあることを示す「搬送中」、救急車両が病院に到着したことを示す「病院着」、救急車両が消防署に戻る道路上にあることを示す「復路」及び救急車両が消防署に到着したことを示す「引揚」が例として存在する。
位置情報履歴データ３１のレコードは、車両ＩＤ、事案ＩＤ及び登録時刻の組合せの数だけ存在する。なお、位置情報履歴データ３１については、車両ごとに異なるテーブルが作成されてもよい。
【００１９】
図２を参照しつつ、事案「Ａ００１」における車両の動きを大まかに説明する。
救急車両「救００１」は、「20100101 10:00」に、消防署１（Ｘ１，Ｙ１）を「出動」し（レコード２０１）、「20100101 10:02」においては、災害現場に向かう道路上のある点（Ｘａ，Ｙａ）を走行中である（レコード２０４）。その後、「20100101 10:04」に、災害現場（Ｘ０，Ｙ０）に到着し（レコード２０７）、「20100101 10:06」においては、災害現場（Ｘ０，Ｙ０）で「処置中」である（レコード２１０）。「20100101 10:08」に、災害現場（Ｘ０，Ｙ０）を出発し（レコード２１３）、「20100101 10:10」においては、病院に向かう道路上のある点（Ｘｅ，Ｙｅ）を走行中である（レコード２１６）。「20100101 10:12」に、病院（Ｘ４，Ｙ４）に到着し（レコード２１９）、「20100101 10:14」においては、消防署１に戻る道路上のある点（Ｘｈ，Ｙｈ）を走行中であり（レコード２２２）、20100101 10:16」に、消防署１（Ｘ１，Ｙ１）に到着している（レコード２２５）。
【００２０】
消防車両「消００１」についても、図２のレコード２０２、２０５、２０８、２１１、２１４、２１７、２２０及び２２３を参照すれば、（詳細は省略するが）消防署２（Ｘ２，Ｙ２）を「20100101 10:00」に「出動」した後、消防署２（Ｘ２，Ｙ２）に「20100101 10:14」に「引揚」げた経過が確認できる。消防車両「消００２」についても、図２のレコード２０３、２０６、２０９、２１２、２１５、２１８、２２１及び２２４を参照すれば、（詳細は省略するが）消防署３（Ｘ３，Ｙ３）を「20100101 10:00」に「出動」した後、消防署３（Ｘ３，Ｙ３）に「20100101 10:14」に「引揚」げた経過が確認できる。
【００２１】
（道路情報データ）
図４に沿って、道路情報データ３２を説明する。
道路情報データ３２においては、オブジェクトＩＤ欄１１１に記憶されたオブジェクトＩＤに関連付けて、種類欄１１２には種類が、位置欄１１３には位置情報が、端点欄１１４には端点情報が、幅員欄１１５には幅員が、範囲欄１１６には範囲が記憶されている。
【００２２】
オブジェクトＩＤ欄１１１のオブジェクトＩＤは、地図上のオブジェクトを一意に特定する識別子である。オブジェクトとは、地図上の、点及び図形（地物）である。
種類欄１１２の種類は、オブジェクトの種類である。本来地図には、多くの種類の図形が存在するが、ここでは、単純化のため、オブジェクトの種類として「ノード」、「道路」及び「施設」が存在するものとする。「ノード」とは位置情報のみを有する点であり、典型的には交差点（の中心点）である。「道路」（「リンク」ともいう）とは、２つのノードを両端に有し、ある幅員を有する道路（図形としては長方形）である。「施設」とは、１つのノードを中心に有する建物等（図形としては長方形）である。
【００２３】
位置欄１１３の位置情報は、ノードが存在する位置を示す２次元座標値である。ここでは、経度を示す「Ｘ」及び緯度を示す「Ｙ」の組合せである。一般的なＧＰＳ技術によって位置情報が取得できるものとする。位置欄１１３の値として、すべて「（Ｘ，Ｙ）」が便宜的に記載されているが、実際には、別々の値が記憶されているものとする。
端点欄１１４の端点情報は、道路の両端のノードのオブジェクトＩＤの組み合わせ、又は、施設の中心のノードのオブジェクトＩＤである。
幅員欄１１５の幅員は、道路の幅、又は施設の縦横の長さである。
【００２４】
範囲欄１１６の範囲は、オブジェクトが地図上に占める長方形の４つの頂点の位置情報の組合せである。４つの位置情報のそれぞれが、経度及び緯度の組合せとなっている。図４においては、範囲欄１１６の値として、すべて「（x，y），（x，y），（x，y），（x，y）」が便宜的に記載されているが、実際には、別々の値が記憶されているものとする。
なお、種類欄１１２に「ノード」が記憶されているレコードの端点欄１１４、幅員欄１１５及び範囲欄１１６は空欄である。種類欄１１２に「道路」又は「施設」が記憶されているレコードの位置欄１１３は空欄である。
道路情報データ３２のレコードのうち、種類欄１１２に「道路」を有するレコードは、更に欄を設けて、例えば、一方通行等の規制、高架橋の高さ、道路工事の申請の有無等に関する情報を記憶するようにしてもよい。
【００２５】
図５に沿って、「ノード」、「道路」及び「施設」の関係を説明する。
図５のノード「Ｂ００１」は、図４のレコード２３１を平面上に表示したものである。図５のノード「Ｂ００２」は、図４のレコード２３２を平面上に表示したものである。図５の道路「Ｂ１０１」は、ノード「Ｂ００１」及び「Ｂ００２」を端点に有する線分である。そして当該道路「Ｂ１０１」は、幅員「１０」を有している。すなわち、図５の破線の長方形２５１は、図４のレコード２３６を平面上に表示したものに他ならない。そして、図５の長方形２５１の幅員が、図４のレコード２３６の幅員に対応し、図５の長方形２５１の４つの頂点が、図４のレコード２３６の範囲欄１１６に記憶された４つの位置情報に相当する。同様に、図５の破線の長方形２５２及び２５３は、図４のそれぞれレコード２３７及び２３８を平面上に表示したものである。
【００２６】
同様に、図５の破線の長方形２５４は、図４の道路情報データ３２のレコード２３９を、平面に表示した結果である。図４の道路情報データ３２のうち「施設」に関するレコード（行）については、別途欄を設けて、その欄に、例えば図５の破線の長方形の辺が横軸（縦軸）に対しなす角度を記憶させてもよいし、破線の長方形に付して表示する文字列（建物名等を示す）を記憶させてもよい。要するに、図４の道路情報データ３２は、道路及び建物を有する地図を作成し、表示するためのデータである。
【００２７】
（処理手順）
以降、本実施形態の処理手順を説明する。処理手順には、（１）位置情報履歴データ作成処理手順及び（２）走行ルート表示処理手順がある。（１）の処理手順は、車両が出動するたびに実行される。（２）の処理手順は、消防車両走行ルート管理システム１の管理者が指定する任意のタイミングで実行される。（２）の処理手順が実行されるためには、少なくとも１度（１）の処理手順が実行され、位置情報履歴データ３１が作成されていることが前提となる。
【００２８】
（位置情報履歴データ作成処理手順）
図６については後記することとし、図７に沿って、位置情報履歴データ作成処理手順を説明する。
ステップＳ３０１において、車両端末装置４は、起動指示を受け付ける。具体的には、車両端末装置４は、ユーザ（車両の運転手、消防士等）が、車両の位置情報処理用のアプリケーション（図示せず）を起動させる指示を、入力装置を介して入力するのを受け付ける。以降において、車両端末装置４の動作主体は、当該アプリケーションである。
なお、車両端末装置４が、データ通信カードを利用したモバイル回線等を介して、１１９番通報を受ける指令システム（図示せず）から出動指令情報を受け付けてもよい。この場合は、ユーザからの手動の指示がなくとも、車両端末装置４は、自動的に起動指示を受け付けることができる。
【００２９】
ステップＳ３０２において、車両端末装置４は、事案ＩＤを受け付ける。具体的には、車両端末装置４は、ユーザが、事案ＩＤを、入力装置を介して入力するのを受け付ける。例えば、災害の通報を受信した本部等が、事案ＩＤを採番し、当該事案ＩＤを当該災害が発生した地域の消防署の任意の装置に送信し、当該消防署の任意の装置は、車両が出動する直前に、ユーザに知らしめてもよい。さらに、当該消防署の任意の装置は、車両端末装置４に対し、事案ＩＤを無線等で直接送信してもよい。
【００３０】
ステップＳ３０３において、車両端末装置４は、位置情報等を送信する。具体的には、車両端末装置４は、第１に、位置情報（車両の存在する緯度及び経度）を、ＧＰＳ技術を使用して取得する。
第２に、ユーザが、動態情報を、入力装置を介して入力するのを受け付ける。アプリケーションが起動した後最初に入力される動態情報は、「出動」である。パネル上に表示された「出動」等のアイコンをユーザが選択することによって入力を受け付けてもよいし、ユーザの肉声を車両端末装置４が「出動」等の文字列に変換してもよい。
第３に、ステップＳ３０２において受け付けた事案ＩＤ、ステップＳ３０３の「第１」において取得した位置情報、及び、ステップＳ３０３の「第２」において受け付けた動態情報に、車両ＩＤ及び登録時刻（現在の時刻）を付して、データ格納サーバ２に送信する。
【００３１】
ステップＳ３０４において、データ格納サーバ２の位置情報管理部２１は、位置情報履歴データ３１のレコードを作成する。具体的には、位置情報管理部２１は、第１に、ステップＳ３０３の「第３」において送信された事案ＩＤ、位置情報、動態情報、車両ＩＤ及び登録時刻を受信する。
第２に、位置情報履歴データ３１（図２）の新たなレコードを作成する。
第３に、作成したレコードの車両ＩＤ欄１０１、事案ＩＤ欄１０２、登録時刻欄１０３、位置欄１０４及び動態欄１０５に、ステップＳ３０４の「第１」において受信した、車両ＩＤ、事案ＩＤ、登録時刻、位置情報及び動態情報を、それぞれ記憶する。
【００３２】
ステップＳ３０５において、車両端末装置４は、最後に送信した動態情報が「引揚」であるか否かを判断する。具体的には、車両端末装置４は、ステップＳ３０３の「第３」において送信した動態情報が「引揚」である場合（ステップＳ３０５“ＹＥＳ”）は、位置情報履歴データ作成処理手順を終了し、それ以外の場合（ステップＳ３０５“ＮＯ”）は、ステップＳ３０３に戻る。
【００３３】
ステップＳ３０３は繰り返し実行されることになる。２回目以降のステップＳ３０３の「第２」においては、動態情報として、消防車両については、「往路」、「現着」、「消火中」、「現発」、「復路」及び「引揚」が、救急車両については、「往路」、「現着」、「処置中」、「現発」、「搬送中」、「病院着」、「復路」及び「引揚」が、この順序で入力されることになる。「往路」、「消火中」、「復路」、「処置中」及び「搬送中」については、連続して複数回入力されることもある。
また、車両端末装置４は、位置情報等をデータ格納サーバ２に前回送信した時刻を記憶しており、当該時刻から所定の時間（例えば２分）を経過した時点で、ユーザに対し、音声等で、動態情報の入力を促してもよい。
【００３４】
さらに、車両端末装置４は、消防署の位置情報、病院の位置情報及び災害現場の位置情報（通報を受け付けた際に特定できる）を記憶しているものとし、ステップＳ３０３の「第２」において以下の規則にしたがって動態情報を自動的に生成してもよい。そして、生成した動態情報を、ステップＳ３０３の「第３」以降の処理において、ユーザから入力を受け付けた動態情報に代替して取り扱うものとしてもよい。
【００３５】
すなわち、車両が消防車両である場合は、当該規則は以下の通りである。
（１）ＧＰＳ技術を用いて取得した車両の位置情報が、記憶されている消防署の位置情報と同じ（又は所定の誤差範囲内にある）場合は、「出動」（初回）又は「引揚」（２回目）を生成する。
（２）ＧＰＳ技術を用いて取得した車両の位置情報が、記憶されている災害現場の位置情報と同じ（又は所定の誤差範囲内にある）場合は、「現着」（初回）、「消火中」（２回目以降）又は「現発」（最終回）を生成する。
（３）ＧＰＳ技術を用いて取得した車両の位置情報が、記憶されている消防署の位置情報とも災害現場の位置情報とも異なる（又は所定の誤差範囲外にある）場合は、「往路」（「現着」が生成される前）又は「復路」（「現発」が生成された後）を生成する。
【００３６】
また、車両が救急車両である場合は、当該規則は以下の通りである。
（１）ＧＰＳ技術を用いて取得した車両の位置情報が記憶されている消防署の位置情報と同じ（又は所定の誤差範囲内にある）場合は、「出動」（初回）又は「引揚」（２回目）を生成する。
（２）ＧＰＳ技術を用いて取得した車両の位置情報が、記憶されている災害現場の位置情報と同じ（又は所定の誤差範囲内にある）場合は、「現着」（初回）、「処置中」（２回目以降）又は「現発」（最終回）を生成する。
（３）ＧＰＳ技術を用いて取得した車両の位置情報が、記憶されている病院の位置情報と同じ（又は所定の誤差範囲内にある）場合は、「病院着」を生成する。
（４）ＧＰＳ技術を用いて取得した車両の位置情報が、記憶されている消防署の位置情報とも災害現場の位置情報とも異なる（又は所定の誤差範囲外にある）場合は、「往路」（「現着」が生成される前）、「搬送中」（「現発」が生成された後）又は「復路」（「病院着」が生成された後）を生成する。
【００３７】
（走行ルート表示処理）
図８及び図９に沿って、走行ルート表示処理を説明する。
ステップＳ４０１において、ユーザ端末装置５は、事案を選択する。具体的には、ユーザ端末装置５は、第１に、ユーザ（管理者）が事案ＩＤを、入力装置を介して入力するのを受け付ける。
第２に、受け付けた事案ＩＤをＷｅｂサーバ３に送信する。
【００３８】
ステップＳ４０２において、Ｗｅｂサーバ３の位置情報・道路情報取得部５１は、選択された事案に関するデータを要求する。具体的には、位置情報・道路情報取得部５１は、第１に、ステップＳ４０１の「第２」において送信された事案ＩＤを受信する。
第２に、受信した事案ＩＤをデータ格納サーバ２に送信する。
【００３９】
ステップＳ４０３において、データ格納サーバ２の位置情報管理部２１は、位置情報履歴データ３１を検索する。具体的には、位置情報管理部２１は、第１に、ステップＳ４０２の「第２」において送信された事案ＩＤを受信する。
第２に、事案ＩＤを検索キーとして、位置情報履歴データ３１（図２）を検索し、該当したレコード（行）をすべて取得する。ここで取得されたレコードを以降「対象レコード」と呼ぶことがある。図２の位置情報履歴データ３１は、複数の事案ＩＤについての多くのレコードを有する。ここでは例として、事案ＩＤ「Ａ００１」を検索キーとして検索した結果、「Ａ００１」を事案ＩＤ欄１０２に有するレコード、すなわち図２のレコード２０１〜２２５が、対象レコードとして取得されたものとする。
【００４０】
ステップＳ４０４において、データ格納サーバ２の道路情報管理部２２は、道路情報データ３２を検索する。具体的には、道路情報管理部２２は、第１に、すべての対象レコードに含まれる位置情報のうち最大の緯度、最小の緯度、最大の経度及び最小の経度によって四辺が区画される長方形の領域を特定する。当該領域を以降「表示予定領域」と呼ぶことがある。このとき、上下左右にそれぞれ所定の緯度（経度）を余裕として加え、表示予定領域を特定してもよい。
第２に、道路情報データ３２（図４）を検索し、種類欄１１２に「ノード」を有し、かつ、位置欄１１３の位置情報が表示予定領域内に属するレコードを取得する。ここでは、レコード２３１〜２３５を含むレコード群が取得されたものとする。
【００４１】
第３に、ステップＳ４０４の「第２」において取得されたレコードのすべてのオブジェクトＩＤを検索キーとして、道路情報データ３２（図４）を検索し、種類欄１１２に「道路」を有し、かつ、検索キーとしたオブジェクトＩＤと同じオブジェクトＩＤを端点欄１１４に少なくとも１つ有するレコードをすべて取得する。ここでは、レコード２３６〜２３８を含むレコード群が取得されたものとする。
第４に、ステップＳ４０４の「第２」において取得されたレコードのすべてのオブジェクトＩＤを検索キーとして、道路情報データ３２（図４）を検索し、種類欄１１２に「施設」を有し、かつ、検索キーとしたオブジェクトＩＤと同じオブジェクトＩＤを端点欄１１４に有するレコードをすべて取得する。ここでは、レコード２３９、２４０を含むレコード群が取得されたものとする。
なお、ステップＳ４０４の「第２」、「第３」及び「第４」において取得されたレコード群を以降「背景レコード」と呼ぶことがある。この時点での背景レコードは、車両が走行した可能性のある道路に対応するレコード、車両が走行した地点の付近にある施設に対応するレコード及びこれらの道路及び施設を特定するために必要な「ノード」についてのレコードである。
【００４２】
ステップＳ４０５において、データ格納サーバ２の道路情報管理部２２は、検索したデータを送信する。具体的には、道路情報管理部２２は、背景レコード及び対象レコードをＷｅｂサーバ３に送信する。
【００４３】
ステップＳ４０６において、Ｗｅｂサーバ３のマッチング部５２は、選択された事案に関するデータを受信する。具体的には、マッチング部５２は、ステップＳ４０５において送信された背景レコード及び対象レコードを受信する。
【００４４】
ステップＳ４０７において、Ｗｅｂサーバ３のマッチング部５２は、位置情報履歴データ３１と道路情報データ３２とをマッチングする。
具体的には、マッチング部５２は、第１に、対象レコードに含まれる車両ＩＤのうち任意の１つを選択する。当該選択された車両ＩＤを、以降「対象車両ＩＤ」と呼ぶことがある。ここでは、例えば、「救００１」が選択されたとする。
第２に、対象レコードから対象車両ＩＤを有するレコードをすべて取得し、登録時刻の順に並び替える。「救００１」を有するレコード（図２）が、レコード２０１、２０４、２０７、２１０、２１３、２１６、２１９、２２２及び２２５の順に並ぶことになる。
【００４５】
第３に、並び替えられた対象レコードのうちｎ番目のレコードの位置情報が、種類「道路」を有する背景レコードのうちｍ番目のレコードの範囲欄１１６に記憶された範囲内に存在するか否かを判断し、存在する場合は、種類「道路」を有する背景レコードのうちｍ番目のレコードに「＃」のようなフラグを立てる。当該処理は、ｎ＝１を基準に、ｍ＝１，２，３，４，・・・について実行し、その後、ｎ＝２を基準に、ｍ＝１，２，３，４，・・・について実行し、・・・のように繰り返し実行される。
第４に、フラグ「＃」が立てられたレコードのみを抽出し、さらにフラグ「＃」が立てられた順に並び替える。このように抽出され並び替えられたレコードを、以降「表示予定道路レコード」と呼ぶことがある。
当該繰り返し処理が終了した時点で、車両ＩＤが「救００１」である車両が走行した道路に対応する背景レコードが、当該車両が走行した順に、表示予定道路レコードとして並んでいることになる。なお「ノード」又は「施設」を含む背景レコードはそのまま残る。
このとき、表示予定道路レコードは、図４のレコード２３６〜２３８であったとする。
【００４６】
ステップＳ４０８において、Ｗｅｂサーバ３のルート補完処理部５３は、ルートが連続するか否かを判断する。
具体的には、ルート補完処理部５３は、第１に、表示予定道路レコードの端点欄１１４に記憶されているオブジェクトＩＤが連続しているか否かを判断する。例えば、図４のレコード２３６の端点欄１１４の「Ｂ００２」は、レコード２３７の端点欄１１４にも記憶されている。このような場合、オブジェクトＩＤは連続していると判断される。つまり、レコード２３６及び２３７に対応する道路は、連続して繋がったものとして表示されることが可能である。さらに、レコード２３７の端点欄１１４の「Ｂ００３」は、レコード２３８の端点欄１１４にも記憶されている。このような場合、オブジェクトＩＤは連続していると判断される。つまり、レコード２３７及び２３８に対応する道路も、連続して繋がったものとして表示されることが可能である。
ルート補完処理部５３は、このように表示予定道路レコードを２つずつ対比して、それらのオブジェクトＩＤが連続しているか否か（すなわち共通するオブジェクトＩＤを有するか否か）を判断することができる。
【００４７】
第２に、連続していないと判断された前後（レコードの位置としては上下）２つのレコードの組のオブジェクトＩＤ（欄１１１）を保持する。図４の例では、保持すべきオブジェクトＩＤは存在しない。しかしながら、仮に図４において、レコード２３８の端点欄１１４に「Ｂ００４，Ｂ００５」が記憶されていた場合、ルート補完処理部５３は、レコード２３７及び２３８を、オブジェクトＩＤが連続していない前後２つのレコードの組であると判断することになる。
第３に、連続していないと判断された前後２つのレコードの組が存在する場合（ステップＳ４０８“ＮＯ”）は、ステップＳ４０９に進み、それ以外の場合（ステップＳ４０８“ＹＥＳ”）は、ステップＳ４１０に進む。
【００４８】
次に説明するステップＳ４０９の処理に関連し、図６に沿ってルート補完の考え方を説明する。
表示予定道路レコードが、例えば３つ存在するとする。そして、第１のレコードと第２のレコードの組は、オブジェクトＩＤが連続していない前後２つのレコードの組であるとする。同様に、第２のレコードと第３のレコードの組もオブジェクトＩＤが連続していない前後２つのレコードの組であるとする。図６は、第１のレコード、第２のレコード及び第３のレコードを平面に表示した図である。破線の長方形２６１、２６２及び２６３は、それぞれ、第１のレコード、第２のレコード及び第３のレコードに対応する。車両端末装置４が位置情報等をデータ格納サーバ２に送信する（図７のステップＳ３０３）間隔が長い場合、ステップＳ４０７の「第３」において、実際に車両が走行した道路に対応する背景レコードのすべてに対して、フラグ「＃」を立てることは不可能になる。その結果、図６の円形の領域２６４及び２６５のような、破線の長方形が連続しない「ルート未確定領域」が発生する。このようなルート未確定領域ごとに、車両が走行したであろう１又は複数の道路を推定することが、ルート補完の処理に他ならない。
【００４９】
図９に戻って、ステップＳ４０９において、Ｗｅｂサーバ３のルート補完処理部５３は、ルートを補完する。具体的には、ルート補完処理部５３は、第１に、ステップＳ４０８の「第１」において、オブジェクトＩＤが連続していないと判断された前後２つのレコードの組のうち、任意の組を選択する。
第２に、選択した組の２つのレコードの端点欄１１４に記憶されている４つのオブジェクトＩＤ（端点である「ノード」を示す）のうちから、同一のレコードに属さない２つを特定する。このとき、４つのノードのうち、当該組に属さない他のレコードと連続しているノードは除外される。例えば、今、図６のルート未確定領域２６４の道路を推定するとする。仮に、ノード２６９とノード２７０とが一致している場合は、ノード２６９は無視し、ノード２６６及びノード２６８の組、又はノード２６７及びノード２６８の組が、特定される候補となり得る。
このように複数の候補がある場合、表示予定道路レコードの端点欄１１４のオブジェクトＩＤを検索キーとして、種類「ノード」を有する背景レコードの位置情報を取得することによって、ノード２６６及びノード２６８の間の距離、並びに、ノード２６７及びノード２６８の間の距離を計算する。そして、最も距離が短いノード同士に対応するオブジェクトＩＤを２つ特定する。この場合、ノード２６７及びノード２６８に対応するオブジェクトＩＤが特定される。
【００５０】
第３に、特定した２つのオブジェクトＩＤを検索キーとして、背景レコード検索し、種類欄１１２に「道路」を有し、かつ、検索キーとした２つのオブジェクトＩＤを端点欄１１４に有するレコードを取得する。当該取得したレコードを、以降「補完レコード」と言うことがある。このとき、補完レコードが存在しない場合がありうる。例えば、図６のルート未確定領域２６５において、ノード２６９及びノード２７０の間の道路を推定しようとするものの、符号２７２の道路が存在しない場合である。
このような場合は、ルート補完処理部５３は、以下の処理を実行する。
【００５１】
（１）：２つの「道路」によって補完する。
すなわち、種類「道路」を有する背景レコードから、ノード２６９に対応するオブジェクトＩＤを有する複数の背景レコード群と、ノード２７０に対応するオブジェクトＩＤを有する複数の背景レコード群とを抽出する。その後、ある１つのノードに対応するオブジェクトＩＤを共有する２つのレコードを、それぞれの群から１つずつ抽出し、補完レコードとする。このような２つのレコードの組が複数存在する場合は、ノード２６９から「ある１つの点」を経由してノード２７０に至る距離が最短であるような２つのレコードを、それぞれの群から１つずつ抽出し、補完レコードとする。このような補完レコードは、図６における、例えば破線２７４及び２７５に対応している。
【００５２】
（２）：（１）の処理によっても補完レコードが存在しない場合は、３つの「道路」によって補完する。
すなわち、（１）の処理において、例えばノード２６９に対応するオブジェクトＩＤを有する複数の背景レコード群の内の任意の１つのレコードをレコード（ａ）とする。そしてレコード（ａ）の他方のオブジェクトＩＤを有する複数の背景レコード群（ｂ）と、ノード２７０に対応するオブジェクトＩＤを有する複数の背景レコード群（ｃ）とを抽出する。その後、ある１つの点に対応するオブジェクトＩＤを共有する２つのレコードを、（１）の処理と同様に、レコード群（ｂ）及びレコード群（ｃ）から１つずつ抽出し、任意のレコード（ａ）とあわせて３つの補完レコードとする。つまり、例えばノード２７３とノード２７０との間を補完するような２つの補完レコードを（１）の処理に準じて実行する。このような補完レコードは、図６における、例えば破線２７６、２７７及び２７８に対応している。
また、レコード（ａ）を他の候補に代替し、３つの補完レコードの組の候補を取得し、合計距離が最短であるような組の３つのレコードを補完レコードとしてもよい。
【００５３】
（３）：（２）の処理によっても補完レコードが存在しない場合は、ｐ個（ｐ＝４，５，・・・）の「道路」によって補完する。処理の内容は、（２）に準ずる。ある閾値を設定して、ｐの値が当該閾値以上となってもなお補完レコードが存在しない場合は、「補完すべき道路がありません」のようなメッセージを生成する。そして、次の「第４」の処理は実行しない。ただし、このようなことは、当該事案が発生した後、道路情報データ３２が変更された場合（道路の付け替えのような場合）等を除けば、通常はあり得ない。
【００５４】
第４に、補完レコードを、ステップＳ４０８の「第１」において、オブジェクトＩＤが連続していないと判断された前後２つのレコードの組の間に挿入する。「補完すべき道路がありません」のようなメッセージが生成されたときは、当該メッセージを有するダミーのレコードを挿入する。
【００５５】
ステップＳ４０７〜Ｓ４０９の処理は、対象レコードに含まれるすべての車両ＩＤについて繰り返される。ステップＳ４０９の処理から抜けた段階で、Ｗｅｂサーバ３は、例えば、図１０のような対象レコード及び図１１のような背景レコードを一時的に記憶していることになる。
【００５６】
図１０の対象レコードは、前記したように、位置情報履歴データ３１（図２）の一部に基づいて作成されたものである。したがって、各欄の名称と符号は図２と同じである。しかしながら、レコードは、ステップＳ４０１において入力を受け付けた事案ＩＤ「Ａ００１」を有するものだけに限定されている。
なお、以降の説明の単純化のために、図１０のデータは、以前に説明した例とは直接関係を有さない（整合性を無視する）ものとする。例えば、事案ＩＤ「Ａ００１」を有する対象レコードは、車両ＩＤが「救００１」であるもの（レコード２８１ａ〜２８１ｄを含む）、及び車両ＩＤが「消００１」であるもの（レコード２８２ａ〜２８２ｃを含む）だけであるとする。そして、対象レコードは、実際には図１０に示されるより多く存在するが、単純化のために、以降では、動態情報として「出動」、「往路」及び「現着」を有するレコードについてのみを説明する。
【００５７】
図１０を参照すると、車両ＩＤが「救００１」である救急車両及び車両ＩＤが「消００１」である消防車両は、何れも、「20100102 12：00」に「出動」している（レコード２８１ａ、２８２ａ）。しかしながら、「現着」の時刻は、「消００１」については「20100102 12：04」である（レコード２８２ｃ）のに対し、「救００１」については「20100102 12：06」である（レコード２８１ｄ）。ユーザ（管理者）は、なぜ当該救急車両が災害現場に到着するのが遅れたのか知りたくなる（詳細後記）。
【００５８】
図１１の背景レコードは、前記したように、道路情報データ３２（図４）の一部に基づいて作成されたものである。したがって、各欄の名称と符号は図４と同じである。
図１１の背景レコードは、大きくわけて、種類「ノード」を有するもの（レコード２８３ａ〜２８３ｃを含む）、種類「道路」を有するもの（レコード２８４ａ〜２８４ｄ、２８５ａ、２８５ｂを含む）及び種類「施設」を有するもの（レコード２８６ａ〜２８６ｃを含む）の３つの群に分かれる。
【００５９】
種類「道路」を有するレコードは、当初取得された背景レコードのうちから、実際に車両が走行した道路に対応するレコードに絞り込まれた「表示予定道路レコード」である。さらに、レコード２８４ａ〜２８４ｄは、車両ＩＤが「救００１」である救急車両についてのものであり、さらに、そのうちレコード２８４ｃは、当該車両が実際に走行したか否かが不明であるが、前後関係を基に、走行しているものと推定した道路に対応する「補完レコード」である（左欄外に「補完」と記載）。レコード２８５ａ及び２８５ｄは、車両ＩＤが「消００１」である消防車両についてのものである。
【００６０】
図９に戻る。ステップＳ４１０において、Ｗｅｂサーバ３の表示処理部５４は、画面表示用のデータを送信する。具体的には、表示処理部５４は、図１０の対象レコード及び図１１の背景レコードを、動画表示用のアプリケーション（図示せず）とともにユーザ端末装置５に送信する。
【００６１】
ステップＳ４１１において、ユーザ端末装置５は、走行ルートを表示する。具体的には、ユーザ端末装置５は、第１に、ステップＳ４１０において送信された対象レコード、背景レコード及び動画表示用のアプリケーションを受信する。（以降の動作主体は当該アプリケーションである。但し他例について詳細後記。）
第２に、受信した背景レコードに基づき、走行ルート表示画面６１（図１２）を出力装置に表示する。例えば、図１１のレコード２８４ａの範囲欄１１６の範囲を図形表示すると、図１２の破線の長方形２９１ｄとなる。同様に、図１２の破線の長方形のうち、道路を表す長方形２９１ｅ、２９１ｆ及び２９１ｇは、それぞれ、図１１のレコード２８４ｂ、２８４ｃ及び２８４ｄに対応している。このうち太線で示した長方形２９１ｆは、「補完レコード」（図１１のレコード２８４ｃ）が作成されてはじめて表示され得る。図１２の破線の長方形のうち、道路を表す長方形２９１ｉ及び２９１ｈは、それぞれ、図１１のレコード２８５ａ及び２８５ｂに対応している。図１２の破線の長方形のうち、施設を表す長方形２９１ａ、２９１ｂ及び２９１ｃは、それぞれ、図１１のレコード２８６ａ、２８６ｂ及び２８６ｃに対応している。
なお、ユーザ端末装置５は、メッセージを有するダミーレコードに基づいて、前後の表示予定道路レコードに対応する道路の間の領域に、メッセージの文言を表示する。
【００６２】
図１２における「消防署１」等の文字は、例えば、道路情報データ３２の種別が「施設」であるレコードに欄を設け記憶しておくことによって、走行ルート表示画面６１に表示することができる。
なお、前記の例では、表示される道路は「表示予定道路レコード」に対応する道路のみである。しかしながら、表示処理部５４は、種類「道路」を有する背景レコードすべてを表示し、そのうち、表示予定道路レコードに対応する道路を強調表示してもかまわない。
【００６３】
第３に、受信した対象レコードのすべてのレコードの位置情報、登録時刻及び動態情報の組を、走行ルート表示画面６１に重ねて表示する。この段階での走行ルート表示画面６１は、図１３に示した通りである。
例えば、図１０のレコード２８１ａの、位置情報、登録時刻のうちの時分及び動態情報を表示すると、それぞれ、図１３の「×」２９２ａ、「12：00」２９２ｂ及び「出動」２９２ｃとなる。同様に、図１０のレコード２８１ｂの位置情報、登録時刻のうちの時分及び動態情報は、それぞれ、図１３の「×」２９３ａ、「12：02」２９３ｂ及び「往路」２９３ｃに対応している。以下同様に、図１０のレコード２８１ｃ、２８１ｄ、２８２ａ、２８２ｂ及び２８２ｃは、それぞれ、図１３の符号２９４ａ〜ｃ、２９５ａ〜ｃ、２９６ａ〜ｃ、２９７ａ〜ｃ及び２９８ａ〜ｃに対応している。
【００６４】
第４に、受信した対象レコードのすべてのレコードに基づき、車両を示すアイコンを、走行ルート表示画面６１に重ねて表示する。この段階での走行ルート表示画面６１は、図１４に示した通りである。図１４においては、車両ＩＤが「救００１」である救急車両を示すアイコン２９９ａが、図１３の「×」２９２ａに置き換わって表示されている。同じ救急車両を示すアイコン２９９ｂが、図１３の「×」２９３ａに置き換わって表示されている。同様に、車両ＩＤが「消００１」である消防車両を示すアイコン２９９ｃが、図１３の「×」２９６ａに置き換わって表示されている。同じ消防車両を示すアイコン２９９ｄが、図１３の「×」２９７ａに置き換わって表示されている。
アイコンは、すべての登録時刻について一度に表示されてもよいし、登録時刻が早い順に、１ずつ表示されてもよい（図１４の例）。そして、ある登録時刻のアイコンが表示されてから次の登録時刻のアイコンが表示されるまでの時間は、両者の登録時刻の差分に基づいて決定されてもよい。
【００６５】
なお、前記したような、対象レコードの数だけ離散的にアイコンを表示する方法に替わって、アイコンを動的に表示してもよい。例えば、「車両が１分間に進む実際の道路上の距離を、対応する画面上では１秒でアイコンが進む」のような換算率を設定しておき、当該率で、アイコンを移動させてもよい。このようにすると、走行ルート表示画面６１上では、２秒間の間に、救急車両を示すアイコンは符号２９９ａの位置から符号２９９ｂの位置へ移動し、消防車両を示すアイコンは符号２９９ｃの位置から符号２９９ｄの位置へ移動する。
以上の処理の後、走行ルート表示処理を終了する。
【００６６】
なお、前記の実施形態では、Ｗｅｂサーバ３はユーザ端末装置５に、対象レコード、背景レコード及び動画表示用のアプリケーションを渡し切ることとした。しかしながら、Ｗｅｂサーバ３とユーザ端末装置５との間で連続的に通信を確保しながら、Ｗｅｂサーバ３の表示処理部５４が主体となって、前記ステップＳ４１１の処理（走行ルート表示画面６１をユーザ端末装置５の出力装置に表示させる）を実行してもよい。
【００６７】
走行ルート表示画面６１（図１４）視認したユーザ（管理者）は、例えば、救急車両を示すアイコンの移動速度、消防署１から災害現場へ至る道路の幅員等から、以下のことを容易に理解できる。すなわち、「もし、当該災害現場の付近で災害が頻発し、消防署１の支援を受けざるを得ないのであれば、消防署１から当該災害現場へ至る道路の幅員を拡大することが有効である」と言うことである。
【００６８】
本発明は、前記した実施形態に限定されることなく、本発明の趣旨を逸脱しない範囲で、変更実施が可能である。
【符号の説明】
【００６９】
１ 消防車両走行ルート管理システム
２ データ格納サーバ
３ Ｗｅｂサーバ
４ 車両端末装置
５ ユーザ端末装置
１１、４１ 中央制御装置（制御部）
１２、４２ 主記憶装置（記憶部）
１３、４３ 補助記憶装置（記憶部）
１４、４４ 通信装置
１５、４５ 入力装置
１６、４６ 出力装置
２１ 位置情報管理部
２２ 道路情報管理部
３１ 位置情報履歴データ
３２ 道路情報データ
５１ 位置情報・道路情報取得部
５２ マッチング部
５３ ルート補完処理部
５４ 表示処理部
６１ 走行ルート表示画面
【技術分野】
【０００１】
本発明は、車両走行ルート表示装置に関する。
【背景技術】
【０００２】
自治体の消防業務においては、災害現場からの通報を受けると、消防車両及び救急車両が、消防署を出発し、当該災害現場に到着し、消火活動や救助活動を行ったのち、もとの消防署に戻る。当然のことながら、これらの車両が消防署を出発してから災害現場に到着するまでの時間が短いほど、人的・物的被害は少なくて済む。一般的に、当該時間は、消防署から災害現場までの距離に比例する。しかし、消防署から災害現場までのルートは、一般道路であることが殆どであり、地域・季節・時間帯による一般車両の混雑度によって、到着するまでの時間は大きく変化する。そこで、災害が発生した場合にどのルートを通って災害現場に到着するかを、過去の例を分析し日頃よりシミュレーションしておくことは非常に重要である。
例えば、特許文献１には、被介護者を介護施設へ送迎する車両が、乗車中の被介護者が発病した場合、被介護者の掛かりつけの病院まで運搬するルートを車載器に表示することと、最寄りの消防署から出発する救急車両と途中で落ち合うルートを車載器に表示することが開示されている。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２００５−５０１８３号公報（請求項２〜７）
【発明の概要】
【発明が解決しようとする課題】
【０００４】
特許文献１の発明は、まさに被介護者が発病しているその時に、一刻もはやく被介護者を病院に運ぶためには有効である。しかし、過去の走行ルートを履歴情報として保有していない。よって、災害発生前から、災害現場に最も早く到着できる消防署やルートを計画するために、さらには、交通規制や都市計画を含めた社会インフラ自体を計画しておくために、多くのルートを比較検討するようなシミュレーションには向いていない。
【０００５】
そこで、本発明は、消防車両の過去の走行ルートを時系列で視認しやすく表示することを目的とする。
【課題を解決するための手段】
【０００６】
本発明は、特定の場所に向かい走行する車両に関連付けて車両の位置を時系列で記憶した車両位置情報と、車両が走行し得る道路に関連付けて道路の位置を記憶した道路位置情報と、に対しアクセス可能な車両走行ルート表示装置であって、車両の位置に基づいて、道路位置情報から車両が走行する道路を抽出し、抽出した道路を表示し、表示した道路に沿って、車両を示す図形を時系列で移動させて表示する制御部を有すること、を特徴とする。その他の手段については、発明を実施するための形態のなかで説明する。
【発明の効果】
【０００７】
本発明によれば、消防車両の過去の走行ルートを時系列で視認しやすく表示することが可能になる。
【図面の簡単な説明】
【０００８】
【図１】本実施形態に係る消防車両走行ルート管理システムの構成図である。
【図２】本実施形態に係る位置情報履歴データの一例を示す図である。
【図３】本実施形態に係る位置情報を説明する図である。
【図４】本実施形態に係る道路情報データの一例を示す図である。
【図５】本実施形態に係る「ノード」、「道路」及び「施設」の関係を説明する図である。
【図６】本実施形態に係るルート補完の考え方を説明する図である。
【図７】本実施形態に係る位置情報履歴データ作成処理手順のフローチャートである。
【図８】本実施形態に係る走行ルート表示処理手順のフローチャートである。
【図９】本実施形態に係る走行ルート表示処理手順のフローチャート（続き）である。
【図１０】本実施形態に係る対象レコードの一例を示す図である。
【図１１】本実施形態に係る背景レコードの一例を示す図である。
【図１２】本実施形態に係る走行ルート表示画面の一例を示す図である。
【図１３】本実施形態に係る走行ルート表示画面の一例を示す図である。
【図１４】本実施形態に係る走行ルート表示画面の一例を示す図である。
【発明を実施するための形態】
【０００９】
以降、本発明を実施するための形態（「本実施形態」という）を、図等を参照しながら詳細に説明する。
【００１０】
（消防車両走行ルート管理システム）
図１の消防車両走行ルート管理システム１は、データ格納サーバ２、Ｗｅｂサーバ３、車両端末装置４及びユーザ端末装置５を有する。これらは、有線及び／又は無線のネットワーク６を介して相互に接続されている。データ格納サーバ２及びＷｅｂサーバ３は、地域の複数の消防署を統括する本部等に通常１台ずつ設置される。車両端末装置４は、当該地域の複数の消防署に所属する複数の消防車両及び救急車両に通常１台ずつ搭載される。ユーザ端末装置５は、特に設置される場所は限定されないが、消防署及び本部の管理者が使用可能な場所に１又は複数台設置されているものとする。
【００１１】
（データ格納サーバ）
データ格納サーバ２は、一般的なコンピュータであり、中央制御装置１１、主記憶装置１２、補助記憶装置１３、通信装置１４、入力装置１５及び出力装置１６を有する。これらはバスによって相互に接続されている。補助記憶装置１３は、位置情報履歴データ３１及び道路情報データ３２を格納している（いずれも詳細後記）。位置情報管理部２１及び道路情報管理部２２はプログラムである。以降、「○○部は」と主体を記した場合は、中央制御装置１１が、補助記憶装置１３から各プログラムを読み出し、主記憶装置１２にロードしたうえで、各プログラムの機能（詳細後記）を実現するものとする（後記するＷｅｂサーバ３についても同様である）。
なお、「車両位置情報」及び「道路位置情報」には、それぞれ、位置情報履歴データ３１及び道路情報データ３２が相当する。
【００１２】
（Ｗｅｂサーバ）
Ｗｅｂサーバ３もまた、一般的なコンピュータであり、中央制御装置４１、主記憶装置４２、補助記憶装置４３、通信装置４４、入力装置４５及び出力装置４６を有する。これらはバスによって相互に接続されている。位置情報・道路情報取得部５１、マッチング部５２、ルート補完処理部５３及び表示処理部５４はプログラムである。
なお、「車両走行ルート表示装置」には、Ｗｅｂサーバ３が相当する。
【００１３】
車両端末装置４及びユーザ端末装置５もまた、一般的なコンピュータであり、中央制御装置、主記憶装置、補助記憶装置、通信装置、入力装置及び出力装置を有する。これらはバスによって相互に接続されている（図示せず）。車両端末装置４は、消防車に搭乗する消防士が災害現場において操作しやすい携帯型であることが望ましい。
【００１４】
（位置情報履歴データ）
図２に沿って、位置情報履歴データ３１を説明する。
位置情報履歴データ３１においては、車両ＩＤ欄１０１に記憶された車両ＩＤに関連付けて、事案ＩＤ欄１０２は事案ＩＤが、登録時刻欄１０３には登録時刻が、位置欄１０４には位置情報が、動態欄１０５には動態情報が記憶されている。
【００１５】
車両ＩＤ欄１０１の車両ＩＤは、地域の１又は複数の消防署に所属する、消防車両及び救急車両を含む車両を一意に特定する識別子である。ここでは、消防車両についての車両ＩＤには「消」の文字を、救急車両についての車両ＩＤには「救」の文字を、その冒頭部分に付している。なお、消防車両及び救急車両をまとめて、以降単に「車両」と呼ぶことがある。
事案ＩＤ欄１０２の事案ＩＤは、当該地域における個々の事案を一意に特定する識別子である。事案とは、火災、事故、犯罪、自然災害等を含む、車両が出動した機会である。
登録時刻欄１０３の登録時刻は、個々のレコード（行）が位置情報履歴データ３１として記憶された時刻である。登録時刻の間隔は任意である。さらに、ある事案において、登録時刻の間隔が均等である必要はない。ここでは、説明の単純化のために、登録時刻は２分間隔であるとしている。
【００１６】
位置欄１０４の位置情報は、車両が存在する位置を示す２次元座標値であり、ここでは、経度を示す「Ｘ」及び緯度を示す「Ｙ」の組合せである。一般的なＧＰＳ（Global Positioning System）技術によって車両のリアルタイムの位置情報が取得できるものとする。なお、位置情報として、さらに高さ「Ｚ」を加えた３次元座標値を採用してもよい。以降では、２次元座標値の例を説明する。
図３においては、横軸である経度及び縦軸である緯度を座標軸とする平面上に、「災害現場」、「消防署１」、「消防署２」、「消防署３」及び「病院」がプロットされている。災害現場の位置情報は（Ｘ０，Ｙ０）であり、消防署１の位置情報は（Ｘ１，Ｙ１）であり、消防署２の位置情報は（Ｘ２，Ｙ２）であり、消防署３の位置情報は（Ｘ３，Ｙ３）であり、病院の位置情報は（Ｘ４，Ｙ４）である。さらに、「消防署１」から「災害現場」に向かう道路上のある点の位置情報は（Ｘａ，Ｙａ）である。図２の位置欄１０４の位置情報は、このように図３において説明される位置情報である。
【００１７】
図２に戻り、動態欄１０５の動態情報は、車両の活動状況を端的に示す文字列である。ここでは、消防車両についての動態情報として、消防車両が消防署を出発したことを示す「出動」、消防車両が災害現場に向かう道路上にあることを示す「往路」、消防車両が災害現場に到着したことを示す「現着」、消防車両が消火活動中であることを示す「消火中」、消防車両が消火活動を終了し災害現場を出発したことを示す「現発」、消防車両が消防署に戻る道路上にあることを示す「復路」及び消防車両が消防署に到着したことを示す「引揚」が例として存在する。
【００１８】
また、救急車両についての動態情報として、救急車両が消防署を出発したことを示す「出動」、救急車両が災害現場に向かう道路上にあることを示す「往路」、救急車両が災害現場に到着したことを示す「現着」、救急車両が救命活動中であることを示す「処置中」、救急車両が病人等を収容して災害現場を出発したことを示す「現発」、救急車両が病人等を病院に搬送する道路上にあることを示す「搬送中」、救急車両が病院に到着したことを示す「病院着」、救急車両が消防署に戻る道路上にあることを示す「復路」及び救急車両が消防署に到着したことを示す「引揚」が例として存在する。
位置情報履歴データ３１のレコードは、車両ＩＤ、事案ＩＤ及び登録時刻の組合せの数だけ存在する。なお、位置情報履歴データ３１については、車両ごとに異なるテーブルが作成されてもよい。
【００１９】
図２を参照しつつ、事案「Ａ００１」における車両の動きを大まかに説明する。
救急車両「救００１」は、「20100101 10:00」に、消防署１（Ｘ１，Ｙ１）を「出動」し（レコード２０１）、「20100101 10:02」においては、災害現場に向かう道路上のある点（Ｘａ，Ｙａ）を走行中である（レコード２０４）。その後、「20100101 10:04」に、災害現場（Ｘ０，Ｙ０）に到着し（レコード２０７）、「20100101 10:06」においては、災害現場（Ｘ０，Ｙ０）で「処置中」である（レコード２１０）。「20100101 10:08」に、災害現場（Ｘ０，Ｙ０）を出発し（レコード２１３）、「20100101 10:10」においては、病院に向かう道路上のある点（Ｘｅ，Ｙｅ）を走行中である（レコード２１６）。「20100101 10:12」に、病院（Ｘ４，Ｙ４）に到着し（レコード２１９）、「20100101 10:14」においては、消防署１に戻る道路上のある点（Ｘｈ，Ｙｈ）を走行中であり（レコード２２２）、20100101 10:16」に、消防署１（Ｘ１，Ｙ１）に到着している（レコード２２５）。
【００２０】
消防車両「消００１」についても、図２のレコード２０２、２０５、２０８、２１１、２１４、２１７、２２０及び２２３を参照すれば、（詳細は省略するが）消防署２（Ｘ２，Ｙ２）を「20100101 10:00」に「出動」した後、消防署２（Ｘ２，Ｙ２）に「20100101 10:14」に「引揚」げた経過が確認できる。消防車両「消００２」についても、図２のレコード２０３、２０６、２０９、２１２、２１５、２１８、２２１及び２２４を参照すれば、（詳細は省略するが）消防署３（Ｘ３，Ｙ３）を「20100101 10:00」に「出動」した後、消防署３（Ｘ３，Ｙ３）に「20100101 10:14」に「引揚」げた経過が確認できる。
【００２１】
（道路情報データ）
図４に沿って、道路情報データ３２を説明する。
道路情報データ３２においては、オブジェクトＩＤ欄１１１に記憶されたオブジェクトＩＤに関連付けて、種類欄１１２には種類が、位置欄１１３には位置情報が、端点欄１１４には端点情報が、幅員欄１１５には幅員が、範囲欄１１６には範囲が記憶されている。
【００２２】
オブジェクトＩＤ欄１１１のオブジェクトＩＤは、地図上のオブジェクトを一意に特定する識別子である。オブジェクトとは、地図上の、点及び図形（地物）である。
種類欄１１２の種類は、オブジェクトの種類である。本来地図には、多くの種類の図形が存在するが、ここでは、単純化のため、オブジェクトの種類として「ノード」、「道路」及び「施設」が存在するものとする。「ノード」とは位置情報のみを有する点であり、典型的には交差点（の中心点）である。「道路」（「リンク」ともいう）とは、２つのノードを両端に有し、ある幅員を有する道路（図形としては長方形）である。「施設」とは、１つのノードを中心に有する建物等（図形としては長方形）である。
【００２３】
位置欄１１３の位置情報は、ノードが存在する位置を示す２次元座標値である。ここでは、経度を示す「Ｘ」及び緯度を示す「Ｙ」の組合せである。一般的なＧＰＳ技術によって位置情報が取得できるものとする。位置欄１１３の値として、すべて「（Ｘ，Ｙ）」が便宜的に記載されているが、実際には、別々の値が記憶されているものとする。
端点欄１１４の端点情報は、道路の両端のノードのオブジェクトＩＤの組み合わせ、又は、施設の中心のノードのオブジェクトＩＤである。
幅員欄１１５の幅員は、道路の幅、又は施設の縦横の長さである。
【００２４】
範囲欄１１６の範囲は、オブジェクトが地図上に占める長方形の４つの頂点の位置情報の組合せである。４つの位置情報のそれぞれが、経度及び緯度の組合せとなっている。図４においては、範囲欄１１６の値として、すべて「（x，y），（x，y），（x，y），（x，y）」が便宜的に記載されているが、実際には、別々の値が記憶されているものとする。
なお、種類欄１１２に「ノード」が記憶されているレコードの端点欄１１４、幅員欄１１５及び範囲欄１１６は空欄である。種類欄１１２に「道路」又は「施設」が記憶されているレコードの位置欄１１３は空欄である。
道路情報データ３２のレコードのうち、種類欄１１２に「道路」を有するレコードは、更に欄を設けて、例えば、一方通行等の規制、高架橋の高さ、道路工事の申請の有無等に関する情報を記憶するようにしてもよい。
【００２５】
図５に沿って、「ノード」、「道路」及び「施設」の関係を説明する。
図５のノード「Ｂ００１」は、図４のレコード２３１を平面上に表示したものである。図５のノード「Ｂ００２」は、図４のレコード２３２を平面上に表示したものである。図５の道路「Ｂ１０１」は、ノード「Ｂ００１」及び「Ｂ００２」を端点に有する線分である。そして当該道路「Ｂ１０１」は、幅員「１０」を有している。すなわち、図５の破線の長方形２５１は、図４のレコード２３６を平面上に表示したものに他ならない。そして、図５の長方形２５１の幅員が、図４のレコード２３６の幅員に対応し、図５の長方形２５１の４つの頂点が、図４のレコード２３６の範囲欄１１６に記憶された４つの位置情報に相当する。同様に、図５の破線の長方形２５２及び２５３は、図４のそれぞれレコード２３７及び２３８を平面上に表示したものである。
【００２６】
同様に、図５の破線の長方形２５４は、図４の道路情報データ３２のレコード２３９を、平面に表示した結果である。図４の道路情報データ３２のうち「施設」に関するレコード（行）については、別途欄を設けて、その欄に、例えば図５の破線の長方形の辺が横軸（縦軸）に対しなす角度を記憶させてもよいし、破線の長方形に付して表示する文字列（建物名等を示す）を記憶させてもよい。要するに、図４の道路情報データ３２は、道路及び建物を有する地図を作成し、表示するためのデータである。
【００２７】
（処理手順）
以降、本実施形態の処理手順を説明する。処理手順には、（１）位置情報履歴データ作成処理手順及び（２）走行ルート表示処理手順がある。（１）の処理手順は、車両が出動するたびに実行される。（２）の処理手順は、消防車両走行ルート管理システム１の管理者が指定する任意のタイミングで実行される。（２）の処理手順が実行されるためには、少なくとも１度（１）の処理手順が実行され、位置情報履歴データ３１が作成されていることが前提となる。
【００２８】
（位置情報履歴データ作成処理手順）
図６については後記することとし、図７に沿って、位置情報履歴データ作成処理手順を説明する。
ステップＳ３０１において、車両端末装置４は、起動指示を受け付ける。具体的には、車両端末装置４は、ユーザ（車両の運転手、消防士等）が、車両の位置情報処理用のアプリケーション（図示せず）を起動させる指示を、入力装置を介して入力するのを受け付ける。以降において、車両端末装置４の動作主体は、当該アプリケーションである。
なお、車両端末装置４が、データ通信カードを利用したモバイル回線等を介して、１１９番通報を受ける指令システム（図示せず）から出動指令情報を受け付けてもよい。この場合は、ユーザからの手動の指示がなくとも、車両端末装置４は、自動的に起動指示を受け付けることができる。
【００２９】
ステップＳ３０２において、車両端末装置４は、事案ＩＤを受け付ける。具体的には、車両端末装置４は、ユーザが、事案ＩＤを、入力装置を介して入力するのを受け付ける。例えば、災害の通報を受信した本部等が、事案ＩＤを採番し、当該事案ＩＤを当該災害が発生した地域の消防署の任意の装置に送信し、当該消防署の任意の装置は、車両が出動する直前に、ユーザに知らしめてもよい。さらに、当該消防署の任意の装置は、車両端末装置４に対し、事案ＩＤを無線等で直接送信してもよい。
【００３０】
ステップＳ３０３において、車両端末装置４は、位置情報等を送信する。具体的には、車両端末装置４は、第１に、位置情報（車両の存在する緯度及び経度）を、ＧＰＳ技術を使用して取得する。
第２に、ユーザが、動態情報を、入力装置を介して入力するのを受け付ける。アプリケーションが起動した後最初に入力される動態情報は、「出動」である。パネル上に表示された「出動」等のアイコンをユーザが選択することによって入力を受け付けてもよいし、ユーザの肉声を車両端末装置４が「出動」等の文字列に変換してもよい。
第３に、ステップＳ３０２において受け付けた事案ＩＤ、ステップＳ３０３の「第１」において取得した位置情報、及び、ステップＳ３０３の「第２」において受け付けた動態情報に、車両ＩＤ及び登録時刻（現在の時刻）を付して、データ格納サーバ２に送信する。
【００３１】
ステップＳ３０４において、データ格納サーバ２の位置情報管理部２１は、位置情報履歴データ３１のレコードを作成する。具体的には、位置情報管理部２１は、第１に、ステップＳ３０３の「第３」において送信された事案ＩＤ、位置情報、動態情報、車両ＩＤ及び登録時刻を受信する。
第２に、位置情報履歴データ３１（図２）の新たなレコードを作成する。
第３に、作成したレコードの車両ＩＤ欄１０１、事案ＩＤ欄１０２、登録時刻欄１０３、位置欄１０４及び動態欄１０５に、ステップＳ３０４の「第１」において受信した、車両ＩＤ、事案ＩＤ、登録時刻、位置情報及び動態情報を、それぞれ記憶する。
【００３２】
ステップＳ３０５において、車両端末装置４は、最後に送信した動態情報が「引揚」であるか否かを判断する。具体的には、車両端末装置４は、ステップＳ３０３の「第３」において送信した動態情報が「引揚」である場合（ステップＳ３０５“ＹＥＳ”）は、位置情報履歴データ作成処理手順を終了し、それ以外の場合（ステップＳ３０５“ＮＯ”）は、ステップＳ３０３に戻る。
【００３３】
ステップＳ３０３は繰り返し実行されることになる。２回目以降のステップＳ３０３の「第２」においては、動態情報として、消防車両については、「往路」、「現着」、「消火中」、「現発」、「復路」及び「引揚」が、救急車両については、「往路」、「現着」、「処置中」、「現発」、「搬送中」、「病院着」、「復路」及び「引揚」が、この順序で入力されることになる。「往路」、「消火中」、「復路」、「処置中」及び「搬送中」については、連続して複数回入力されることもある。
また、車両端末装置４は、位置情報等をデータ格納サーバ２に前回送信した時刻を記憶しており、当該時刻から所定の時間（例えば２分）を経過した時点で、ユーザに対し、音声等で、動態情報の入力を促してもよい。
【００３４】
さらに、車両端末装置４は、消防署の位置情報、病院の位置情報及び災害現場の位置情報（通報を受け付けた際に特定できる）を記憶しているものとし、ステップＳ３０３の「第２」において以下の規則にしたがって動態情報を自動的に生成してもよい。そして、生成した動態情報を、ステップＳ３０３の「第３」以降の処理において、ユーザから入力を受け付けた動態情報に代替して取り扱うものとしてもよい。
【００３５】
すなわち、車両が消防車両である場合は、当該規則は以下の通りである。
（１）ＧＰＳ技術を用いて取得した車両の位置情報が、記憶されている消防署の位置情報と同じ（又は所定の誤差範囲内にある）場合は、「出動」（初回）又は「引揚」（２回目）を生成する。
（２）ＧＰＳ技術を用いて取得した車両の位置情報が、記憶されている災害現場の位置情報と同じ（又は所定の誤差範囲内にある）場合は、「現着」（初回）、「消火中」（２回目以降）又は「現発」（最終回）を生成する。
（３）ＧＰＳ技術を用いて取得した車両の位置情報が、記憶されている消防署の位置情報とも災害現場の位置情報とも異なる（又は所定の誤差範囲外にある）場合は、「往路」（「現着」が生成される前）又は「復路」（「現発」が生成された後）を生成する。
【００３６】
また、車両が救急車両である場合は、当該規則は以下の通りである。
（１）ＧＰＳ技術を用いて取得した車両の位置情報が記憶されている消防署の位置情報と同じ（又は所定の誤差範囲内にある）場合は、「出動」（初回）又は「引揚」（２回目）を生成する。
（２）ＧＰＳ技術を用いて取得した車両の位置情報が、記憶されている災害現場の位置情報と同じ（又は所定の誤差範囲内にある）場合は、「現着」（初回）、「処置中」（２回目以降）又は「現発」（最終回）を生成する。
（３）ＧＰＳ技術を用いて取得した車両の位置情報が、記憶されている病院の位置情報と同じ（又は所定の誤差範囲内にある）場合は、「病院着」を生成する。
（４）ＧＰＳ技術を用いて取得した車両の位置情報が、記憶されている消防署の位置情報とも災害現場の位置情報とも異なる（又は所定の誤差範囲外にある）場合は、「往路」（「現着」が生成される前）、「搬送中」（「現発」が生成された後）又は「復路」（「病院着」が生成された後）を生成する。
【００３７】
（走行ルート表示処理）
図８及び図９に沿って、走行ルート表示処理を説明する。
ステップＳ４０１において、ユーザ端末装置５は、事案を選択する。具体的には、ユーザ端末装置５は、第１に、ユーザ（管理者）が事案ＩＤを、入力装置を介して入力するのを受け付ける。
第２に、受け付けた事案ＩＤをＷｅｂサーバ３に送信する。
【００３８】
ステップＳ４０２において、Ｗｅｂサーバ３の位置情報・道路情報取得部５１は、選択された事案に関するデータを要求する。具体的には、位置情報・道路情報取得部５１は、第１に、ステップＳ４０１の「第２」において送信された事案ＩＤを受信する。
第２に、受信した事案ＩＤをデータ格納サーバ２に送信する。
【００３９】
ステップＳ４０３において、データ格納サーバ２の位置情報管理部２１は、位置情報履歴データ３１を検索する。具体的には、位置情報管理部２１は、第１に、ステップＳ４０２の「第２」において送信された事案ＩＤを受信する。
第２に、事案ＩＤを検索キーとして、位置情報履歴データ３１（図２）を検索し、該当したレコード（行）をすべて取得する。ここで取得されたレコードを以降「対象レコード」と呼ぶことがある。図２の位置情報履歴データ３１は、複数の事案ＩＤについての多くのレコードを有する。ここでは例として、事案ＩＤ「Ａ００１」を検索キーとして検索した結果、「Ａ００１」を事案ＩＤ欄１０２に有するレコード、すなわち図２のレコード２０１〜２２５が、対象レコードとして取得されたものとする。
【００４０】
ステップＳ４０４において、データ格納サーバ２の道路情報管理部２２は、道路情報データ３２を検索する。具体的には、道路情報管理部２２は、第１に、すべての対象レコードに含まれる位置情報のうち最大の緯度、最小の緯度、最大の経度及び最小の経度によって四辺が区画される長方形の領域を特定する。当該領域を以降「表示予定領域」と呼ぶことがある。このとき、上下左右にそれぞれ所定の緯度（経度）を余裕として加え、表示予定領域を特定してもよい。
第２に、道路情報データ３２（図４）を検索し、種類欄１１２に「ノード」を有し、かつ、位置欄１１３の位置情報が表示予定領域内に属するレコードを取得する。ここでは、レコード２３１〜２３５を含むレコード群が取得されたものとする。
【００４１】
第３に、ステップＳ４０４の「第２」において取得されたレコードのすべてのオブジェクトＩＤを検索キーとして、道路情報データ３２（図４）を検索し、種類欄１１２に「道路」を有し、かつ、検索キーとしたオブジェクトＩＤと同じオブジェクトＩＤを端点欄１１４に少なくとも１つ有するレコードをすべて取得する。ここでは、レコード２３６〜２３８を含むレコード群が取得されたものとする。
第４に、ステップＳ４０４の「第２」において取得されたレコードのすべてのオブジェクトＩＤを検索キーとして、道路情報データ３２（図４）を検索し、種類欄１１２に「施設」を有し、かつ、検索キーとしたオブジェクトＩＤと同じオブジェクトＩＤを端点欄１１４に有するレコードをすべて取得する。ここでは、レコード２３９、２４０を含むレコード群が取得されたものとする。
なお、ステップＳ４０４の「第２」、「第３」及び「第４」において取得されたレコード群を以降「背景レコード」と呼ぶことがある。この時点での背景レコードは、車両が走行した可能性のある道路に対応するレコード、車両が走行した地点の付近にある施設に対応するレコード及びこれらの道路及び施設を特定するために必要な「ノード」についてのレコードである。
【００４２】
ステップＳ４０５において、データ格納サーバ２の道路情報管理部２２は、検索したデータを送信する。具体的には、道路情報管理部２２は、背景レコード及び対象レコードをＷｅｂサーバ３に送信する。
【００４３】
ステップＳ４０６において、Ｗｅｂサーバ３のマッチング部５２は、選択された事案に関するデータを受信する。具体的には、マッチング部５２は、ステップＳ４０５において送信された背景レコード及び対象レコードを受信する。
【００４４】
ステップＳ４０７において、Ｗｅｂサーバ３のマッチング部５２は、位置情報履歴データ３１と道路情報データ３２とをマッチングする。
具体的には、マッチング部５２は、第１に、対象レコードに含まれる車両ＩＤのうち任意の１つを選択する。当該選択された車両ＩＤを、以降「対象車両ＩＤ」と呼ぶことがある。ここでは、例えば、「救００１」が選択されたとする。
第２に、対象レコードから対象車両ＩＤを有するレコードをすべて取得し、登録時刻の順に並び替える。「救００１」を有するレコード（図２）が、レコード２０１、２０４、２０７、２１０、２１３、２１６、２１９、２２２及び２２５の順に並ぶことになる。
【００４５】
第３に、並び替えられた対象レコードのうちｎ番目のレコードの位置情報が、種類「道路」を有する背景レコードのうちｍ番目のレコードの範囲欄１１６に記憶された範囲内に存在するか否かを判断し、存在する場合は、種類「道路」を有する背景レコードのうちｍ番目のレコードに「＃」のようなフラグを立てる。当該処理は、ｎ＝１を基準に、ｍ＝１，２，３，４，・・・について実行し、その後、ｎ＝２を基準に、ｍ＝１，２，３，４，・・・について実行し、・・・のように繰り返し実行される。
第４に、フラグ「＃」が立てられたレコードのみを抽出し、さらにフラグ「＃」が立てられた順に並び替える。このように抽出され並び替えられたレコードを、以降「表示予定道路レコード」と呼ぶことがある。
当該繰り返し処理が終了した時点で、車両ＩＤが「救００１」である車両が走行した道路に対応する背景レコードが、当該車両が走行した順に、表示予定道路レコードとして並んでいることになる。なお「ノード」又は「施設」を含む背景レコードはそのまま残る。
このとき、表示予定道路レコードは、図４のレコード２３６〜２３８であったとする。
【００４６】
ステップＳ４０８において、Ｗｅｂサーバ３のルート補完処理部５３は、ルートが連続するか否かを判断する。
具体的には、ルート補完処理部５３は、第１に、表示予定道路レコードの端点欄１１４に記憶されているオブジェクトＩＤが連続しているか否かを判断する。例えば、図４のレコード２３６の端点欄１１４の「Ｂ００２」は、レコード２３７の端点欄１１４にも記憶されている。このような場合、オブジェクトＩＤは連続していると判断される。つまり、レコード２３６及び２３７に対応する道路は、連続して繋がったものとして表示されることが可能である。さらに、レコード２３７の端点欄１１４の「Ｂ００３」は、レコード２３８の端点欄１１４にも記憶されている。このような場合、オブジェクトＩＤは連続していると判断される。つまり、レコード２３７及び２３８に対応する道路も、連続して繋がったものとして表示されることが可能である。
ルート補完処理部５３は、このように表示予定道路レコードを２つずつ対比して、それらのオブジェクトＩＤが連続しているか否か（すなわち共通するオブジェクトＩＤを有するか否か）を判断することができる。
【００４７】
第２に、連続していないと判断された前後（レコードの位置としては上下）２つのレコードの組のオブジェクトＩＤ（欄１１１）を保持する。図４の例では、保持すべきオブジェクトＩＤは存在しない。しかしながら、仮に図４において、レコード２３８の端点欄１１４に「Ｂ００４，Ｂ００５」が記憶されていた場合、ルート補完処理部５３は、レコード２３７及び２３８を、オブジェクトＩＤが連続していない前後２つのレコードの組であると判断することになる。
第３に、連続していないと判断された前後２つのレコードの組が存在する場合（ステップＳ４０８“ＮＯ”）は、ステップＳ４０９に進み、それ以外の場合（ステップＳ４０８“ＹＥＳ”）は、ステップＳ４１０に進む。
【００４８】
次に説明するステップＳ４０９の処理に関連し、図６に沿ってルート補完の考え方を説明する。
表示予定道路レコードが、例えば３つ存在するとする。そして、第１のレコードと第２のレコードの組は、オブジェクトＩＤが連続していない前後２つのレコードの組であるとする。同様に、第２のレコードと第３のレコードの組もオブジェクトＩＤが連続していない前後２つのレコードの組であるとする。図６は、第１のレコード、第２のレコード及び第３のレコードを平面に表示した図である。破線の長方形２６１、２６２及び２６３は、それぞれ、第１のレコード、第２のレコード及び第３のレコードに対応する。車両端末装置４が位置情報等をデータ格納サーバ２に送信する（図７のステップＳ３０３）間隔が長い場合、ステップＳ４０７の「第３」において、実際に車両が走行した道路に対応する背景レコードのすべてに対して、フラグ「＃」を立てることは不可能になる。その結果、図６の円形の領域２６４及び２６５のような、破線の長方形が連続しない「ルート未確定領域」が発生する。このようなルート未確定領域ごとに、車両が走行したであろう１又は複数の道路を推定することが、ルート補完の処理に他ならない。
【００４９】
図９に戻って、ステップＳ４０９において、Ｗｅｂサーバ３のルート補完処理部５３は、ルートを補完する。具体的には、ルート補完処理部５３は、第１に、ステップＳ４０８の「第１」において、オブジェクトＩＤが連続していないと判断された前後２つのレコードの組のうち、任意の組を選択する。
第２に、選択した組の２つのレコードの端点欄１１４に記憶されている４つのオブジェクトＩＤ（端点である「ノード」を示す）のうちから、同一のレコードに属さない２つを特定する。このとき、４つのノードのうち、当該組に属さない他のレコードと連続しているノードは除外される。例えば、今、図６のルート未確定領域２６４の道路を推定するとする。仮に、ノード２６９とノード２７０とが一致している場合は、ノード２６９は無視し、ノード２６６及びノード２６８の組、又はノード２６７及びノード２６８の組が、特定される候補となり得る。
このように複数の候補がある場合、表示予定道路レコードの端点欄１１４のオブジェクトＩＤを検索キーとして、種類「ノード」を有する背景レコードの位置情報を取得することによって、ノード２６６及びノード２６８の間の距離、並びに、ノード２６７及びノード２６８の間の距離を計算する。そして、最も距離が短いノード同士に対応するオブジェクトＩＤを２つ特定する。この場合、ノード２６７及びノード２６８に対応するオブジェクトＩＤが特定される。
【００５０】
第３に、特定した２つのオブジェクトＩＤを検索キーとして、背景レコード検索し、種類欄１１２に「道路」を有し、かつ、検索キーとした２つのオブジェクトＩＤを端点欄１１４に有するレコードを取得する。当該取得したレコードを、以降「補完レコード」と言うことがある。このとき、補完レコードが存在しない場合がありうる。例えば、図６のルート未確定領域２６５において、ノード２６９及びノード２７０の間の道路を推定しようとするものの、符号２７２の道路が存在しない場合である。
このような場合は、ルート補完処理部５３は、以下の処理を実行する。
【００５１】
（１）：２つの「道路」によって補完する。
すなわち、種類「道路」を有する背景レコードから、ノード２６９に対応するオブジェクトＩＤを有する複数の背景レコード群と、ノード２７０に対応するオブジェクトＩＤを有する複数の背景レコード群とを抽出する。その後、ある１つのノードに対応するオブジェクトＩＤを共有する２つのレコードを、それぞれの群から１つずつ抽出し、補完レコードとする。このような２つのレコードの組が複数存在する場合は、ノード２６９から「ある１つの点」を経由してノード２７０に至る距離が最短であるような２つのレコードを、それぞれの群から１つずつ抽出し、補完レコードとする。このような補完レコードは、図６における、例えば破線２７４及び２７５に対応している。
【００５２】
（２）：（１）の処理によっても補完レコードが存在しない場合は、３つの「道路」によって補完する。
すなわち、（１）の処理において、例えばノード２６９に対応するオブジェクトＩＤを有する複数の背景レコード群の内の任意の１つのレコードをレコード（ａ）とする。そしてレコード（ａ）の他方のオブジェクトＩＤを有する複数の背景レコード群（ｂ）と、ノード２７０に対応するオブジェクトＩＤを有する複数の背景レコード群（ｃ）とを抽出する。その後、ある１つの点に対応するオブジェクトＩＤを共有する２つのレコードを、（１）の処理と同様に、レコード群（ｂ）及びレコード群（ｃ）から１つずつ抽出し、任意のレコード（ａ）とあわせて３つの補完レコードとする。つまり、例えばノード２７３とノード２７０との間を補完するような２つの補完レコードを（１）の処理に準じて実行する。このような補完レコードは、図６における、例えば破線２７６、２７７及び２７８に対応している。
また、レコード（ａ）を他の候補に代替し、３つの補完レコードの組の候補を取得し、合計距離が最短であるような組の３つのレコードを補完レコードとしてもよい。
【００５３】
（３）：（２）の処理によっても補完レコードが存在しない場合は、ｐ個（ｐ＝４，５，・・・）の「道路」によって補完する。処理の内容は、（２）に準ずる。ある閾値を設定して、ｐの値が当該閾値以上となってもなお補完レコードが存在しない場合は、「補完すべき道路がありません」のようなメッセージを生成する。そして、次の「第４」の処理は実行しない。ただし、このようなことは、当該事案が発生した後、道路情報データ３２が変更された場合（道路の付け替えのような場合）等を除けば、通常はあり得ない。
【００５４】
第４に、補完レコードを、ステップＳ４０８の「第１」において、オブジェクトＩＤが連続していないと判断された前後２つのレコードの組の間に挿入する。「補完すべき道路がありません」のようなメッセージが生成されたときは、当該メッセージを有するダミーのレコードを挿入する。
【００５５】
ステップＳ４０７〜Ｓ４０９の処理は、対象レコードに含まれるすべての車両ＩＤについて繰り返される。ステップＳ４０９の処理から抜けた段階で、Ｗｅｂサーバ３は、例えば、図１０のような対象レコード及び図１１のような背景レコードを一時的に記憶していることになる。
【００５６】
図１０の対象レコードは、前記したように、位置情報履歴データ３１（図２）の一部に基づいて作成されたものである。したがって、各欄の名称と符号は図２と同じである。しかしながら、レコードは、ステップＳ４０１において入力を受け付けた事案ＩＤ「Ａ００１」を有するものだけに限定されている。
なお、以降の説明の単純化のために、図１０のデータは、以前に説明した例とは直接関係を有さない（整合性を無視する）ものとする。例えば、事案ＩＤ「Ａ００１」を有する対象レコードは、車両ＩＤが「救００１」であるもの（レコード２８１ａ〜２８１ｄを含む）、及び車両ＩＤが「消００１」であるもの（レコード２８２ａ〜２８２ｃを含む）だけであるとする。そして、対象レコードは、実際には図１０に示されるより多く存在するが、単純化のために、以降では、動態情報として「出動」、「往路」及び「現着」を有するレコードについてのみを説明する。
【００５７】
図１０を参照すると、車両ＩＤが「救００１」である救急車両及び車両ＩＤが「消００１」である消防車両は、何れも、「20100102 12：00」に「出動」している（レコード２８１ａ、２８２ａ）。しかしながら、「現着」の時刻は、「消００１」については「20100102 12：04」である（レコード２８２ｃ）のに対し、「救００１」については「20100102 12：06」である（レコード２８１ｄ）。ユーザ（管理者）は、なぜ当該救急車両が災害現場に到着するのが遅れたのか知りたくなる（詳細後記）。
【００５８】
図１１の背景レコードは、前記したように、道路情報データ３２（図４）の一部に基づいて作成されたものである。したがって、各欄の名称と符号は図４と同じである。
図１１の背景レコードは、大きくわけて、種類「ノード」を有するもの（レコード２８３ａ〜２８３ｃを含む）、種類「道路」を有するもの（レコード２８４ａ〜２８４ｄ、２８５ａ、２８５ｂを含む）及び種類「施設」を有するもの（レコード２８６ａ〜２８６ｃを含む）の３つの群に分かれる。
【００５９】
種類「道路」を有するレコードは、当初取得された背景レコードのうちから、実際に車両が走行した道路に対応するレコードに絞り込まれた「表示予定道路レコード」である。さらに、レコード２８４ａ〜２８４ｄは、車両ＩＤが「救００１」である救急車両についてのものであり、さらに、そのうちレコード２８４ｃは、当該車両が実際に走行したか否かが不明であるが、前後関係を基に、走行しているものと推定した道路に対応する「補完レコード」である（左欄外に「補完」と記載）。レコード２８５ａ及び２８５ｄは、車両ＩＤが「消００１」である消防車両についてのものである。
【００６０】
図９に戻る。ステップＳ４１０において、Ｗｅｂサーバ３の表示処理部５４は、画面表示用のデータを送信する。具体的には、表示処理部５４は、図１０の対象レコード及び図１１の背景レコードを、動画表示用のアプリケーション（図示せず）とともにユーザ端末装置５に送信する。
【００６１】
ステップＳ４１１において、ユーザ端末装置５は、走行ルートを表示する。具体的には、ユーザ端末装置５は、第１に、ステップＳ４１０において送信された対象レコード、背景レコード及び動画表示用のアプリケーションを受信する。（以降の動作主体は当該アプリケーションである。但し他例について詳細後記。）
第２に、受信した背景レコードに基づき、走行ルート表示画面６１（図１２）を出力装置に表示する。例えば、図１１のレコード２８４ａの範囲欄１１６の範囲を図形表示すると、図１２の破線の長方形２９１ｄとなる。同様に、図１２の破線の長方形のうち、道路を表す長方形２９１ｅ、２９１ｆ及び２９１ｇは、それぞれ、図１１のレコード２８４ｂ、２８４ｃ及び２８４ｄに対応している。このうち太線で示した長方形２９１ｆは、「補完レコード」（図１１のレコード２８４ｃ）が作成されてはじめて表示され得る。図１２の破線の長方形のうち、道路を表す長方形２９１ｉ及び２９１ｈは、それぞれ、図１１のレコード２８５ａ及び２８５ｂに対応している。図１２の破線の長方形のうち、施設を表す長方形２９１ａ、２９１ｂ及び２９１ｃは、それぞれ、図１１のレコード２８６ａ、２８６ｂ及び２８６ｃに対応している。
なお、ユーザ端末装置５は、メッセージを有するダミーレコードに基づいて、前後の表示予定道路レコードに対応する道路の間の領域に、メッセージの文言を表示する。
【００６２】
図１２における「消防署１」等の文字は、例えば、道路情報データ３２の種別が「施設」であるレコードに欄を設け記憶しておくことによって、走行ルート表示画面６１に表示することができる。
なお、前記の例では、表示される道路は「表示予定道路レコード」に対応する道路のみである。しかしながら、表示処理部５４は、種類「道路」を有する背景レコードすべてを表示し、そのうち、表示予定道路レコードに対応する道路を強調表示してもかまわない。
【００６３】
第３に、受信した対象レコードのすべてのレコードの位置情報、登録時刻及び動態情報の組を、走行ルート表示画面６１に重ねて表示する。この段階での走行ルート表示画面６１は、図１３に示した通りである。
例えば、図１０のレコード２８１ａの、位置情報、登録時刻のうちの時分及び動態情報を表示すると、それぞれ、図１３の「×」２９２ａ、「12：00」２９２ｂ及び「出動」２９２ｃとなる。同様に、図１０のレコード２８１ｂの位置情報、登録時刻のうちの時分及び動態情報は、それぞれ、図１３の「×」２９３ａ、「12：02」２９３ｂ及び「往路」２９３ｃに対応している。以下同様に、図１０のレコード２８１ｃ、２８１ｄ、２８２ａ、２８２ｂ及び２８２ｃは、それぞれ、図１３の符号２９４ａ〜ｃ、２９５ａ〜ｃ、２９６ａ〜ｃ、２９７ａ〜ｃ及び２９８ａ〜ｃに対応している。
【００６４】
第４に、受信した対象レコードのすべてのレコードに基づき、車両を示すアイコンを、走行ルート表示画面６１に重ねて表示する。この段階での走行ルート表示画面６１は、図１４に示した通りである。図１４においては、車両ＩＤが「救００１」である救急車両を示すアイコン２９９ａが、図１３の「×」２９２ａに置き換わって表示されている。同じ救急車両を示すアイコン２９９ｂが、図１３の「×」２９３ａに置き換わって表示されている。同様に、車両ＩＤが「消００１」である消防車両を示すアイコン２９９ｃが、図１３の「×」２９６ａに置き換わって表示されている。同じ消防車両を示すアイコン２９９ｄが、図１３の「×」２９７ａに置き換わって表示されている。
アイコンは、すべての登録時刻について一度に表示されてもよいし、登録時刻が早い順に、１ずつ表示されてもよい（図１４の例）。そして、ある登録時刻のアイコンが表示されてから次の登録時刻のアイコンが表示されるまでの時間は、両者の登録時刻の差分に基づいて決定されてもよい。
【００６５】
なお、前記したような、対象レコードの数だけ離散的にアイコンを表示する方法に替わって、アイコンを動的に表示してもよい。例えば、「車両が１分間に進む実際の道路上の距離を、対応する画面上では１秒でアイコンが進む」のような換算率を設定しておき、当該率で、アイコンを移動させてもよい。このようにすると、走行ルート表示画面６１上では、２秒間の間に、救急車両を示すアイコンは符号２９９ａの位置から符号２９９ｂの位置へ移動し、消防車両を示すアイコンは符号２９９ｃの位置から符号２９９ｄの位置へ移動する。
以上の処理の後、走行ルート表示処理を終了する。
【００６６】
なお、前記の実施形態では、Ｗｅｂサーバ３はユーザ端末装置５に、対象レコード、背景レコード及び動画表示用のアプリケーションを渡し切ることとした。しかしながら、Ｗｅｂサーバ３とユーザ端末装置５との間で連続的に通信を確保しながら、Ｗｅｂサーバ３の表示処理部５４が主体となって、前記ステップＳ４１１の処理（走行ルート表示画面６１をユーザ端末装置５の出力装置に表示させる）を実行してもよい。
【００６７】
走行ルート表示画面６１（図１４）視認したユーザ（管理者）は、例えば、救急車両を示すアイコンの移動速度、消防署１から災害現場へ至る道路の幅員等から、以下のことを容易に理解できる。すなわち、「もし、当該災害現場の付近で災害が頻発し、消防署１の支援を受けざるを得ないのであれば、消防署１から当該災害現場へ至る道路の幅員を拡大することが有効である」と言うことである。
【００６８】
本発明は、前記した実施形態に限定されることなく、本発明の趣旨を逸脱しない範囲で、変更実施が可能である。
【符号の説明】
【００６９】
１ 消防車両走行ルート管理システム
２ データ格納サーバ
３ Ｗｅｂサーバ
４ 車両端末装置
５ ユーザ端末装置
１１、４１ 中央制御装置（制御部）
１２、４２ 主記憶装置（記憶部）
１３、４３ 補助記憶装置（記憶部）
１４、４４ 通信装置
１５、４５ 入力装置
１６、４６ 出力装置
２１ 位置情報管理部
２２ 道路情報管理部
３１ 位置情報履歴データ
３２ 道路情報データ
５１ 位置情報・道路情報取得部
５２ マッチング部
５３ ルート補完処理部
５４ 表示処理部
６１ 走行ルート表示画面
【特許請求の範囲】
【請求項１】
特定の場所に向かい走行する車両に関連付けて前記車両の位置を時系列で記憶した車両位置情報と、
前記車両が走行し得る道路に関連付けて前記道路の位置を記憶した道路位置情報と、
に対しアクセス可能な車両走行ルート表示装置であって、
前記車両の位置に基づいて、前記道路位置情報から前記車両が走行する道路を抽出し、
前記抽出した道路を表示し、
前記表示した道路に沿って、前記車両を示す図形を時系列で移動させて表示する制御部を有すること、
を特徴とする車両走行ルート表示装置。
【請求項２】
前記制御部は、
前記抽出した道路が連続するか否かを判断し、
連続しない場合は、連続しない区間の前後の道路の位置に基づき、前記連続しない区間の道路を推定すること、
を特徴とする請求項１に記載の車両走行ルート表示装置。
【請求項３】
前記車両位置情報は、
前記車両に関連付けて、前記車両の活動状況を示す動態情報を記憶しており、
前記制御部は、
前記車両を示す図形に対応付けて、前記動態情報を表示すること、
を特徴とする請求項１に記載の車両走行ルート表示装置。
【請求項４】
前記制御部は、
前記車両を示す図形を動画として表示すること、
を特徴とする請求項１に記載の車両走行ルート表示装置。
【請求項１】
特定の場所に向かい走行する車両に関連付けて前記車両の位置を時系列で記憶した車両位置情報と、
前記車両が走行し得る道路に関連付けて前記道路の位置を記憶した道路位置情報と、
に対しアクセス可能な車両走行ルート表示装置であって、
前記車両の位置に基づいて、前記道路位置情報から前記車両が走行する道路を抽出し、
前記抽出した道路を表示し、
前記表示した道路に沿って、前記車両を示す図形を時系列で移動させて表示する制御部を有すること、
を特徴とする車両走行ルート表示装置。
【請求項２】
前記制御部は、
前記抽出した道路が連続するか否かを判断し、
連続しない場合は、連続しない区間の前後の道路の位置に基づき、前記連続しない区間の道路を推定すること、
を特徴とする請求項１に記載の車両走行ルート表示装置。
【請求項３】
前記車両位置情報は、
前記車両に関連付けて、前記車両の活動状況を示す動態情報を記憶しており、
前記制御部は、
前記車両を示す図形に対応付けて、前記動態情報を表示すること、
を特徴とする請求項１に記載の車両走行ルート表示装置。
【請求項４】
前記制御部は、
前記車両を示す図形を動画として表示すること、
を特徴とする請求項１に記載の車両走行ルート表示装置。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【公開番号】特開２０１２−１１８７００（Ｐ２０１２−１１８７００Ａ）
【公開日】平成２４年６月２１日（２０１２．６．２１）
【国際特許分類】
【出願番号】特願２０１０−２６７０６３（Ｐ２０１０−２６７０６３）
【出願日】平成２２年１１月３０日（２０１０．１１．３０）
【出願人】（０００２３３０４４）株式会社日立エンジニアリング・アンド・サービス (276)
【Ｆターム（参考）】
【公開日】平成２４年６月２１日（２０１２．６．２１）
【国際特許分類】
【出願日】平成２２年１１月３０日（２０１０．１１．３０）
【出願人】（０００２３３０４４）株式会社日立エンジニアリング・アンド・サービス (276)
【Ｆターム（参考）】
[ Back to top ]