「情報連携用語彙データベースと連携するデータ設計・
作成支援ツール群の試作及び試用並びに概念モデルの構築
（浦安市都市整備部市街地開発課液状化対策推室）」
設計書
2014 年 9 月 30 日
実施企業: インディゴ株式会社
独立行政法人情報処理推進機構（IPA）
「試作ツールは、 MIT ライセンスによって提供いたします。その他、内包されたオープンソ
ース・ソフトウェアについてはそれぞれのライセンスに従ってご利用ください。」
【目次】
１． はじめに ... 4
２． 全体設計 ... 5
３． 詳細設計：地理情報データベース ... 7
システム構成 ... 7
データベース設計 ... 9
整備データ ... 11
４． 詳細設計：入力支援機能及び集計/可視化機能 ... 14
入力支援機能 ... 14
4.1.1 入力支援機能の機能要件と対応方針 ... 14
4.1.2 入力支援機能の画面遷移及び画面詳細仕様 ... 16
集計/可視化機能... 22
4.2.1 時系列優先ビュー ... 23
4.2.2 エリア優先ビュー ... 26
１．はじめに
本書は「情報連携用語彙データベースと連携するデータ設計・作成支援ツール群の試作及び試用 並びに概念モデルの構築（浦安市都市整備部市街地開発課液状化対策推進室）」にて試作したツー ルに関する設計書である。
本書の前提事項としては下記のとおり。
本事業では、別プロジェクトとして構築・運用される語彙データベースのパイロットシステ ム（以下、パイロットシステム）と連携し、そこから得られる語彙データを活用して再利用 性の高いデータの作成等に資するツールを試作（以下、試作ツール）することが前提とな る。
試作ツールに係る基本要件及び前提事項については「情報連携用語彙データベースと連携す るデータ設計・作成支援ツール群の試作及び試用並びに概念モデルの構築（浦安市都市整備 部市街地開発課液状化対策推進室）」に係る仕様書（以下、仕様書）ならびに同別紙（以 下、仕様書別紙）に準ずる。
また、本書の構成は下記のとおり。
１章（本章）では、文書の位置づけ・構成について述べる。
２章では、試作ツールの全体設計を解説する。
３章では、試作ツールの構成要素のうち、地理情報データベースに関する詳細設計を解説す る。
４章では、試作ツールの構成要素のうち、入力支援機能と集計/可視化機能に関する詳細設 計を解説する。
２．全体設計
試作ツールに係る基本要件について、仕様書および仕様書別紙では、図 1及び図 2のユースケ ース図および配置図を前提としており、全体設計においてはこれらの UML モデルを踏襲した。
図 1 仕様書別紙 ユースケース図
図 2 仕様書別紙 配置図
以上より、試作ツールの構築対象となるのは、「入力支援機能」と「地理情報データベース」の2 つであるが、本事業では仕様書別紙に定めのある「試行的運用」を行う上での利便性及び効果訴求 の観点での検討の結果、追加機能として入力支援機能により出力されたデータの集計/可視化を行 うことを主目的とした「集計/可視化機能」を構築することとした。以下では当該の追加機能を含 めた試作ツールの具体化方針を提示する。
（全般的な方針）
基本原則として、既存の OSS での充足が可能な要件に対しては、OSS を採用するものと し、新規に開発するソフトウェアでの課題解決は最小限となるように留意する
仕様書／仕様書別紙にて選択肢が提示されている内容および代替手段を導入した場合につい ては、選択の根拠を提示する
（地理情報データベースの設計ポイント）
システム設計： SPARQL Endpoint の選択
データベース設計： RDF の語彙の選択と定義
データ整備：既存データから RDF データへの変換、運用上の考察
（入力支援機能及び集計/可視化機能の設計ポイント）
利用者にとって利便性が高く、使用負荷の低いツールを目指す
運用者にとって導入やメンテナンスが容易なツールを目指す
３．詳細設計：地理情報データベース
システム構成仕様書別紙で定義するとおり、さまざまな地理識別子に関する情報を集約してデータベース化 し、API を通じて提供する機能を地理情報データベースと称する。モデリング言語として RDF、
データベースおよび API の機能を提供するサーバとして SPARQL Endpoint が提示されてお り、詳細設計においてもこれを踏襲して具体化を行った。
なお、地理情報データベースに対しては、仕様書別紙にて機能要件が提示されている。それぞれ の要件に対する対応方針は以下のとおりに整理される。
表 1 地理情報データベースに求められる機能要件（仕様書別紙より）と対応方針
機能名 機能要件 対応方針
地理情報デー タ登録機能
地理情報データを地理情報データベースに 登録する機能を有すること。
なお、地理情報データは地理情報の属性や 関係を RDF に準拠したデータモデルとし て記述したものとする。地理情報データベ ースはこのようなデータモデルを保持・検 索できることが求められる。
また、データの管理については全削除・一 括登録の方式をとるものとして、追加・部 分更新・部分削除は求めない。
SPARQL Endpoint の基本 機能によって充足
地理情報デー タ生成機能
総務省統計局の国勢調査データ（地域コー ドと当該コードの境界を示すポリゴンデー タなど）、国土交通省位置参照コード（構造 化住所、ID、代表点の緯度経度座標など）、
郵便番号データ（郵便番号と対応する地域 コード、構造化住所など）、道路データ（識 別子/名称、幾何情報）他の地理識別子デー タを、地理情報データベースが受け入れ可 能な形式のデータ（RDF 準拠の諸形式）に 変換する機能を提供すること。
GISソフトウェアを介したデ ータ加工作業として実施
本機能は地理情報データベースの機能拡張 として実装してもよいし、単独で動作する アプリケーションとして実装してもかまわ ない。
検索機能 (Web API)
地理情報データベースに登録されたデータ に対して、Web API を通じた検索機能を提 供すること。
なお、地理情報データベースの実装が Triple Store を想定していることから、同 データベースの標準的なクエリ言語である SPARQL1.1 Query Languageを用いた検 索に対応すること。また、 Web API のプ ロトコルについては SPARQL1.1 Protocol を使用すること。
また、性能・利便性の面から必要が認めら れる場合には、上記に該当しない簡易的な
Web API の提供を行ってもよい。
SPARQL Endpoint の基本 機能によって充足
（特に独自の Web API の 設計・実装は行わなかった）
地理情報データベースに関して、本事業での使用用途を鑑みると、基本的には単独自治体、今後 想定される場合でも隣接自治体間程度で検索対象となるデータが閉じており、また多重処理に伴う 性能低下等も特に考慮をする必要が薄いことから、検索対象となるデータ数やレスポンス等の性能 要件はさほど高くないことが想定される。
SPARQL Endpoint については規模やライセンス（OSS、商用）に応じて様々な選択肢が存在す
るが、商用・ハイエンドのSPARQL Endpointの実装は用いず、国内での実証実験等で実績が多い OSSのApache Jena Fuseki1 を用いることとした。
SPARQL Endpointが稼働する環境については、クラウドプラットフォームである Microsoft
Azure の仮想マシンを用いることした。
1 Apache Jena Fuseki http://jena.apache.org/ 2014年6月時点で version 1.0.2 が公開され ている。ライセンスは Apache Software License 2.0 である。
実行環境 Microsoft Azure Virtual Machines (仮想マシン) Small VM (1.6GHz CPU, 1.75GB RAM)
OS Cent OS 6.5
データベースサーバ Apache Jena Fuseki
その他 Java 7 以降の最新版 （DB サーバの依存ライブラリ）
なお、地理情報データベースについては、対応業務の拡大や広域行政データの一括管理など、将 来的な負荷や規模の増大要因が存在する。これらの課題への解決としてはスケールアップが可能な アーキテクチャの選択が重要である。クラウドプラットフォームを選択することで、システムの垂 直拡張・水平拡張を容易にしている。また、商用・ハイエンドの SPARQL Endpoint 採用による 性能の向上にも対応できる設計となっている。
データベース設計
仕様書別紙では地理情報データベースに格納する情報として「行政区域情報」「道路情報」の二 種を挙げている。本節では地理情報データベース内でこれらのデータを保持するための RDF ボキ ャブラリに関して、選択・定義を行う。
（行政区域の識別子）
行政区域の識別子の情報（※形状データを含まないことに注意）のモデリングについては、W3C によって標準化が行われている SKOS Simple Knowledge Organization System2 を用いてエンコ ーディングを行う方針とした。
2 http://www.w3.org/TR/skos-reference/
SKOS自体はシソーラス（類語辞書）をモデリングするための RDF 語彙であるが、単語とそれ に対応するコードを保持する仕組みを持つ、という特徴がある。国や言語、分類コードといったさ まざまなコード体系を SKOS で記述してデータセットとして公開する試みがなされている。
http://www.w3.org/2001/sw/wiki/SKOS/Datasets
（行政区域の形状データ／道路）
対象となる浦安市 GIS データを分析して試行的運用のために必要な RDF ボキャブラリを新た に設計した。浦安市GIS データは Shapefile 形式3で提供されており、独自のプロパティを保持 している。また、仕様書別紙の加工方針および試行的運用の実施に必要なプロパティを加工・保持 するために行政区域・道路それぞれにプレースホルダが必要となる。整理されたプロパティは下表 のとおりである。なお、このようなプロパティ群を保持するプレースホルダとして専用の RDF 語 彙を設計した。
表 2 道路情報のプロパティ
名称 解説 備考
道路種別 GIS データに含まれている道路種別 道路番号 GIS データに含まれている道路番号 ポリゴン GIS データに含まれている道路外周の形状
中心線 道路の中心線情報 浦安市GISでは中心線を保 持せず、外周形状を使用して いるため未使用
交差エリア この道路と交差する行政区域 作業によって付与 内包エリア この道路を内包する行政区域 作業によって付与 FID GISデータにおける内部ID
表 3 行政区域（形状データ）のプロパティ
名称 解説 備考
区域名称 GIS データに含まれている区域の名称 町字コード GIS データに含まれている町字コード
郵便番号 郵便番号コード 作業によって付与
ポリゴン GISデータに含まれている区域の形状
交差エリア この区域と交差する行政区域 作業によって付与 内包エリア この区域を内包する行政区域 作業によって付与
3 Shapefile (シェープファイル) は Esri 社の提唱するベクトル形式の地理情報フォーマットで
あり、位置情報と属性情報を保持することができる。
FID GISデータにおける内部ID
整備データ
データの整備にあたって、道路と行政区域との空間的な関係に関しては、地理情報データベース へのアクセス時に都度計算を行う手法も考えられるが、本事業においては、道路の新設、形状変 更、また行政区域の領域の変更など、行政区画の形状、道路情報の形状の更新のタイミングでのみ 道路と行政区域との関係が変わる静的な関係のため、道路と行政区域、行政区域間の関係をデータ 変換時に空間検索、座標変換等を行って前もって埋め込んだ状態でRDFに格納することとした。
以下に整備データの元となった各々のデータとライセンスを示す。
表 4 元データとライセンス
名称 出典 ライセンス
国コード Geonames のデータを加工して作成 (日本のみ抜粋)
http://www.geonames.org/countries /
Creative Commonsの「表示」
( CC_BY 3.0 )
都道府県コード 市区町村コード 郵便番号
郵便番号データの中に含まれるコード 類から取得(千葉・浦安市のみ抜粋) http://www.post.japanpost.jp/zipcod e/download.html
「日本郵政株式会社は著作権を主 張をしない」
http://www.post.japanpost.jp/zi pcode/dl/readme.html
行政区域の形状 道路情報
浦安市共用空間データ（GISデータ）
より「町目-形状」及び「道路-道路種 別-国県市道」を加工して作成
Creative Commonsの「表示」
( CC_BY 3.0 )
次に、RDFに変換した地理情報DBに格納されているデータの一部を以下に示す。
@prefix area: <http://icroad.net/icroad/area/> .
@prefix road: <http://icroad.net/icroad/road/> .
@prefix icroad: <http://icroad.net/vcb#> .
@prefix : <http://example.org/> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix dct: <http://purl.org/dc/terms/> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
@prefix skos: <http://www.w3.org/2004/02/skos/core#> .
#道路情報
road:市道_3-23_4 a icroad:Road ; icroad:bango "3-23" ;
icroad:fid "道路－道路種別－国県市道.778" ;
icroad:isContainedBy <http://icroad.net/icroad/area/machiAza/02502> ,
<http://icroad.net/icroad/area/postalcode/2790043> ;
icroad:polygon "35.65100905368017 139.89078392812476 35.65096427699557 139.89075782229858 (略) 35.65100905368017
139.89078392812476" ;
icroad:shubetsu <http://icroad.net/res/市道> .
#行政区域
<http://icroad.net/icroad/area/machiAza/02603>
a icroad:Area ; icroad:fid "町字－形状.7" ;
icroad:isIntersectedBy <http://icroad.net/icroad/area/postalcode/2790043> ,
<http://icroad.net/icroad/area/machiAza/02602> ,
<http://icroad.net/icroad/area/machiAza/03001> ,
<http://icroad.net/icroad/area/postalcode/2790042> ,
<http://icroad.net/icroad/area/postalcode/2790026> ,
<http://icroad.net/icroad/area/postalcode/2790021> ; icroad:machiAza "02603" ;
icroad:meisho "東野三丁目" ;
icroad:polygon "35.64223027836158 139.89265038382902 (略) " .
なお、当該の整備データについては、以下の留意事項が存在する。
道路に関して：浦安市GISデータでは名称で管理され、ID化はされておらず、単一の道路 が複数の区間ごとに別のデータとして存在している箇所があり、道路に関しては名称で名寄 せする必要がある。
位置情報について：元データ上は日本測地の平面直角座標系(9系)にて表現されているが、
外部サービスとの連携等を考慮し、世界測地の緯度経度系に変換してRDFに格納した。た だし、道路、行政区域との関連性については変換時の誤差を考慮し、変換前の座標を用いて 解決したが、浦安市GISデータでは、本来は接しているべき行政区域のポリゴンと道路ポリ ゴンにデータ上微細な隙間が存在する場合があり、この場合、幾何計算では両者の関係性が ないと判断される場合がある。そのため、道路と行政区域、行政区域同士の関係性において は、行政区域のポリゴンを20mほど膨らませたデータを用いて関係性を導き出している。
浦安市GISデータでは首都高速道路は国道としての取り扱いになり、道路番号に「首都高速 湾岸線」と格納されている。
４．詳細設計：入力支援機能及び集計/可視化機能
入力支援機能
4.1.1 入力支援機能の機能要件と対応方針
入力支援機能は利用者が Web ブラウザを通じて共通語彙適用データの作成を行うための支援機 能である。本機能の実装に当たっては、語彙の整合性を維持するためにパイロットシステムとの連 携が前提となる。そこで以下では、パイロットシステムとの連携仕様を含めた入力支援機能の機能 要件と対応方針について示す。
表 5 入力支援機能に求められる機能要件と対応方針
機能区分 機能要件 対応方針
テンプレート登録 入力すべきデータ構造を定義したテン プレートを登録する機能を有するこ と。登録されたテンプレートがIMIコ アボキャブラリおよび登録済みのドメ イン語彙に準拠していることを保証す るために、妥当性の検証を行うこと。
この目的でパイロットシステムの提供 する「語彙データ一括取得」 機能を用 いること。
オーサリング作業として実 施。
「語彙データ一括取得」機能 によって得られたXMLスキ ーマをもとに XML エディタ で「サンプルインスタンス」4 を生成した
入力フォーム生成 登録されたテンプレートを変換して、
入力フォームを生成する機能を有する こと。
XSLT スタイルシートを用い
たバッチ処理として整備。
サンプルインスタンスを変換 することで、HTMLフォーム を生成する。
入力支援・データ 生成
利用者が Web UI を通じてデータを 入力し、IMIコアボキャブラリおよび
Web アプリケーションとして 実装。
4 NIEM IEPD における Smample XML instance に相当するものである。実際にはスキーマと サンプルインスタンス、スタイルシートとメタデータをパッケージにしたものがテンプレートと呼 ばれることになる。
登録済みのドメイン語彙に準拠したデ ータを出力するための機能を有するこ と。
このとき、地理情報データベースの提 供する Web API を使用することで、
適切な入力支援・データ補完・データ 完全性の担保を行うこと。
生成された入力フォーム／可 視化機能と、それらを補助す る Javascript 等で構成され る
なお、各ワークアイテムとそれに基づく出力、連携は図 3のとおりである。
図 3 各サブ機能の連携とワークフロー
なお、語彙の定義およびサンプルインスタンスの背景となる業務分析に関しては、概念モデル書 に取りまとめた。サンプルインスタンス、および、入力フォームの生成スクリプトはソースコード の一部として収録している。
次に4.1.2では、Web アプリケーションとして動作する入力支援機能に関する画面遷移及び画
面詳細設計を説明する。
ドメイン語彙 の定義
• 道路型ほかの 語彙を定義
サンプルイン スタンスの作
成
• 道路占用のた めのインスタ ンスをエディ タで生成
入力フォーム
の生成 • 変換スクリプト整備
Webへの配 備
• 関連スクリ プト整備
4.1.2 入力支援機能の画面遷移及び画面詳細仕様
入力支援機能は利用者がスキーマに準拠した XML ファイルを生成するための入力作業を支援す るツールである。
アプリケーションのプラットフォームとしては、利用者の負担低減を重視して、専用のアプリケ ーションをインストールしたり、特定ソフトウェアのプラグインとして動作するものではなく、一 般的な Web ブラウザで動作する HTML フォームの形態を採用した。
また、入力支援機能は運用者や将来的な開発者の負担軽減を重視して、Webブラウザ単体で殆ど の処理を行う実装とした5。利用者の入力したデータは、最終的にXMLファイルとして利用者の 端末にダウンロードされ、サーバでのファイル蓄積やワークフローエンジンへの接続は行わないも のとしている。サーバでの処理は最低限であるために、他のプラットフォームへの移植も容易であ る。また、サーバのファイルリソース／計算リソースを使用しないために、サーバの運用も容易で ある。
（画面遷移とファイル構成）
入力支援機能は基本的には画面遷移を伴わないHTML フォームとして作成される。ただし、作成 したXMLファイルのローカル保存／単独表示を補助する目的で、サーバスクリプトへの遷移が発生 する（画面遷移については図 4、構成ファイルと参照関係については図 5及び表 5参照）。
5 HTML5 の機能を使用することで、従来サーバで実装されてきた機能の多くをクライアントで
実装することが可能になってきている。現時点では、唯一、生成したファイルをローカルに保存さ せる目的でサーバスクリプトを使用しているが、これも HTML5 File API の普及や拡張に伴って 代替されることが期待できる。
図 4 入力支援機能の画面遷移
図 5 入力支援機能の構成ファイルと参照関係
index.html
index.js index.css assist.html
assist.js assist.css
road.svg
road.js config.js config.js
view.php
save.php
表 6 入力支援機能の構成ファイルの詳細
ファイル名 機能 備考
index.html HTMLフォーム 変換スクリプトによって生成
index.css 同スタイルシート
index.js 同スクリプト フォームの補完、地理情報DB接続、
XML生成等を担当 assist.html 道路入力支援GUI（外枠）
assist.css 同スタイルシート
assist.js 同スクリプト
road.svg 道路入力支援GUI（本体） SVG ファイル
road.js 同スクリプト 地理情報DB接続、道路画像生成、HTML
フォームへの補完を担当
config.js 共通設定 地理情報DBへの接続情報を一元的に保持
save.php XML保存用サーバスクリプト
view.php XML表示用サーバスクリプト
（画面詳細）
入力支援機能の画面構成は実際には１画面だが、画面状態の遷移を示すため、以下 図 6～図 8 の3つのステップに分割して記述する。
なお、XMLファイルの保存用サーバスクリプト（図 4 : save.php ）は、Webブラウザのファ イル保存ダイアログを開かせるものであり、画面設計は不要となる。また、XML表示用サーバス クリプト（図 4 : view.php ）は、Web ブラウザの XMl 表示機能を使用して XML を表示させ るものであり、こちらも画面設計は不要となる。
図 6 入力支援機能（1/3）
フォーム生成の時点で、管轄として「浦安市」が設定されている。
地理情報データベースを参照して、自治体名称・自治体コードが自動補完される
地理情報データベースを参照して、「管轄」配下の郵便番号リストが取得・表示される
選択した郵便番号に対して、地理情報データベースからさらに詳細な町字・町丁目のデータ が得られる場合には選択肢を取得・提示する
選択肢に応じて構造化住所の内容が自動的に補完される
図 7 入力支援機能（2/3）
「道路選択アシスト」ボタンを押すことで、住所の選択状況に応じた道路選択用GUIが表示さ れる
GUI の道路をクリックすると赤く表示され、また、道路型の各フォームに対して道路情報が自 動補完される
GUI ではマウスオーバーすることで道路名がツールチップ表示される
国道・県道・高速道路など、浦安市の管轄でないものは選択禁止となるように制御されている
図 8 入力支援機能（3/3）
「IMIドキュメントを出力する」ボタンを押すことで、下部のテキストエリアに XML ドキ ュメントが出力される
「保存する」ボタンを押すことで、ローカルファイルとして保存することができる（XML ファイルがサーバに送信＆リダイレクトされる）
「別ウィンドウで開く」ボタンを押すことで、別ウィンドウで開くことができる（XML フ ァイルがサーバに送信＆リダイレクトされる）
集計/可視化機能
集計/可視化機能は作成されたXMLファイル群を集計・可視化して表示する機能モジュールであ る。入力支援機能と同様、Web ブラウザ上で動作すること、ならびに可能な限りクライアントの Webブラウザのみで処理が実施できるような設計とした6。
なお、可視化機能は試行的運用の評価目的に応じて2種類のバリエーションを用意した。
表 7 集計/可視化機能のバリエーション
ビュー 説明
時系列優先ビュー 投入したファイル群を解析して、該当する町丁目一覧／タイムスライダ ーを表示するビュー。タイムスライダーを操作して、市全体の工事が時 系列でどのように計画されているかを確認することを重視している エリア優先ビュー 投入したファイル群を解析、さらに地理情報データベースの近接・包含
情報を使用することで、「注目しているエリアとその周辺」の工事をフ ィルタリング表示するビュー。局所的な工事の依存関係を確認すること を重視している。
集計/可視化機能はファイルの保存や単独表示といった機能が不要であるため、他のファイルへ の遷移が発生しない。そのため、画面遷移図相当のものは存在しない。以下では、２つのビューそ れぞれについて、構成ファイルおよび画面詳細について解説する。
6 集計ツールでは、ファイルに対する「読み込み」のアクセスのみが必要となる。HTML5 の
File API は「書き込み」アクセスについてはサポート状況に差があるが、「読み込み」については
各ブラウザでのサポートが進んできている。集計ツールでは、大量のファイルを効率的に選択・処 理することを容易にするために、HTML5の Drag & Drop API と File API を併用したファイル 群のドロップ操作による処理を採用した。
4.2.1 時系列優先ビュー
時系列優先ビューのファイル構成・参照関係は 図 9及び 表 7のとおりである。
図 9 集計/可視化機能（時系列優先ビュー）の構成ファイルと参照関係
表 8 集計/可視化機能（時系列優先ビュー）の構成ファイルの詳細
ファイル名 機能 備考
index.html 集計ツール本体 タイムスライダー、道路地図を配置
index.css 同スタイルシート
index.js 同スクリプト ファイルのドラッグ＆ドロップをトリガーに、
ファイル解析～ビューへの反映を実施。
map.svg 道路地図
map.js 同スクリプト 地理情報DBに接続して、浦安市地図を表示。
本体のタイムスライダーの選択に応じて、道路 の着色・Tooltip 変更を行う
svg.js SVG ユーティリティ関数群 SPARQL API への接続、Bounding Box 計
算、ユーティリティ関数の提供
config.js 共通設定 地理情報DBへの接続情報を一元的に保持
また、時系列優先ビューの画面構成については、初期状態とファイル投入状態の二つの状態があ るため、それぞれについて図 10と図 11で図解する。
index.html
index.js index.css
map.svg
map.js
svg.js
config.js
図 10 集計/可視化機能・時系列優先ビューの画面構成 (1/2, 初期状態）
左ペインではドラッグ＆ドロップが指示されており、入力支援機能で作成・保存したXML ファイル群をドラッグ＆ドロップすることで解析が開始する
画面右上にはタイムスライダーが表示されている。初期のレンジは1889年1月1日（浦安 村の成立）から2020年12月31日に設定されている。
画面右下には道路地図が表示されている。道路・区域にマウスオーバーすることで、それぞ れの道路番号・区域名称を確認することができる。
タイムスライダーによって選択された時点において、ある区域が存在しない場合には、当該 区域が半透明表示となる。
図 11 集計/可視化機能・時系列優先ビューの画面構成（2/2, ファイル投入状態）
ファイル群をドラッグ＆ドロップすることで、ログ／エリア一覧／ファイル一覧が更新され る。また、タイムスライダーの背景にヒートマップが表示される
タイムスライダーの範囲は工事期間の最小値・最大値によって更新される
マップ上の道路には、タイムスライダーの選択日付における、工事計画状況が表示される
ファイル一覧の列見出しをクリックすることで、降順・昇順ソートされる
ファイル一覧の開始・終了列の日付をクリックすることで、タイムスライダーが当該日付に 設定される
4.2.2 エリア優先ビュー
エリア優先ビューのファイル構成・参照関係は 図 12及び 表 8 のとおりである。
図 12 集計/可視化機能（エリア優先ビュー）の構成ファイルと参照関係
表 9 集計/可視化機能（エリア優先ビュー）の構成ファイルの詳細
ファイル名 機能 備考
index.html 集計ツール本体 タイムスライダー、道路地図を配置
index.css 同スタイルシート
index.js 同スクリプト ファイルのドラッグ＆ドロップをトリガーに、ファ
イル解析～ビューへの反映を実施。地理情報DBに 接続して、近接関係を反映したエリア表示を行う
map.svg 道路地図
map.js 同スクリプト 地理情報DBに接続して、浦安市地図を表示。本体
のタイムスライダーの選択に応じて、道路の着色・
Tooltip 変更を行う
svg.js SVG ユーティリティ
関数群
SPARQL API への接続、Bounding Box 計算、ユ ーティリティ関数の提供
index.html
index.js
index.css wait.gif
map.svg
bg.png map.js
svg.js
config.js
config.js
wait.gif アニメーションGIF ファイル処理中の待機状態を提示
bg.png 道路地図の背景画像 時系列優先ビューとの差別化のため
config.js 共通設定 地理情報DBへの接続情報を一元的に保持
また、エリア優先ビューの画面構成は、初期状態、ファイル投入状態（通常）、ファイル投入状 態（近接選択モード）の三つの状態があるため、それぞれについて図 13～図 15にて図解する。
図 13 集計/可視化機能・エリア優先ビューの画面構成（1/3, 初期状態）
ファイル群のドラッグ＆ドロップなど、基本的な操作は時系列優先ビューと同様である
区別のために、マップ部分のスタイルがグレー系に変更されている
図 14 集計/可視化機能・エリア優先ビューの画面構成（2/3, ファイル投入状態）
時系列優先ビューと異なり「エリア」部分のGUI構成が異なっている
エリアの町丁目ボタン（オレンジ・灰）をクリックすることで、当該エリアを選択／選択解 除することができる。選択したエリアはマップ上でオレンジに強調表示される
青いボタン（図中では今川、富岡など）をクリックすることで、当該地区の配下にあるエリ アが一括して選択／選択解除される
「近接選択モード」チェックボックスを有効にすることで、近接選択モードに移行する
図 15 集計/可視化機能・エリア優先ビューの画面構成（3/3, 近接選択モード）
近接選択モードを有効にすると、エリア選択対象が単一のエリアに限定される
任意のエリアボタンをクリックすると、当該エリアがオレンジに、当該エリアに隣接するエ リアがイエローになる。マップ上の表示もそれに対応して強調表示される
「近接選択モード」チェックボックスを無効にすることで、通常のエリア選択モードに状態 遷移する
以上
