データベースの利用について

2015-07-21発信

データセットの規模が大きい場合や部分的な更新が頻繁に必要な場合など、データベースによってデータを管理することが効果的なことがあります。
FMEではファイルベースのデータセットと同じ感覚でデータベースを取り扱うことができますが、FMEの使用方法とは別に、DBMS(データベース管理システム)によって少しずつ異なるところがあるデータベースの利用方法に関する基礎的な知識は必要になります。
初めてデータベースを扱おうとする場合には、その点で少し難しさを感じるかも知れません。

FMEがサポートするDBMSのうちPostgreSQL/PostGISは、誰でも無償で利用できるとともに、非空間データベース、空間データベースのどちらにも対応しているので、FMEによるデータベースの利用方法を学ぶうえで最適であると思います。
これからPostgreSQL/PostGISを利用しようとする方の導入時の参考としていただけるよう、次の文書を作成・公開しましたので、ご案内します。
・PostgreSQL/PostGIS のインストールとデータベースの作成
http://www.pragmatica.jp/fme/support/documentation/common/postgresinstallation.pdf
※この文書にアクセスするには、このメール本文の後に記載しているユーザー名、パスワードによる認証が必要です。

また、「FMEケーススタディ」にはPostGISデータベースを利用するFMEワークスペースの例も掲載しましたので、あわせて参考にしていただければ幸いです。
・データベースとの連携 - データベースへのデータ移行
http://fme-casestudy.blogspot.com/2015/07/blog-post_19.html
・データベースとの連携 - データベースからのデータ抽出
http://fme-casestudy.blogspot.com/2015/07/blog-post_20.html

FMEとデータベースを連携して利用できるようになると、FME、データベース双方の活用の幅が格段に広がります。
まだデータベースユーザーでない方は、チャレンジなさることをお勧めいたします。

新企画「FMEケーススタディ」サイト開設

2015-07-12発信

1.「FMEケーススタディ」サイトの開設について

前々回、前回と2回続けて具体的なワークスペース例をご紹介しましたが、それらも含めて、さまざまなワークスペース例をご紹介するための専用サイト「FMEケーススタディ」を設けましたのでご案内します。
FMEケーススタディURL:
http://fme-casestudy.blogspot.com/

このサイトでは、原則としてウェブ上で公開されているデータを素材として具体的なデータ変換・統合のシナリオを想定し、それを実現するためのワークスペース例を掲載していくこととします。
良く使われるトランスフォーマーやそれらの組み合わせの基本的なパターンを取り上げることにより、現実の課題を解決するためのワークスペース作成の参考例になるようにしたいと考えています。

各記事で取り上げるシナリオ・ワークスペース例は、データフロー全体が一目で見渡せるようにはできるだけ簡潔なものとするとともに、短時間で読み切れるように説明は要点のみにしています。
詳細についてご不明な点がありましたらお問い合わせいただくか、「FMEユーザーフォーラム」でご質問ください。
FMEユーザーフォーラムURL:
https://groups.google.com/forum/?hl=ja#!forum/fmers

また、ケーススタディのテーマについてのご要望がありましたらお知らせください。
ご要望に沿った記事も追加していきたいと思います。

-----
2. FMEのバージョン表記方法について

FMEは年1回（通常は1月中旬）メジャーバージョンアップが行われるとともに、年4～5回、小規模な改良や累積的なバグ修正を行ったアップグレードバージョンがリリースされます。
FME 2014までは、年内のアップグレードバージョンはSP（サービスパック）番号で表されていましたが（例: FME 2014 SP5）、FME 2015からは、ドットで区切った番号で表されるようになりました（例: FME 2015.1.0.3）。
この"YYYY.A.B.C"形式での表記のうち、"A"は従来のSP番号に相当し、年4回程度更新されます。
"B"は"A"の更新サイクル以外の時期にアップグレード版をリリースしたとき、"C"は主にホットフィクス（迅速なバグ修正）をリリースしたときに更新されます。

インターネットに接続している状態で FME Workbench を開き、メニュー: Help > Check for Updates を選択すると、使用中のFMEがその年の最新版であるかどうかが確認できます。
最新版は次のページからダウンロードでき、FME年間保守（または評価版ライセンス）の有効期間内であればいつでもアップグレードできます。
FMEダウンロードページURL:
http://www.safe.com/support/support-resources/fme-downloads/

"B"と"C"の更新は不定期なので時々チェックし、できるだけ最新版をご利用になることをお勧めします。

テーブル結合を伴うワークスペース例

2015-07-05発信

データ統合 - 既存の複数のデータセットからデータを抽出・統合して新たなデータセットを作成することは、FMEの典型的な用途のひとつです。
多くの場合、データ統合の過程ではデータベースの世界で言うところのテーブル結合に相当する処理が必要になり、それがデータ統合の要（かなめ）であるケースも多いと思われます。
今回は次の例によって、FMEでテーブル結合に相当する処理を行うための基本的な方法を紹介いたします。
=====
平成22年国勢調査の人口、世帯数の市区町村別集計表（CSV形式）と調査時点の市区町村の区域を表すGISポリゴンデータ（Shape形式）に基づき、人口、世帯数を属性として持つ市区町村ポリゴンデータ（KML形式, 都道府県別レイヤ）を作成する。

ソースデータセット
(1) 平成22年国勢調査による市区町村別人口、世帯数集計結果
e-Stat 政府統計の総合窓口からダウンロードした「男女別人口及び世帯の種類(2区分)別世帯数」テーブル（CSV 形式, 全国1ファイル）
e-Stat 政府統計の総合窓口
平成22年国勢調査 > 人口等基本集計（男女・年齢・配偶関係，世帯の構成，住居の状態など）> 全国結果
総人口・総世帯数 表番号2「男女別人口及び世帯の種類(2区分)別世帯数」

(2) 平成22年国勢調査時点（2010年10月1日現在）の市区町村ポリゴンデータ
次のツールによって作成した2010年10月1日現在の市区町村ポリゴン（Esri Shape 形式, 全国1ファイル）
Municipality Map Maker ウェブ版 市区町村区域のGISデータ生成ツール
=====

これらのソースデータセットから読み込まれるCSVレコード、ポリゴンはどちらも市区町村コードを属性として持っているので、それが一致することを条件としてCSVの各レコードを対応する市区町村ポリゴンに結合することができます。
これがテーブル結合に相当するもので、FMEでは、FeatureMerger などのトランスフォーマーによってそれが実現されます。

具体的なワークスペースの例は次のページに掲載しましたので、ご参照ください。

FMEケーススタディ「属性結合の基本的な方法」

-----
FMEが多数のフォーマットをサポートし、多種多様なデータ変換機能を備えているということは、統合前の複数のデータセットの間、あるいは、統合前後のデータセットの間でフォーマットが異なっていたとしても、データ抽出、加工、スキーマ変更といったデータ統合に必要な一連のプロセスをひとつのワークスペースで定義・実行できる可能性が高いということを意味します。
データ統合のための全プロセスがひとつのワークスペースで完結できるならば、いくつかの工程に分割して作業分担するよりもはるかに効率的であり、工程ごとに生じる中間データや全体の進捗を管理するためのコストも不要になります。
データセットの多様性、データ変換の複雑さが増せば当然、ワークスペースも複雑で大規模なものになりますが、それによってもたらされる効果もそれだけ大きくなると考えられます。

[事例] 国勢調査人口等集計表とGIS市区町村ポリゴンの結合

FMEケーススタディ「属性結合の基本的な方法」に移動しました。

FME活用例 - 水系域別河川データセットの作成

2015-06-28発信

一言でいうとFMEは何をするソフトウェアなのか？
この問いには、これまで「データ変換」をするものであると答えてきました。
間違いではないのですが、これに続いて「300以上のフォーマットをサポートしている」と紹介すると、FMEは「フォーマット変換」を目的とするツールであると勘違いされてしまうことが多いように感じています。

FMEが目指しているものを少し丁寧に言うと、「ある用途のために必要なデータセットを作成するうえで、可能な限り既存のデータセットを利用するとともに、データ変換の手順を最大限自動化することにより、そのコストを最小化することである」と言えます。
ここで言う「データセット」とは、ある用途で要求されるスキーマ、フォーマットで作成されたデータの集合のことで、データを格納するファイルの配置やファイル名、あるいはデータベース内のテーブルの構成なども仕様として定められているようなものを指します。
「ある用途」は、データセットが必要とされる場面に応じて、システム、プロジェクト、業務などと言い換えることができます。

FMEが多数のフォーマットをサポートしているのは、フォーマットが異なっていたとしても、既存のデータセットを利用して新たなデータセットを作成する手順を自動化できるようにするためであって、フォーマット変換が最終目的ではありません。
もちろんフォーマット変換のためにFMEは活用できますが、FMEの用途はそれだけではないということをご理解いただきたいと思います。

ここで、フォーマットの変換が伴わなくてもFMEが効果的に利用できる例をひとつ紹介いたします。
あるシステムで、全国の河川について水系域別のデータファイルで構成されたデータセットが必要とされており、国土数値情報の河川データを利用してそのデータセットを構築するというミッションがあったとします。
そのデータセットの要件は次のとおりです。
**********
国土数値情報で提供されている河川データセット: 都道府県別の河川流路（ライン）、流路端点（ポイント）データ（Shape形式）を再編成し、次のようなフォルダ階層で水系域別のデータファイル（Shape形式）を格納したデータセットを作成する。

<水系域別河川データセットルートフォルダ>
  + 端点
    + <サブフォルダ: 水系域コードの先頭2桁>
  + 流路
    + <サブフォルダ: 水系域コードの先頭2桁>

出力先のファイル名は次のように水系域コード（6桁の数字）に流路か端点かを表すサフィクスをつけた名前とし、その先頭2桁が一致するサブフォルダに格納する。
端点ファイル名: "<水系域コード>_N.shp"
流路ファイル名: "<水系域コード>_S.shp"

留意事項
国土数値情報（河川）データは都道府県別ファイルで提供されており、県境付近の流路、端点が複数のファイル間で重複しているところがあるため、水系域別に再編成する際には重複データを削除する。
**********

まず、このミッションをクリアするために、FMEがない場合はどのツールを使い、どんな手順が必要で、どのくらいの時間（コスト）がかかりそうかを想像してみてください。
FMEによるソリューションの概要は次のページに掲げました。
FMEケーススタディ「データセットの再編成 - 水系域別河川データセットの作成」

これは全く架空のミッションですが、ディスクシステム内でのファイルの配置やファイル名の命名法がシステムの仕様として定められているということは、現実にも良くあるのではないでしょうか。
そのようなデータセットを構築する際にも、FMEの利用についてご検討いただければ幸いです。

[事例] 水系域別河川データセットの作成

FMEケーススタディ「データセットの再編成 - 水系域別河川データセットの作成」に移動しました。

正規表現の利用

2015-06-22発信

正規表現 (Regular Expressions) というものをご存じでしょうか。

簡単に言えば、正規表現は文字列のパターンを定義した文字列式です。
多くのプログラミング言語が正規表現をサポートしており、これを使うことにより、ある文字列が一定のパターンに一致するかどうかを判定したり、パターン内のグループごとに分割したりすることができます。

FMEでもいくつかのトランスフォーマーで正規表現が利用でき、それらによってデータ変換・統合における課題が簡単に解決できるケースがあります。
以下の例は全て、これまでに実際に私が出会ったことがあるものです。

例1: 都道府県別の統計表
都道府県名の前後や中間に空白が含まれる（「　千  葉  県  」、「 東  京　都　」など）。
都道府県名をキーとして他のテーブルと結合するために、全ての空白を削除しなければならない。

例2: 現地調査結果の表
調査地点の緯度経度が単位を含んだ60進数表現で記述されている（「35度51分56.1秒」、「139度58分25.2秒」など）。
緯度経度に基づいてポイントジオメトリを作成するために、度単位の数値に変換しなければならない。

例3: 会員名簿
生年月日がまちまちな書式の文字列（日付型データではない）で記述されている（「昭和45年12月5日」、「H3.3.10」、「1986/6/25」など）。
データベースに移行するために、和暦年は西暦年に換算したうえで書式を統一しなければならない

FMEでこれらの課題を解決するのには、正規表現が利用できるトランスフォーマー（StringReplacer, StringSearcher）を使った次のようなアプローチが考えられます。

例1: StringReplacerで都道府県名文字列内で「空白類文字」に一致する文字を全て「空文字列」に置き換える。
例2: StringSearcherで緯度、経度文字列から度、分、秒の数値部分を抽出した後、それらを度単位の値に換算する。
例3: これは数段階の処理になります。
(1) StringSearcherで昭和のパターンに一致するものを選択し、年、月、日の値を抽出する。
(2) 昭和に一致しなかったものについて、StringSearhcer(2) で平成のパターンに一致するものを選択し、年、月、日の値を抽出する。
(3) 平成に一致しなかったものについて、StringSearcher(3) で西暦のパターンに一致するものを選択し、年、月、日の値を抽出する。
(4) 昭和・平成の年を西暦年に換算したうえで、データベース移行用の書式に整える。

Excelの関数を使い、あらかじめ望ましい書式に変換した列を元の表に追加しておくこともできますが、これらのトランスフォーマーで正規表現を利用する利点としては次のようなことが挙げられます。
1. 元の表に列を追加した中間データファイルを作成・管理する必要がない。
2. 書式の変換と本体のデータ変換（テーブル結合、ポイントジオメトリ作成、データベースへの移行）をひとつのデータフローで行える。
3. StringSearcherでは想定される書式と一致しないデータの検出も容易にできる。

Excelで書式を変換するよりもはるかに早く、正確にデータ変換・統合ができますし、元のデータに修正があった場合の対応も楽になります。
例示したものと似たような課題に遭遇したときは、正規表現の利用についてもご検討ください。