HTMLレポートページの作成 - 東京都知事選挙投票結果

FMEの文字列処理用のトランスフォーマーは充実しており、「e-Stat 統計表情報ウェブページの自動作成 (FME Server)」でも紹介したように、従来から、工夫次第でHTML文書を作成することが可能でしたが、FME 2016.1 ではHTMLに関していくつかの機能が追加され、図表を中心とする定型のHTMLレポートページが簡単に作成できるようになりました。

次の Safe Software ブログ記事も参照してください。
FME 2016.1 New Functionality: HTML and HTML Transformers

ここでは、2016年7月31日に投開票が行われた東京都知事選挙の投票結果について、開票区別の投票率を示す棒グラフと開票区別の投票結果一覧表を含むHTMLレポートページを作成するワークスペース例を掲げます。

【ソースデータ】
東京都選挙管理委員会事務局ウェブサイトにおいて公開されている東京都知事選挙投票結果Excelファイル
東京都選挙管理委員会事務局 > 都知事選挙（平成28年7月31日執行）投開票結果
投票結果: h28tochiji_touhyo.xls [Sheet1]

【変換内容】
開票区別の投票率（男女平均）を示す棒グラフ、および、開票区別の有権者数（男、女、計）、投票者数（男、女、計）、投票率（男、女、平均）の一覧表をウェブブラウザで閲覧できるHTML文書に変換する。

FME 2016.1.1.0 build 16609

FME ワークスペース例

[XLSXR] (Excel) リーダー: Excelスプレッドシートから投票結果を読み込む。
AttributeRenamer: 属性名（列名）を分かり易い名称に変更する。
AttributeTrimmer: 開票区名の先頭にある余分な全角空白を削除する。
Tester: 集計行（開票区名が「***計」、「***支庁」であるもの）を除く。
StringFormatter x 2: 投票者数、投票率の数値書式調整
HTMLReportGenerator: HTML図表作成
HTMLlayouter: HTMLページのレイアウト調整
[HTML] ライター: HTMLファイル出力

Excelリーダーをワークスペースに追加する際のパラメーター設定によって、列名が記述されている行番号を指定し、それらを属性名とすることができますが、その行に同一の列名があった場合、2番目以降の列名には連番 (00, 01, 02...) が自動的に付加されます。この例では、6行目を列名としたので、2番目以降の「男」は、「男00」、「男01」、「男02」となります。ただし、3番目の「男01」（棄権者数）は使用しないので、フィーチャータイププロパティ設定画面の User Attributes (ユーザー属性) タブで非表示に設定したため、上の図には現れていません。「女」等についても同様です。

Excelに数値として記録されている値には整数と小数点数の区別はなく、Excel画面上に表示される小数点以下の桁数は、セルの書式として設定されています。FME はセルの書式のいかんに関わらず、Excelの数値データを全て小数点数として読み込むので、HTML文書を作成する前に StringFormatter によって数値の書式を整えました（有権者数、投票者数は小数部なしの整数、投票率は小数点以下2桁の小数点数）。

以上の前処理の後、FME 2016.1 で導入された HTMLReportGenerator, HTMLLayouter, [HTML] ライターによって、次のようなHTML文書=ウェブページに変換しました（実際のページはこちら > HTMLReportGenerator DEMO）。

HTMLReportGenerator では、入力データを次の要素を含むHTML文書に変換することができます。

Chart (Bar, Line, Pie)	チャート (棒グラフ, 折れ線グラフ, 円グラフ)
Header	ヘッダー（H*要素文字列)
List	リスト
Image	画像
Map	マップ (注)
Separator	セパレーター (hr要素)
Table	表
Custom HTML (FME 2017.0 以降)	任意のHTML要素を含むHTML文書のパーツ

注: マップ要素は、Esri Leaflet, Google, または Mapbox Leaflet のAPIを利用して地物を表示するためのスクリプトをHTML文書に組み込むものです。利用にあたっては各APIの利用規約等にしたがってください。

HTML文書に組み込む要素の種類、数、順序は任意です。この例では、ヘッダーx3, セパレーター, チャート (棒グラフ), ヘッダー, 表の順で使用しました。

HTMLReportGenerator パラメーター設定画面

HTMLLayouter では、HTMLReportGenerator によって作成したひとつ以上のHTML文書を1ページのHTML文書に統合し、それらのレイアウトを整えることができます。この例では HTMLReportGenerator でひとつの文書しか作成していませんが、 Layout Type パラメーターを Vertical (垂直) とすることにより、左右のマージンなどが整えられます。

HTMLLayouter パラメーター設定画面

[HTML] ライターは、HTMLReportGenerator, HTMLLayouter で作成されたHTML文書（html_content属性に格納された文字列）をそのままファイルに出力します。

[HTML] ライターの代わりに FeatureWriter トランスフォーマーによってファイル出力すれば、引き続き FTPCaller トランスフォーマー等によってウェブサーバーにアップロードするところまでをひとつのワークスペースで自動化することもできます。

HTMLReportGenerator, HTMLLayouter は、特に、静的ではあるが、しばしばデータの更新があるようなウェブページついて、データ更新に伴うHTML文書の更新を正確かつ迅速に行うために活用できそうです。

なお、現時点 (FME 2016.1.1) の HTMLReportGenerator はまだ機能が限られており、思い通りのウェブページを作成するのが難しいケースもあります。例えば:

• 表の各欄の右揃え、センタリング等の設定をサポートしておらず、全て左揃えになる。
• 図の凡例文字列中のスペースや非ASCII文字の前で改行され、縦書きのように表示される。
• 入力文字列中の <, > 等の特殊文字が自動的に実体参照に置き換えられるため、任意のHTML要素（例えば他のページへのリンクなど）を埋め込むことができない (FME 2017.0 では "Custom HTML" によって、任意のHTML要素を含むHTML文書のパーツを組み込むことができるようになりました)。

これらについてはすでに多数のユーザーから改良、機能強化の要望があがっているので、今後のアップグレードで改良されていくことと思われます。

GISポリゴンデータに基づく面積計算 (_AZMEA_の利用)

GISポリゴンデータに基づいて地物の面積を求めることはよくあると思います。GISソフトウェア等の機能として面積計算はありふれたものですが、データの精度は元の地図の縮尺やデジタイズの方法等によって異なるとともに、同じデータであっても投影先の座標系によって地物の形状は異なるため、使用するデータや投影方法によって、同一の地物について求められる面積が異なることもあるということは認識しておく必要があるでしょう。

既存のGISデータから求めた面積を研究論文・報文や調査業務報告書などで用いるのならば、データの出典を明記するのはもちろんのこと、元のデータの座標系が緯度経度である場合には、どの座標系に投影した形状の面積なのかも説明するべきであると考えます。

緯度経度の座標系で作成された日本国内のGISデータに基づいて地物の面積を求める場合、平面直角座標系またはUTM座標系に変換することが多いかも知れません。

しかし、平面直角座標系の複数の系、UTM座標系の複数のゾーンにまたがった広い範囲に分布する地物の面積を求める場合には、個々の地物が所在する位置に応じて変換先座標系の系番号、ゾーン番号を選択するといったプロセスが必要になります。そのようなプロセスを含むワークスペースを作成することもできますが、合理的な説明ができれば面積計算にあたっての投影法は任意で良いという場合には、_AZMEA_ (Dynamic Reprojection Equal Area) という名前の座標系を利用するのが便利です。

_AZMEA_ は、任意の座標を基準点とする「ランベルト正積方位図法」 (Lambert azimuthal equal-area projection) によって定義される座標系 (単位: メートル) であり、座標系変換を行う Reprojector または CsmapReprojector トランスフォーマーで変換先の座標系として _AZMEA_ を指定すると、ワークスペースの実行時に、個々の地物について元の座標系におけるバウンディングボックス中心を基準点とするランベルト正積方位図法の座標系が定義され、それに変換されます。これにより、系番号やゾーン番号を考慮しなくても、広い範囲に分布する地物の面積を統一的な手法で求めることができます。

ここでは、国土数値情報「行政区域」データに基づいて、_AZMEA_ を利用して全国の市区町村の面積を求めるワークスペース例を掲げます。

【ソースデータ】
国土数値情報ダウンロードサービスサイトからダウンロードした「行政区域」データ（平成28年1月1日時点, 全国, Esri Shapefile 形式ポリゴンデータ）

FME 2016.1.1.0 build 16609

FMEワークスペース例 1

[ESRISHAPE] リーダー: 国土数値情報行政区域（全国）データを読み込む。
Tester: 市区町村コード（N03_007属性値）を持っているフィーチャーとそうでないものに分岐する。
Aggregator: 同じ市区町村コードを持っているフィーチャーを集約する。
Reprojector: フィーチャーごとに _AZMEA_ に座標系を変換する。
AreaCalculator: フィーチャーごとに面積を計算する。
Inspector: 変換結果を FME Data Inspector で確認する。

国土数値情報の行政区域データ（ポリゴン）は、飛び地や離島などがある市区町村について、それらが個別のレコードとなっている、いわゆるシングルパートポリゴンです。また、埋立地などでどの市区町村に属するか決定していない「所属未定地」のレコードには、市区町村コードが記録されていません。

そのため、このワークスペース例ではまず、Tester によって市区町村コードを持っているフィーチャーと持っていないフィーチャー（所属未定地）に分け、市区町村コードを持っているフィーチャーについて Aggregator によって市区町村ごとに集約しました。これによって、飛び地や離島がある市区町村についても、市区町村単位で全域の面積を求めることができます。

Reprojector の Destination Coordinate System （変換先の座標系）パラメーターに _AZMEA_ を設定することにより、前述のとおり、フィーチャー（市区町村または所属未定地）ごとに、それぞれバウンディングボックス中心を基準点とする「ランベルト正積方位図法」による座標系に変換されます。

Reprojector パラメーター設定画面

AreaCalculator は、入力フィーチャーの面積を計算し、その値を格納する新たな属性を付加します。ここで、Multiplier パラメーターによって、求められた値に乗じる値を指定することができます。_AZMEA_ によって変換された座標値の単位はメートルなので、Multiplier パラメーターに 1e-6 (= 0.000001) を設定すれば、平方キロメートル単位の値に換算されます。


このワークスペースを実行して Data Inspector に変換後のポリゴンを表示させると分かりますが、_AZMEA_ は、個々のフィーチャーのバウンディングボックス中心を基準点、つまり原点 (0, 0) とする座標系なので、変換後のポリゴンは原点周辺で重なり合うことになります。地図としては用を成しません。

面積を求めることだけが目的ならばこのままでも構いません。しかし、元の座標系（この場合は JGD2011 緯度経度）におけるジオメトリとしての処理も必要な場合には、元の座標系における位置、形状を復元する必要があります。

もうひとつ Reprojector を追加して元の座標系に再変換するのは簡単ですが、座標系変換にはどうしても計算誤差が伴い、完全に復元できるとは限りません。正確に元に戻すには、あらかじめ元の座標系名とジオメトリを属性データとして抽出しておき、面積を求めた後で、それらの属性データに基づいて元のジオメトリと座標系の定義を復元するという方法があります。

上記ワークスペースにそれらの手順を追加すると、次のようになります。

FME ワークスペース例 2

(座標系変換前）
CoordinateSystemExtractor: フィーチャーに設定されている座標系名を属性 (_coordsys) として抽出する。
GeometryExtractor: ジオメトリ（形状のデータ）を属性 (_geometry) として抽出する。

（面積計算後）
GeometryReplecer: 属性 (_geometry) に基づいてジオメトリを復元する。
CoordinateSystemSetter: 属性 (_coordsys) に基づいて元の座標系の定義を復元する。

GeometryExtractor/Replacer では、Geometry Encoding パラメーターでいくつかの属性値（文字列）としてのジオメトリの表現方法が選択できますが、そのうち FME Binary は、ジオメトリの抽出/復元に伴う誤差は全くなく、かつ、最も効率が良いので、この例のようにジオメトリを復元することを目的とする場合には最も適しています。

GeometryReplacer は、フィーチャーのジオメトリ（形状のデータ）だけを置き換えるものであり、座標系の定義は復元しないことに注意してください。そのため、このワークスペース例では、CoordinateSystemExtractor によって元の座標系名をあらかじめ抽出しておき、CoordinateSystemSetter によってその座標系の定義を復元しています。

なお、GeometryExtractor/Replacer は、FME Binary のほか、GeoJSON, GML, OGC Well Known Binary, OGC Well Known Text などのメジャーなジオメトリの文字列表現をサポートしており、用途に応じて使い分けることができます。

MapnikRasterizer による画像作成 - 基盤地図情報等高線と標高点

複数のベクター、ラスターレイヤを重ね合わせ、ひとつの地図として視覚的に表現することは、GISが得意とするところです。FMEはGISではありませんが、MapnikRasterizer トランスフォーマーによって、GISにも匹敵する高度な地図画像（ラスター）を作成することも可能です。

名前からも分かるように、このトランスフォーマーは Mapnik というオープンソースの地図レンダリング用ツールキットを内部で使用することにより、非常に多彩な表現をサポートしています。

ここでは、基盤地図情報基本項目「等高線」および「標高点」のレンダリングを例として、MapnikRasterizer の基本的な使い方を示すワークスペース例を掲げます。

【ソースデータ】
三宅島周辺の二次メッシュ4区画（513903, 513904, 513913, 513914）について、基盤地図情報ダウンロードサービスサイトからダウンロードした基盤地図情報基本項目の等高線および標高点データ（GML形式）

【変換内容】
等高線をライン、標高点の位置をマーカー、標高点の標高値をテキストとしてレンダリングする。
等高線は「100m間隔」、「50m間隔」、「その他」に分類し、それぞれ異なる色で表現する。
変換結果は、三次メッシュ区画単位でPNG形式のファイルに出力する。

FME 2016.1.1.0 build 16609

FME ワークスペース例

[GML] リーダー: 基盤地図情報等高線、標高点データ（GML形式）を読み込む。
JpStdGridAccumulator: 入力フィーチャーをカバーする範囲の三次メッシュ区画ポリゴンを作成する。
BoundsExtractor: 各メッシュ区画の東西端、南北端の座標を抽出する。
Clipper: メッシュ区画ポリゴンで等高線、標高点をクリップする。
GeometryFilter: ラインフィーチャー（等高線）とポイントフィーチャー（標高点）に振り分ける。
TestFilter: 等高線を「100m間隔」、「50m間隔」、「その他」の3区分に振り分ける。
MapnikRasterizer: メッシュ区画ごとに等高線（ライン）、標高点（マーカー、テキスト）をレンダリングする。
[PNGRASTER] ライター: メッシュ区画ごとにラスターをPNG形式のファイルに出力する。

基盤地図情報基本項目データはGML形式で提供されており、FMEは基盤地図情報応用スキーマをバンドルしているので、標準のGMLリーダーで直接読み込むことができます。

JpStdGridAccumulator は FME Hub で公開しているカスタムトランスフォーマーで、パラメーターの設定に応じて、入力フィーチャーをカバーする範囲の一次～1/10細分メッシュ区画ポリゴンまたはポイントを作成するとともに、それらにメッシュコードを属性として付加します。この例では、三次メッシュ区画ポリゴンを作成しました。

BoundsExtractor は、各フィーチャーのバウンディングボックス境界の座標を抽出します。この例では各三次メッシュ区画の境界の座標が得られ、それらによって後述の MapnikRasterizer で画像の作成範囲を指定しています。

Clipper によって、等高線と標高点をメッシュ区画ポリゴンでクリップしました。このとき、Clipper のパラメーター設定画面で Merge Attributes（属性を結合する）オプションをオンにすることにより、メッシュコードやバウンディングボックス境界座標を格納したメッシュ区画ポリゴンの属性が、区画ごとにその内部となる全ての等高線、標高点に結合されます。

GeometryFilter でフィーチャーの流れをライン（等高線）とポイント（標高点）に分岐した後、等高線についてはさらに、TestFilter によって、各フィーチャーが持っている標高値（alti属性の値）に応じて「100m間隔」、「50m間隔」、「その他」の3区分に振り分けました。

MapnikRasterizer には、必要に応じて任意の数の入力ポートを追加することができ、ポートごとに、そこから入力されるフィーチャーに対するひとつ以上のレンダリングルール（視覚的な表現方法）を設定することができます。

レンダリングルールの設定内容は多岐にわたります。主なものだけ挙げると、ラインについては線幅、色、ダッシュスタイル（実線部の長さ、間隔の任意の繰り返しパターン）など、マーカーについてはサイズ、色、あるいは外部画像ファイルなど、テキストについてはフォント、サイズ、色、ポイントに対する相対的な位置などです。

MapnikRasterizer パラメーター設定画面

ソースデータ（二次メッシュ4区画）のうち、等高線、標高点が存在する三次メッシュ区画数は70でした。そのうち、雄山（おやま）火口周辺の次の9区画（下記）の画像をモザイク（結合）した結果を示します。
5139-14-11, 5139-14-12
5139-14-01, 5139-14-02
5139-04-91, 5139-04-92
この画像の解像度は、上記 MapnikRasterizer での設定と同じ（三次メッシュ1区画あたり1200 x 800ピクセル）です。ただし、ファイルサイズを小さくするため、パレット（エントリー数=16）つきの1バンドラスターに変換しました。ピクセル等倍でご覧になるには、ダウンロードして適当なビューアーで開いてください。

一見、うまくいっているようですが、上記ワークスペース例には、メッシュ区画境界付近で標高点テキストが描画されないことがあるという欠陥があります。上の図では、画像下部、三次メッシュ区画 5139-04-91 と 5139-04-92 の境界付近の 5139-04-91 側、つまり、西側の区画の東端付近にある標高点について、標高値テキストが描画されていません。これは、MapnikRasterizer では、指定した画像作成範囲をはみ出すようなテキストはレンダリングされないためです。

これは、ワークスペースに次のような改良を加えることによって解消することができます。
・MapnikRasterizerによる画像作成範囲を三次メッシュ区画ぴったりの範囲でなく、隣接区画の標高点テキスト描画範囲を含むのに十分な範囲まで拡大する。
・作成するラスターの解像度（縦横のピクセル数）をその範囲にあわせて修正する。
・MapnikRasterizerで作成された画像を、対応する三次メッシュ区画の範囲によってクリップする。

この改良を行うために追加したり置き換えたりするトランスフォーマーは、Scaler, SpatialRelator, ListExploder, JpMeshCodeReplacer (FME Hub) などです。

==========
2016-09-08 追記: クリップではなく、RasterSubsetter によって三次メッシュ区画に相当する範囲のラスターに変換する方法もあり、場合によってはその方が効率が良いかも知れません。
==========

改良後のワークスペースで作成した三次メッシュ区画 5139-04-91, 5139-04-92 の画像をモザイクした結果は次のとおりです。改良前には描画できなかった中央付近の標高値テキスト「723」も描画されました。

MapnikRasterizer は、複数のベクター、ラスターデータをまとめてひとつの地図画像を作成するのに非常に便利なトランスフォーマーですが、現時点では、非ASCII文字を含むテキストのレンダリングについて、MS UI Gothic (Normal) 以外のフォントがサポートされていないという制約があります。

その他のフォント（MS ゴシック、MS 明朝など）での日本語文字の描画が必要な場合、TextAdder 等によってテキストフィーチャーを作成し、さらに TextStroker によってフォントを指定してポリゴンに変換したうえでレンダリングするという代替策はありますが、サイズや位置の調整が少し面倒になるかも知れません。近い将来、MS UI Gothic 以外の非ASCII文字フォントのサポートも追加されることを期待しています。