2016-03-29

基盤地図情報DEMによるラインのドレープ (3Dラインへの変換)

ベクタージオメトリ用のほとんどのデータフォーマットは、ジオメトリの各頂点が高さ方向のZ座標を持つ「3D」ベクタージオメトリの格納をサポートしています。精度の高い3Dベクタージオメトリを作成するのにはそれなりのコストがかかりますが、既存の「2D」ベクタージオメトリの各頂点のZ座標に、地形を表す3Dモデル (サーフェス) から読み取れる標高値を与えることによって、簡易に3D化することで間に合う場合も多いと思います。

サーフェスの起伏に沿ってベクタージオメトリの各頂点にZ座標を与える処理は「ドレープ」 (drape) と呼ばれています。FMEでは、サーフェスデータがない場合でも、3Dポイント/ライン、DEM (数値標高モデル) ラスター、あるいは点群 (ポイントクラウド) があれば、それに基づいてTIN - 不規則三角網サーフェスを作成したうえで、ベクタージオメトリのドレープを行うことができます。

ここでは、利尻島 (北海道北部) の区域をサンプルとして、基盤地図情報数値標高モデル (10mメッシュDEM) に基づくサーフェスを作成するとともに、それによって道路中心線 (2Dライン) をドレープするワークスペース例を掲げます。

FME 2016.0.1.1 build 16177

ソースデータ
1. 数値標高モデル (XML): 利尻島を含む範囲について、基盤地図情報ダウンロードサイトからダウンロードした2次メッシュ5区画分 (メッシュコード: 6741-51, -52, -61, -62, -71) の10mメッシュDEMデータ
2. 道路中心線 (Esri Shapefile): 利尻島を含む範囲について、国土地理院ベクトルタイル提供実験「道路中心線」データを FME によって取得、Shapefile 形式で保存したデータ (2Dライン)

国土地理院「地理院タイル」データ (ベクトルタイル提供実験で提供されているデータを含む) の取得に関しては、次の記事を参照してください。
> 地理院タイルデータの取得 - 西之島付近噴火活動 正射画像の例
> ベクタージオメトリの色 - 国土地理院「地形分類」


FMEワークスペース例

















(ブックマーク上)
[JP_FGD_DEM] リーダー (FME Store カスタムフォーマット): 基盤地図情報DEM (XML) をラスターとして読み込む。
RasterMozaicker: 複数のラスターを結合してひとつのラスターに変換する。
Reprojector: 座標系を変換する (この例ではJGD2000平面直角座標第XII系に変換)。

(ブックマーク下)
[ESRISHAPE] リーダー: 道路中心線データ (Shapefile, 2Dライン) を読み込む。
Reprojector: 座標系を変換する (この例ではJGD2000平面直角座標第XII系に変換)。

SurfaceModeller: DEMラスターに基づいてサーフェスを作成するとともに、それによって道路中心線をドレープする。
[ESRISHAPE] ライター: ドレープ後の道路中心線、サーフェスをそれぞれ Shapefile 形式のファイルに保存する。


SurfaceModeller の TINSurface ポートから出力されるTINサーフェスのデータ構造は Mesh ですが、[ESRISHAPE] ライターは、それを Shapefile (Multipatch タイプ) 形式のファイルに保存することができます。3Dモデル (サーフェス、ソリッド) のデータ構造に関しては、次の記事を参照してください。
> Esri Shapefile 形式による3Dモデルの保存

なお、国土地理院ベクトルタイル提供実験サーバーから道路中心線データを取得する処理をこのワークスペースに組み込んで同時に実行することもできますが、それは今回の主題ではないので、データフローを簡素にするため、あらかじめ別のワークスペースによって取得して Shapefile 形式のファイルに保存したデータを使いました。


結果: 基盤地図情報DEMに基づいて作成したサーフェスとドレープ後の道路中心線 (オレンジ色のライン)
FME Data Inspector による3D表示。サーフェス (地形) の起伏に沿って道路中心線が3D化されました。
利尻島の区域について、基盤地図情報数値標高モデル (10mメッシュDEM)、および、国土地理院ベクトルタイル提供実験「道路中心線」データに基づいて作成















SurfaceModeller は、Points/Lines ポートから入力された3Dポイント/ライン、DEMラスター、あるいは点群 (ポイントクラウド) に基づいてTINサーフェスを作成し、DrapeFeautres ポートからベクタージオメトリを持つフィーチャーが入力された場合には、それに対するドレープを同時に行います。

このトランスフォーマーは多機能で、TINサーフェスの作成とドレープのほかに、等高線、DEMポイント、DEMラスター、ボロノイ図の作成も同時に行うので、場合によってはオーバースペックかも知れません。次のように機能ごとのトランスフォーマーが用意されているので、目的に応じて使い分けることもできます。

トランスフォーマー機能概要
ContourGenerator等高線 (3Dライン) の作成
DEMGeneratorDEMポイントの作成
RasterDEMGeneratorDEMラスターの作成
SurfaceDraperベクタージオメトリのドレープ
TINGeneratorTIN (不規則三角網) サーフェスの作成
VoronoiDiagrammerボロノイ図 (ボロノイ領域を表すポリゴン) の作成

例えば、上記の例で道路中心線のドレープだけを行う場合には SurfaceDraper、サーフェスの作成だけを行う場合には TINGenerator が使えます。TINGenerator に関しては、次の記事も参照してください。
> TIN (不規則三角網) の作成

2016-03-19

基盤地図情報DEMに基づく傾斜方向ラスターの作成

基盤地図情報の数値標高モデル (DEM) のデータは XML 形式のファイルで提供されていますが、FME は、それをファイル (メッシュ区画) 単位の数値ラスターとして読み込むことができます。

ラスターのデータ変換を行うためのさまざまなトランスフォーマーが用意されているので、FME は、基盤地図情報 DEM に基づいて地形のさまざまな特性の分析、あるいはそのためのデータ作成を効率的に行うツールとしても活用できるかも知れません。

ここでは、基盤地図情報10mメッシュ DEM に基づいて 10m x 10m グリッドの傾斜方位角を求め、さらに、傾斜方向を表現するラスターに変換するワークスペース例を掲げます。

サンプルとして、基盤地図情報ダウンロードサービスサイトからダウンロードした次の4ファイル (三宅島周辺2次メッシュ4区画分) の10mメッシュ DEM データを使用しました。
----------
FG-GML-5139-03-dem10b-20090201.xml
FG-GML-5139-04-dem10b-20090201.xml
FG-GML-5139-13-dem10b-20090201.xml
FG-GML-5139-14-dem10b-20090201.xml
----------

FME 2016.0.1.1 build 16177


FMEワークスペース例

[JP_FGD_DEM] リーダー: 基盤地図情報10mメッシュ DEM データ (XML) を数値ラスターとして読み込む。
RasterMosaicker: 読み込んだ複数のラスター (この例では2次メッシュ4区画分) を結合してひとつのラスターに変換
Reprojector: 座標変換 (この例では EPSG:3857 - Spherical Mercator に変換)
RasterResampler: セルサイズ (グリッド間隔) を 10m x 10m に調整
[GEOTIFF] ライター (1): 座標変換、セルサイズ調整後のDEMラスターを出力

(傾斜方向ラスターへの変換)
RasterAspectCalculator: 傾斜方位角をセル値とする REAL64 (64ビット浮動小数点数) 数値ラスターに変換
RasterExpressionEvaluator: 傾斜方向コードをセル値とする UINT8 (符号なし8ビット整数) 数値ラスターに変換
RasterBandNodataSetter: Nodata値の定義 (この例では 99 を Nodata値とする)

(グレースケール表示用パレットの設定)
AttributeFileReader: 表示用の GRAY8 パレット定義を外部ファイルから読み込んで属性として格納
RasterPaletteAdder: パレット設定
[GEOTIFF] ライター (2): 傾斜方向 UINT8 数値ラスター (グレースケール表示用パレット付き) を出力

(画像ラスターへの変換)
RasterPaletteResolver: セル値を対応するパレットの値に変更
RasterInterpretationCoercer: RGBA32 画像ラスターに変換
[PNGRASTER] ライター: 傾斜方向 RGBA32 画像ラスターを出力


JP_FGD_DEM は FME Store で公開されているカスタムフォーマットで、一般のリーダーと同じ操作で任意のワークスペースに追加し、基盤地図情報 DEM データ (XML) を数値ラスター (REAL64, 1バンド, Nodata値=-9999) として読み込むためのリーダーとして利用できます。

RasterAspectCalculator は、DEM ラスターの各セルの傾斜方位角 (傾斜の下り方向。北向きを 0 度とし、右回りで計測した 0 度以上 360 度未満の実数値) を求め、その値をセル値とするラスターに変換して出力します。ただし、海域などで元々 Nodata 値だったセル、および、平坦な地形で方位角が求められなかったセルには、元のラスターで定義されている Nodata 値が設定されます (参考: 傾斜度は RasterSlopeCalculator で求められます)。

RasterExpressionEvaluator により、ひとつ (A) または ふたつ (A, B) のラスターについてセル単位の数値演算を行い、その結果をセル値とするラスターに変換することができます。この例では、RasterAspectCalculator によって求められた傾斜方位角に基づいて傾斜方向を示すコード (整数値) を求め、UINT8 ラスターに変換しました。傾斜方位角と傾斜方向の対応については、次の表のように定義しました。「グレースケール」は、後述する画面表示用の値です。

傾斜方位角の範囲 [以上, 未満) 単位:度傾斜方向傾斜方向コードグレースケール
Nodata: 平坦で求められないなし0128
[337.5, 360.0) または [0.0, 22.5)132
[22.5, 67.5)北東264
[67.5, 112.5)3128
[112.5, 157.5)南東4192
[157.5, 202.5)5224
[202.5, 247.5)南西6192
[247.5, 292.5)西7128
[292.5, 337.5)北西864
Nodata: 海域などで標高データがないなし99255

この定義に基づき、RasterExpressionEvaluator では次の式によって傾斜方位角から傾斜方向コードを求めています。

@if(@isnodata(B[0]),99,@if(@isnodata(A[0]),0,@if(337.5<=A[0],1,@uint8((A[0]+67.5)/45))))
----------
・B[0] (DEMラスターのセル値) が Nodata (海域など) なら 99
・そうでなく、A[0] (傾斜方位角ラスターのセル値) が Nodata (平坦) なら 0
・そうでなく、A[0] が 337.5 以上なら 1 (北)
・そうでければ、A[0] に 67.5 を加えてから 45 で除した値の小数部を切り捨てて UINT8 整数に変換した値
----------
数式中の A[0], B[0] は、それぞれ RasterExpressionEvaluator のA, B ポートから入力されたラスターのセル値を示します。ラスターは複数のバンドを持つことができるので、[ ] 内のインデクス (0 から始まる連番) によってどのバンドのセル値なのかを指定します。この例で取り扱うラスターは 1 バンドしか持たないので、有効なインデクスは 0 だけです。

次の RasterBandNodataSetter では、99 がこのラスターの Nodata 値として解釈されるように設定しました。

ここまでで傾斜方向コードをセル値とする UINT8 数値ラスターが作成できました。これ以降は、画面上で南向きのセルが明るく、北向きのセルが暗く表示されるようにし、さらに、RGBA カラー画像に変換するための処理です。それらについては後述します。


結果: 三宅島 DEM および傾斜方向ラスター (FME Data Inspector による表示例)
左: DEM (数値標高モデル) ラスター 濃: 低 -> 淡: 高 (色が定義されていない数値ラスターのデフォルトの表示)
右: 傾斜方向ラスター 濃: 北向き -> 淡: 南向き (グレースケール)
基盤地図情報10mメッシュ数値標高モデルに基づいて作成
注: グレースケールで表示した傾斜方向ラスターは、一見、陰影起伏 (hillshade) 図に似ていますが、意味するものは全く異なります。陰影起伏図は RasterHillshader トランスフォーマーによって作成できます。




















なんらかの分析に使用するためのデータとしては、RasterBandNodataSetter までのデータフローで作成されるラスターで十分ですが、このワークスペース例では、画面表示したときに斜面がどの方角を向いているかを直感的に分かり易くするために、グレースケールで南向きを明るく、北向きを暗く表示するための処理を追加しました。

まず、AttributeFileReader で、表示用のパレットの定義を外部ファイルから読み込みます。外部ファイルはテキスト形式で、次のように1バイトグレースケール表示用のパレット (傾斜方向コード=セル値とグレースケール値の対応) を定義しました。パレット定義の書式については、RasterPaletteExtractor トランスフォーマーのヘルプを参照してください。

GRAY8
0 128
1 32
2 64
3 128
4 192
5 224
6 192
7 128
8 64
99 255

RasterPaletteAdder でこのパレットをラスターに設定することにより、データとしてのセル値は傾斜方向コードのままで、画面表示したときに上の図の右のように、各傾斜方向コードに対応するグレーの濃淡で表示されるようになります。この例では、これを GeoTIFF 形式のファイルに出力しました。

パレットを持ったラスターに対して RasterPaletteResolver を適用すると、各セルの値が対応するパレットの値に置き換わり、パレットなしのラスターに変換されます。この場合はパレットのタイプが GRAY8 なので、1バイトグレースケールラスターになります。これは不可逆な変換で、このときに元のセル値=傾斜方向コードは失われます。

さらに、RasterInterpretationCoercer によって、他の構造のラスターに変換することもできます。この例では、RGBA32 カラー画像ラスター (4バンド) に変換したうえで、最後に PNG 形式のファイルに出力しました。

上記のワークスペース例で作成される GeoTIFF 形式のデータと PNG 形式のデータは、画面上ではどちらも同じグレースケールで表示されますが、GeoTIFF はセル値として傾斜方向コードを保持した数値ラスターであり、PNG は画面表示用の色の情報だけを持った画像ラスターであることに留意してください。

補足1: PNG 形式もパレットをサポートしているので、RasterPaletteAdder に PNGRASTER ライターを接続し、UINT8 (パレット付き) のラスターとして PNG ファイルに出力することもできます。その場合は、傾斜方向コードもセル値として保持されます。

補足2: パレットの定義は、AttributeCreator などで作成する属性値として記述することによってワークスペースに組み込むこともできますが、上記のワークスペース例のように外部ファイルで定義しておくと、画面上の表現方法の変更がし易いというという利点があります。例えば、次のように外部ファイルでパレットの定義を RGB24 に変更してからワークスペースを再度実行すると、傾斜方向を色分けしたカラフルなラスターが出力されます。

RGB24
0 51,255,0
1 51,102,255
2 51,204,255
3 51,255,0
4 255,255,0
5 255,102,0
6 255,255,0
7 51,255,0
8 51,204,255
99 255,255,255

2016-03-16

Esri Shapefile 形式による3Dモデルの保存

はじめに、FME がサポートする3Dモデルの概要を説明します。

立体形状 (three-dimensional shape) を取り扱うためのデータモデルには、立体の表面を表すサーフェス (Surface) と、立体が占める空間領域を表すソリッド (Solid) があり、FME では、これらをあわせて「3Dモデル」と呼んでいます。

3Dモデルを実装するためのデータ構造にはさまざまなタイプがあり、FME は、次に掲げるデータタイプを使い分けることによって、ソースデータに格納されているジオメトリの構造を可能な限り忠実にシステム内で再現します。

FMEの3Dモデル用データタイプ (データ構造の分類)

  • Surface: サーフェス (単純サーフェスと複合サーフェスの総称)
    • SimpleSurface: 単純サーフェス (次の5タイプの総称)
      • Face: 単一の多角形 (穴があるものを含む) の面
      • RectangleFace: 対角の2頂点で規定される長方形の面
      • TriangleFan: 扇状に連続した複数の三角形で形成される面
      • TriangleStrip: 蛇腹状に連続した複数の三角形で形成される面
      • Mesh: 敷き詰めるように配置された複数の多角形で形成される面
    • CompositeSurface: 複合サーフェス (複数の Surface で形成される面)
  • Solid: ソリッド (単純ソリッドと複合ソリッドの総称)
    • SimpleSolid: 単純ソリッド (次の4タイプの総称)
      • Box: 対角の2頂点で規定される直方体の空間領域
      • BRepSolid: 内部と外部の境界面を表す Surface で囲まれた空間領域
      • Extrusion: Face とそれを押し出す方向・量で定義される柱状の空間領域
      • CSGSolid: Solid 間の和、差、積で求められる空間領域 > 参考
    • CompositeSolid: 複合ソリッド (複数の Solid で形成される空間領域)
  • MultiSurface: マルチサーフェス (階層構造を持たない Surface の集合)
  • MultiSolid: マルチソリッド (階層構造を持たない Solid の集合)
  • Aggregate: 集約ジオメトリ (任意の種類のジオメトリの集合)

各タイプの説明は、データ構造、あるいはそれによって表すことができる形状の特徴を述べたものであり、厳密な定義ではありません。

Aggregate は、3Dモデルだけでなく、ベクター、ラスター、点群など、FME がサポートするあらゆる種類 (形状がないことを示す Null も含む) のジオメトリで構成することができ、階層構造を持つ場合も持たない場合もあります。

同じ種類のジオメトリのみで構成される Aggregate を Homogeneous Aggregate (均質な集約ジオメトリ)、異なる種類のジオメトリが混在する Aggregate を Heterogeneous Aggregate (非均質な集約ジオメトリ) と呼び、取り扱いが異なることがあります。

Aggregate (特に Heterogeneous Aggregate) は、文脈によっては Collection と呼ばれることもあります。

マルチジオメトリ (Multi***) は、論理構造としては「階層構造を持たない均質な集約ジオメトリ」と等価であり、原則としてそれらの間には互換性があります。

データ構造として MultiSurface と Surface、MultiSolid と Solid は区別されますが、ジオメトリの種類 (ジオメトリタイプ) としては、MultiSurface はサーフェス、MultiSolid はソリッドとして取り扱われます。また、ジオメトリの種類としてのサーフェスのみで構成される均質な集約ジオメトリ、ソリッドのみで構成される均質な集約ジオメトリも、ジオメトリの種類としては、それぞれサーフェス、ソリッドとして取り扱われます。

Esri Shapefile 形式はソリッドをサポートしませんが、ソリッド表面の形状をサーフェスに変換できれば Multipatch タイプの Shapefile 形式のファイルに保存することができ、また、そのサーフェスを形成する多角形を Polygon タイプの Shapefile 形式のファイルに保存することもできます。

ソリッドをサーフェスに変換する方法はジオメトリのデータ構造によって異なり、ソースデータセットから読み込まれたデータ構造のままで ESRISHAPE ライターが自動的に変換できるケースもあれば、いくつかのトランスフォーマーを使ってデータ構造を変換しなければならないケースもあります。

ここでは、比較的単純なケースと複雑なケースについて、ソースデータから読み込んだ3Dモデルのジオメトリを Shapefile (Multipatch, Polygon) 形式のファイルに保存するワークスペース例を掲げます。

ソースデータとして、FME Knowledge Center > Knowledge Base: BIM to GIS (Advanced) | IFC LOD 200 to LOD 3 CityGML で解説されているワークスペース例のテンプレート: BIM2GISadvcd_IFC2002CityGML_FME2015.fmwt に含まれる IFC (Industry Foundation Class STEP Files) 形式のデータを使用しました。
----------
・単純なケース: DC_Riverside_Bldg-LOD_100.ifc
・複雑なケース: DC_Riverside_Bldg-ARCH-LOD_200.ifc
----------
これらの IFC データセットには、建物を構成する部材の形状が3Dモデルのジオメトリとして保存されています。

なお、IFC データセットは、通常、複数のフィーチャータイプで構成されており、また、各フィーチャーはさまざまな属性を持っています。実務上はフィーチャータイプや属性に応じて異なる処理をしなければならないこともあるはずですが、ここでは3Dモデルのジオメトリの変換が主題なので、以下のワークスペース例では、そのことは考慮していません。

FME 2016.0.1.1 build 16177


1. 単純なケース

FMEワークスペース例














[IFC] リーダー: IFC データセットから全てのフィーチャーを読み込む。
GeometryFilter: ソリッドを抽出する。
[ESRISHAPE] ライター: Shapefile (Multipatch, Polygon) 形式のファイルに出力する。


結果: Shapefile (Polygon) 形式で保存したデータの FME Data Inspector による3D表示例
ソースデータセット: DC_Riverside_Bldg-LOD_100.ifc












このソースデータセットから読み込まれたフィーチャーは、Extrusion タイプのソリッドと Null (形状を持たないジオメトリ) で構成される非均質な集約ジオメトリによって形状のデータを保持しています。このデータ構造のままでは、ESRISHAPE ライターで Shapefile 形式のファイルに出力することはできないため、ソリッドの部分を抽出する必要があります。

GeometryFilter は、デフォルトではジオメトリのデータ構造を変更しませんが、Homogenize Collections (非均質な集約ジオメトリを均質化する) パラメーターが Yes に設定されたときは、非均質な集約ジオメトリを構成するパーツをジオメトリの種類ごとのマルチジオメトリ (Multi***) に再編成したうえで、それぞれの種類に対応するポートから出力します。この例では、MultiSolid タイプのジオメトリを持つフィーチャーが Solid ポートから出力されます。

ESRISHAPE ライターは、比較的単純なデータ構造であれば、3Dモデルのジオメトリを自動的に Shapefile 形式用のデータ構造に変換してファイルに出力します。その際、デフォルトではサーフェスもソリッドも Multipatch (サーフェス) として解釈され、ライターフィーチャータイプの Geometry パラメーターで出力先のジオメトリのタイプを shape_polygon に指定したときは Polygon に変換されます。

この例では、ソースデータセットから読み込まれたフィーチャーの形状は Extrusion で表現されており、GeometryFilter が出力するフィーチャーのジオメトリは「Extrusion タイプのソリッドのみで構成される MultiSolid」になります。これは、ESRISHAPE ライターがソリッドの表面を表す Multipatch (サーフェス), Polygon に変換できるデータ構造です。

ただし、Polygon については、これだけではソリッドが個別の面に分解され、各面がシングルパートのポリゴンとして出力されます。フィーチャー単位にまとめたマルチパートのポリゴンにしたい場合には、ジオメトリを MultiArea に変換するための処理を加える必要があります。これは、次の「複雑なケース」についても同様です。


2. 複雑なケース

FMEワークスペース例












[IFC] リーダー: IFC データセットから全てのフィーチャーを読み込む。
Counter: 各フィーチャーにユニークなIDとして連番の属性を与える。
GeometryFilter: 非均質な集約ジオメトリを再編成して Surface と Solid を抽出する。

(ブックマーク内)
Deaggregator: MultiSolid および CompositeSolid を SimpleSolid (単純ソリッド) に分解する。
CSGEvaluator: CSGSolid を MultiSolid または BRepSolid に変換する (他のタイプの単純ソリッドはそのまま)。
GeometryCoercer: 単純ソリッド、および MultiSolid を構成する単純ソリッドを CompositeSurface に変換する。

Deaggregator_2: MultiSurface および CompositeSurface を SimpleSurface に分解する。
Aggregator: SimpleSurface を元のフィーチャー (IDが等しいグループ) 単位で集約して MultiSurface を作成する。
[ESRISHAPE] ライター: Shapefile (Multipatch, Polygon) 形式のファイルに出力する。


結果: Shapefile (Polygon) 形式で保存したデータの FME Data Inspector による3D表示例
ソースデータセット: DC_Riverside_Bldg-ARCH-LOD_200.ifc
















このソースデータセットには、Surface と Solid が混在した非均質な集約ジオメトリを持つフィーチャーが含まれており、そのようなジオメトリは、ESRISHAPE ライターだけでは Shapefile 形式用の Multipatch や Polygon データ構造に変換することができません。

これを解決するため、このワークスペース例では、すべての Surface と Solid (の表面) を SimpleSurface (単純サーフェス) に分解したうえで、元のフィーチャーの形状を単純サーフェスのみで構成される MultiSurface として復元することにしました。MultiSurface ならば、ESRISHAPE ライターでファイルに出力することができます。

Counter によって各フィーチャーにID (連番) 属性を与えた後、GeometryFilter (Homogenize Collections: Yes) によって、Surface と Solid が混在した非均質な集約ジオメトリを MultiSurfice と MultiSolid に再編成したうえで、 Surface (MultiSurface を含む) と Solid (MultiSolid を含む) に分類します。

ブックマーク内は、Solid を CompositeSurface (またはCompositeSurface で構成される MultiSurface) に変換するためのデータフローです。

まず、Deaggregator によって全ての Solid を SimpleSolid (単純ソリッド) に分解します。

単純ソリッドのうち Box, BRepSolid, Extrusion は GeometryCoercer によって CompositeSurface に変換できますが、CSGSolid は、そのままでは変換できないため、CSGEvaluator を使用しました。CSGEvaluator は、入力フィーチャーのジオメトリが CSGSolid である場合に、それを MultiSolid (CSGSolid 以外の単純ソリッドで構成される) または BRepSolid に変換して Output ポートから出力し、入力フィーチャーのジオメトリが CSGSolid でない場合は、<Rejected> ポートからそのまま出力します。

そのうえで、GeometryCoercer によって CompositeSurface に変換します。ここで、CSGEvaluator による変換結果が MultiSolid になることがあるので、Geometry XQuery パラメーターによって、ジオメトリの各パーツのデータタイプとして Box, BRepSolid または Extrusion を指定しました。これにより、Box, BRepSolid, Extrusion は CompositeSurface に変換され、「CSGSolid 以外の単純ソリッドで構成される MultiSolid」は「CompositeSurface で構成される MultiSurface」に変換されることになります。

次の Deaggregator_2 によって、はじめから Surface だったものと、ブックマーク内のデータフローによって Solid から変換された Surface の全てを、一旦 SimpleSurface (単純サーフェス) に分解し、最後に、Aggregator によってIDごとに集約することにより、元のフィーチャーの形状を MultiSurface として復元しました。

2016-03-10

ベクタージオメトリの色 - 国土地理院「地形分類」

ベクタージオメトリ (点、線、面) 用のデータフォーマットには、図形を表示したり印刷したりするときの色に関する情報をデータの内容として記録する仕組みを持たないものがありますが、そのようなフォーマットで提供されているデータでも、凡例などによって、色などのジオメトリの表示スタイルが示されている場合があります。

国土地理院ベクトルタイル提供実験の一環として、昨日 (2016-03-09) 公開が始められた「地形分類」ポリゴンデータもそのひとつです。地形分類ベクタータイルデータ (GeoJSON 形式) の内容に色の定義は含まれていませんが、国土地理院ウェブサイトの次のページで地形分類別の「配色」が示されており、地理院地図ではこの配色で表示されます。
地理院ホーム  > ...  > 身の回りの土地の成り立ちと自然災害リスクがワンクリックで分かります

このように、データ提供者が色などのジオメトリの表示スタイルを示している場合、そのデータを利用する際には、可能な限りそれを踏襲するのが妥当であると考えます。

たまたまですが、「地理院タイルデータの取得 - 西之島付近噴火活動 正射画像の例」で紹介したカスタムトランスフォーマー JpGsiTileFetcher について、国土地理院ベクトルタイル提供実験で提供されているベクタータイルデータを取得する機能を追加しました (2016-03-08)。

ここでは、JpGsiTileFetcher (2016-03-08 更新版) によるベクタータイルデータ取得のデモを兼ねて、「地形分類」ポリゴンフィーチャーに凡例で示されている色を設定するワークスペース例を掲げます。

FME 2016.0.1.1 build 16177


地形分類 (図式コード) と色の対応表 (CSV テーブル) の準備

前述のように、国土地理院ベクトルタイル提供実験で提供されている地形分類データ (GeoJSON 形式) そのものには色の情報が含まれていないので、色を定義するためのデータを用意する必要があります。

地理院地図で地形分類データを表示するためのスタイル定義ファイル (JavaScript):
http://cyberjapandata.gsi.go.jp/xyz/experimental_landformclassification/style.js
も公開されており、このファイルによってポリゴンが属性として持っている地形分類コード (code = 図式コード) と色の対応が定義されているので、それに基づいて、あらかじめ次のような CSV テーブルを作成しました。
----------
図式コード,色
10102,#ff9933
11201,#00cc00
10203,#cccc33
10324,#ffff00
... 以下略 (全38分類)
----------


FMEワークスペース例

















1. 国土地理院ベクトルタイル提供実験「地形分類」ポリゴンデータの取得 (上のブックマーク)
Creator: フィーチャーを1個作成して出力する。
2DBoxReplacer: データを取得する範囲を表す矩形ポリゴンを作成する。
CoordinateSystemSetter: 矩形ポリゴンに座標系 (WGS 84 緯度経度) を設定する。
JpGsiTileFetcher: 矩形ポリゴンをカバーする範囲の「地形分類」データを取得する。

2. 図式コードと色の対応表 (CSV) の読込と変換 (下のブックマーク)
 [CSV] リーダー: 地形分類を示す図式コードと色の対応表を読み込む。
AttributeCreator: 「色」属性値 (HTML用のカラーコード: #******) に基づいて色に関する属性を作成する。

3. 属性結合
FeatureMerger: 地形分類を示すコードをキーとして、色に関する属性をポリゴンに結合する。

JpGsiTileFetcher (2016-03-08 更新版) は、国土地理院ベクトルタイル提供実験で提供されているベクタータイルデータを取得し、ベクタージオメトリと属性を持つフィーチャーに変換したうえで Vector ポートから出力します。

デフォルトでは Workbench インターフェース上に属性名は公開されませんが、必要に応じて Attributes to Expose (Vector) パラメーター、または AttributeExposer トランスフォーマーによって属性名を公開することができます。「地形分類」ポリゴンは地形分類を示す code 属性を持っており、この例ではそれを FeatureMerger による属性結合のキーとする必要があるため、Attributes to Expose (Vector) パラメーターによって公開しました。


FME ワークスペースでは、一般に次のフォーマット属性 (FME ジェネリック属性) によって、フィーチャー (ベクタージオメトリ) の色を設定することができます。
----------
fme_color: 点、線 (面の境界線を含む) の色 (ペンカラー)
fme_fill_color: 面の内部領域の色 (フィルカラー, 塗りつぶしの色)
----------

また、次のフォーマット属性によって不透過率を設定することもできます。ただし、ベクタージオメトリの透過度の定義を標準でサポートするデータフォーマットはごく少数です (KML だけかも知れません)。
----------
fme_pen_opacity: 点、線 (面の境界線を含む) の不透過率 (0: 透明 ~ 1: 不透過)
fme_fill_opacity: 面の内部領域の不透過率 (同上)
----------

fme_color および fme_fill_color の値は、ディスプレイの表示などで一般的に使われている光の三原色 - R: 赤、G: 緑、B: 青それぞれの強度 (0 ~ 1 の範囲で正規化した値) をカンマ区切りで列挙した文字列 "r,g,b" です。例えば黒は "0,0,0"、赤は "1,0,0"、白は "1,1,1" と表現されます。

しかし、CSV テーブルから読み込まれる「色」の値はHTML用の形式、すなわち、R, G, B 値の16進数表現各2桁 (10進数では 0 ~ 255) を連結し、先頭に # をつけた文字列 (例えば黒: #000000、赤: #ff0000、白: #ffffff) なので、これを "r,g,b" 形式に変換する必要があります。この例では、AttributeCreator によってその変換を行いました。

AttributreCreator パラメーター設定画面























まず、最初の3行で CSV テーブルから読み込まれた「色」の値 (#******) から R, G, B 2桁ずつを取り出し (@Substring 関数)、先頭に "0x" をつけて数式内で使用できる16進数表現に整えてから 255 で除して 0 ~ 1 の率に換算し、それぞれ _r, _g, _b 属性に格納しました。

次に、fme_color に、それらの値をカンマ区切りで連結した文字列を与え、fme_fill_color にも同じ値を設定しました。また、不透過率 (fme_pen_opaciry, fme_fill_opaciry) は、地理院地図のスタイル設定に準じて 0.5 としました。

この例のように、ひとつの AttributeCreator で複数の属性を作成した場合、ワークスペースの実行時には、パラメーター設定画面における行の順番 (上から下) で属性の作成、値の設定が行われます。また、新たに作成した属性の値を、同じ AttributeCreator 内のそれより下の行で参照することもできます (FME 2016 以降)。


KMLファイルへの出力

FeatureMerger で「地形分類」ポリゴンフィーチャーにこれらの属性を結合した後、色と透過度の定義をサポートするフォーマットのデータセットに出力すれば、それらを記録することができます。次の図は、地形分類コード (code) が同じ隣接ポリゴンを融合 (dissolve) してから、KML ファイルに出力する例です。














以前の記事で、KMLStyler トランスフォーマーによる KML 表示スタイルの設定に触れたことがありますが、フィーチャーが fme_color 等の表示スタイルに関するフォーマット属性 (FME ジェネリック属性) を持っている場合には、KMLStyler を使わなくても、OGCKML ライターがそれらの値に基づいて KML 用の表示スタイルを構成します。このメカニズムは、フィーチャーの表示スタイルの定義をサポートする他のフォーマットのライターについても同様です。

結果: 函館空港周辺の地形分類 (KML形式ベクターデータ) - Google Earth による表示例
国土地理院ベクトルタイル提供実験「地形分類」データ (ズームレベル14, 函館空港周辺12タイル) に基づいて作成。




















カラー画像 (ラスター) への変換

ベクタージオメトリに色に関する属性を与えた後、ImageRasterizer によってカラー画像 (ラスター) に変換することもできます。

PNG形式の画像に変換する例











結果: 函館空港周辺の地形分類 (PNG形式ラスターデータ)
国土地理院ベクトルタイル提供実験「地形分類」データ (ズームレベル14, 函館空港周辺12タイル) に基づき、上のワークスペースによって作成したPNGファイルをそのままここに添付しています。
・解像度: 1タイルあたり 256 x 256 ピクセル, 全体 1024 x 768 ピクセル
・不透過率: 0.5 (fme_fill_opacity の値を使用)
・アンチエイリアス: なし
解像度、不透過率、アンチエイリアスの有無などは、ImageRasterizer のパラメーターとしてコントロールできます。




















上記のワークスペース例では、データ提供者によって定義されたHTMLカラー値 #****** を FME が解釈できる色の表現 "r,g,b" に変換するために AttributeCreator を使いましたが、ワークスペース内で新たに色を定義するような場合には、FeatureColorSetter トランスフォーマーを使うこともできます。このトランスフォーマーでは、OS 標準の色選択ダイアログボックスによって実際の色を見て選択することにより、その色に対応する fme_color, fme_fill_color の値を設定することができます。

また、表示スタイルをサポートするいくつかのフォーマットについては、***Styler という名前のフォーマット専用の表示スタイル設定用のトランスフォーマーも用意されており、出力先データセットのフォーマットによっては、それらを使用することもできます。

2016-03-08

ベクタータイルデータへの変換 - 国土数値情報 (ダム)

国土地理院は「ベクトルタイル提供実験」を行っており、地理院地図 (情報 > 表示できる情報 > 提供実験) で実験中の何種類かのベクターデータ (線、点) を閲覧することができます。ベクタータイルデータを表示するためのソースコード等も GitHub のリポジトリで公開されており、それらを参考にすれば、同実験で公開されているものと同等のウェブアプリケーションを作成するのは難しくありません。

FME ユーザーとしては、地理院地図に表示されるベクターデータが、どのように作成されたかの方に関心があります。「ベクトルタイル提供実験」で提供されているデータは、ウェブマップタイルの単位で作成されている GeoJSON ファイルのセットですが、はじめからそのような形態で作成された地理情報データセットは、まず存在しないでしょう。国土地理院の実験と同様の手法でベクターデータを提供するプロジェクトでは、既存のベクターデータセットをウェブマップタイル単位のデータファイルのセット (ここでは「ベクタータイルデータ」と呼ぶことにします) に変換するプロセスが必要になるはずであり、その部分では FME が活用できるかも知れません。

そのようなデータ変換を行うワークスペースを容易に作成できるよう、カスタムトランスフォーマー WebMapTileClipper を作成し、FME Store で公開しました。このトランスフォーマーは、パラメーターで指定したズームレベルのウェブマップタイルによって入力フィーチャーのジオメトリをクリップし、クリップ後のフィーチャーにズームレベルとタイルインデクスを格納した属性を付加して出力します。

ここでは、WebMapTileClipper を使って国土数値情報で提供されているダムデータ (Esri Shapefile 形式ポイント) をズームレベル10のタイルでクリップし、GeoJSON 形式のベクタータイルデータに変換するワークスペース例を掲げます。

※FME Store で公開されているカスタムトランスフォーマーは、FME Workbench の Transformer Gallery (FME Store フォルダ) に格納されており、標準のトランスフォーマーと同じ操作で任意のワークスペースに追加、利用できます。

FME 2016.0.1.0 build 16174

FMEワークスペース例



















[ESRISHAPE] リーダー: Esri Shapefile 形式の国土数値情報ダムデータ (ポイント) を読み込む。
WebMapTileClipper (FME Store): ズームレベル10のウェブマップタイルによってダムデータをクリップする。
Reprojector: WGS 84 緯度経度に座標変換する。
SubstringExtractor: 竣工年属性 (年月日文字列) を「年」のみの文字列 (先頭4桁) に変換する。
[GEOJSON] ライター: GeoJSON 形式でファイルに出力する。

ウェブマップタイルでクリップされたフィーチャーをベクタータイルデータとして使用するには、ズームレベル、タイルインデクスによって識別できるファイルパス (URL) に振り分けて出力する必要があります。地理院地図の「ベクトルタイル提供実験」では、次のようなファイルパスが使用されています。

<ルートフォルダ>/<データ名>/{z}/{x}/{y}.geojson
{z}: ズームレベル
{x}: x 方向のタイルインデクス (西から東に向かって増える方向)
{y}: y 方向のタイルインデクス (北から南に向かって増える方向)

WebMapTileClipper はクリップ後のフィーチャーに次の3つの属性を与えるので、ライターの Fanout Dataset (出力先データセットの振り分け) 機能を使い、これらの値に基づいて各フィーチャーの出力先ファイルを適切に決定することができます。Fanout Dataset の設定方法については後述します。
_zoom_level: ズームレベル
_tile_column: x 方向のタイルインデクス
_tile_row: y 方向のタイルインデクス

WebMapTileClipper に入力するフィーチャーには適切な座標系が設定されている必要があり、また、出力フィーチャーには EPSG:3857 (Spherical Mercator) 座標系が設定されます。国土数値情報 (ダム) データ (Shapefile 形式) には座標系が定義されていないので、リーダーの Coordinate System パラメーターによって LL-JGD2K (JGD2000緯度経度) を設定するとともに、クリップ後のフィーチャーについて、Reprojector によって WGS 84 緯度経度に座標変換を行いました。


結果: ウェブアプリケーションによるダム地点の表示例
地理院地図「ベクトルタイル提供実験」と同様に、Leaflet ライブラリ、および Leaflet GeoJSON Tile Layer プラグインを使用した JavaScript アプリケーションです。ズームレベル10以上のときに、上記ワークスペースによって作成したベクタータイルデータに基づいてダム地点を示すマーカーを表示します。
ベースマップ: OpenStreetMap
※ローカルサーバーでのテスト結果をキャプチャしたものであり、インターネット上では公開していません。





















Fanout Dataset の設定

Workbench の Navigator ウィンドウで、ライターの Fanout Expression パラメーターにフィーチャーの属性値を使った文字列式として出力先のデータセット名 (ルートフォルダ以下のファイルパス) を設定することにより、それらの属性値に応じて異なるデータセット (ファイル) にフィーチャーを振り分けて出力することができます。

このワークスペース例では、WebMapTileClipper がクリップ後のフィーチャーに与えたズームレベル、タイルインデクスを使い、国土地理院「ベクトルタイル提供実験」の方式に準じて次のようなファイルパスを設定しました。

ksj_dam/@Value(_zoom_level)/@Value(_tile_column)/@Value(_tile_row).geojson

"@Value(属性名)" は、ワークスペースの実行時にその属性の値に置き換わります。





















ディスクシステムには、次のようなフォルダ階層による GeoJSON ファイルのセットが作成されます。















Fanout Dataset は複数のデータセットにフィーチャーを振り分けて出力するための簡便なオプション機能ですが、このオプションを使用するライターは、受け取ったフィーチャーをキャッシュし、すべてのフィーチャーが到着してからファイルへの出力を始めるので、メモリ使用効率が良い仕組みではありません。また、WebMapTileClipper の処理内容でも、フィーチャーをメモリに一時的に格納する部分があります。

国土数値情報でデータが提供されているダム数は全国で 3000 箇所程度に限られており、また、この例ではズームレベルが大きくない (タイル数 = ファイル数が少ない) ので、Fanout Dataset を使ったひとつのワークスペースによって全国分のデータを一括して処理することができました。しかし、データ量が多い、あるいはズームレベルが大きい場合には、この方法では極めて効率が悪くなったり、メモリオーバーフローによって変換が失敗したりする可能性があります。

実務上は、ソースデータの規模や提供形態に応じて妥当な方法を検討する必要があります。例えば、ソースデータがメッシュ区画あるいは行政区域の単位で分割したファイルに保存されている場合には、まず、ソースデータのファイルの単位でクリップ処理を行い、ズームレベル、タイルインデクスを含めてクリップ後のフィーチャーをデータベースに格納しておき、その後、バッチ処理によってタイル (あるいは一定の範囲のタイルのグループ) ごとにデータベースからデータを抽出して GeoJSON 形式に変換・出力するという二段構えのアプローチが良さそうです。

データベースにデータを格納しておくと、ソースデータの一部に変更があったときに該当するタイルのみを更新する仕組みを作ることも容易になり、データの保守の面でも有利であると考えられます。

下の図は、2つのワークスペースによって、基盤地図情報ダウンロードサービスサイトで2次メッシュ区画単位の GML ファイルによって提供されている等高線データのうち、三宅島周辺4区画分をズームレベル15~18の GeoJSON 形式ベクタータイルデータに変換した実験結果です。

まず、入力ファイル (2次メッシュ区画) の単位でタイルによるクリップを行って、その結果を PostGIS データベースに格納するワークスペースを実行し、次に、タイルごとに PostGIS データベースからデータを抽出して GeoJSON ファイルに出力するワークスペースをバッチ処理で実行しました。この方法ならば、仮に全国分のデータを変換するとしてもメモリオーバーフローが生じることはありません。ただし、今回の実験結果からは、全国分の変換を行うのに要する時間は数日のオーダーになると推測されます。FME による一連のデータ変換プロセスは自動化でき、変換を行っている間に人員を拘束するわけではないので「数日」は許容範囲かも知れませんが、パフォーマンスを改善する余地はまだあります。

基盤地図情報 (基本項目) 等高線 (GML) からベクタータイルデータ (GeoJSON) への変換結果
三宅島周辺2次メッシュ4区画分 (2次メッシュコード: 513903, 513904, 513913, 513914) による実験
・ズームレベル15: 100m 刻みの等高線
・ズームレベル16: 50m 刻みの等高線
・ズームレベル17: 20m 刻みの等高線
・ズームレベル18: 全ての等高線
ベースマップ: 地理院タイル (白地図)
※ローカルサーバーでのテスト結果をキャプチャしたものであり、インターネット上では公開していません。