GDBからShapeに変換した後属性の型が変わってしまう

[TJ]

GDBから一連の処理をして、Shapeファイルに出力しています。

検査をしたところ、出力したShapeと元のGDBの属性型の不一致が発見しました。
現象としては、元Shortになっている属性はLongになり、Data型はTextになったという現象です。

ライターのAttribute DefinitionはDynamicになっているのをみて、これは原因ではないかと思い、Manualに変更して、Typeを変更したら、確定のOKボタンが押せなくて、Dynamicにもどしたら、OKボタンがまた押せるようになりました。

Dynamicライダーの属性型を固定したい場合、どのように設定すればよろしいでしょうか？

[Takashi Iijima]

サポートするデータ型はフォーマットによって異なるため、Dynamicライターを使ったときには、FMEは

入力フォーマットのデータ型 -> FME共通のデータ型 -> 出力先フォーマットのデータ型

という翻訳をします。

予想外のデータ型になることが起こる可能性はあり、その場合、Dynamicをやめて属性名とデータ型をマニュアルで設定するのはひとつの解決方法です。

ライターのフィーチャータイププロパティ設定画面

- User Attributesタブ"Attribute Definition"で"Manual"を選択し、

- 属性名とデータ型を手動で設定する。

ManualにしたときにOKボタンが押せなくなったのは、Generalタブで"Geometry"（ジオメトリタイプ）が選択されていなかったからだと思います。

Dynamicのときはスキーマ定義から自動的にジオメトリタイプを判定しますが、Manualのときはユーザーが指定してやる必要があります。

しかし、ShapeスキーマからGDBスキーマへの翻訳で、データ型にそんなに「誤訳」が出るとはちょっと考えにくいです。

Shapeフォーマットには "Short" というデータ型はないはずなんですが、どうやってShapeのデータ型を確認しました？

Shapeリーダーフィーチャータイプのプロパティ設定画面"User Attributes"タブで、入力Shapeのデータ型が何になっているか再確認していただけませんか？

[Takashi Iijima]

あぁ、おそらくArcGISで元Shapeのデータ型をチェックしていますね。

Shapeの属性ファイルはDBFフォーマットを使用しており、Shapeでは次のデータ型しかサポートしていません。

DBF仕様上のデータ型コード: FMEのShapeリーダー/ライターフィーチャータイプでの表現

C: char (バイト数指定）

D: date

N: number（十進数。全桁数と小数部桁数指定）

L: logical

ArcGISではShapeファイル（DBFフォーマット）の属性データ型が正確には分からないんです。ShapeはEsri社が定義したフォーマットなのに、困ったものです。

FMEのShapeリーダーフィーチャータイプでデータ型を確認してください。

[TJ]

教えていただいた通り、Generalタブで"Geometry"を指定し、ManualにしたらOKボタンが押せるようになりました。
但し、今回点線面のデータ全部入っていますので、このやり方の場合、３つのライダーに分けなければなりません。ついでに教えていただきたいのですが、AutomaticとDynamicの違いは何でしょうか？

>どうやってShapeのデータ型を確認しました？

これはFMEではなく、ArcGISで確認していました。元のGDBの属性型はShortになっていて、Shapeに書き出した後、型はLongになってしまいます。

>Shapeフォーマットには "Short" というデータ型はないはずなんですが
ArcGISで既存の他のShapeファイルを確認するすると、確かにShort型の属性型が存在します。ArcGISで属性新規作追加時もShortかLongかが選べるようになっています。

>Shapeリーダーフィーチャータイプのプロパティ設定画面"User Attributes"タブで、入力Shapeのデータ型が何になっているか再確認していただけませんか？

今回、Shape→GDBではなく、GDB→Shapeへの変換です。
FMEでGDBリーダーのタイプを確認すると、ArcGISで確認したShort型の属性はsmallintで、data型の属性はdateになっています。

[TJ]

本当に困りますね、さいやくの場合、出力したShapeを再度ArcGISで型変換処理をしますが、FMEでそのままShort型の属性を作る方法はないのでしょうか？

[Takashi Iijima]

Automatic/Manualは、スキーマをユーザーが定義する方法で、ワークスペースの作成時に出力先のスキーマが決定されます。

このうち、Automaticは、ライターフィーチャータイプをリーダーフィーチャータイプまたはトランスフォーマーに接続したときに、属性を自動的に接続先からコピーする仕組みです。

属性名は正しくコピーされますが、トランスフォーマーを経ていろいろと変換した後だとデータ型は思い通りにならないことが多く、Manualに切り替えて修正しなければならないことが多いです。

Manualは、すべてユーザーが属性名とデータ型を定義する方法です。

これらに対してDynamicは、ワークスペースの実行時にソースデータセットなどのスキーマ定義を参照し、それに従って出力先のスキーマを自動的に定義する仕組みです。

ソースデータセットのスキーマ定義を参照するケースが多いですが、その他にもいくつかバリエーションがあります。全ては説明しきれないので、ここでは割愛します。

GDB->Shapeでしたか。

それにしても、Shapeの属性データ型にはShortもLongもFloatもDoubleもなく、数値型としてはN（number）しかありません。

GDBのShort型をFMEは "smallint"（内部表現としてはfme_int16)　と正しく解釈したが、Shapeフォーマットの属性データ型には"Short"も"Long"もないので、smallint型の整数値が全て格納できる最大限の "number(n,0)" （nは多分5か6）に翻訳した、ということだと思います。

Manualで "number(4,0)" くらいにすればArcGISでも Short と表示されるかもしれませんが、それだと GDBからShapeに変換したときに桁あふれする可能性もあるので、得策ではないように思います。

[Takashi Iijima]

> FMEでそのままShort型の属性を作る方法はないのでしょうか？

フォーマットの仕様としてShapeにはShort型がないので、厳密にはできません。

前回の最後に書いたように、Manualで "number(4,0)" くらいにすればArcGISに Short と解釈させることはできるでしょうが、それだと、GDBからShape移行時に桁あふれするリスクが生じます。

ArcGISがDBFフォーマットの仕様に従ったデータ型の表現をしてくれないというだけのことなので、私はそのままで実害はないと思いますよ。

[Takashi Iijima]

> ArcGISで既存の他のShapeファイルを確認するすると、確かにShort型の属性型が存在します。ArcGISで属性新規作追加時もShortかLongかが選べるようになっています。

おそらくこれが全ての混乱の元ですね。

繰り返しますが、Shapeのフォーマット仕様では、属性データ型としてShortやLongは存在しません。数値データ型は、十進数表現での桁数と小数部桁数を指定するN型 (number) だけです。

FMEはフォーマットの仕様に可能な限り忠実に従っているので、Shapeフォーマットの属性データ型としてShortやLongはありません。

ArcGISでShapeファイルのデータ型としてShortやLongが存在する（ように見える）のはユーザーインターフェース上だけのことで、Shapeのフォーマット仕様上のデータ型としてはどちらもN型（ただし桁数は異なる）です。

追記:

ArcCatalogで新規に作成したShapeファイルの「実際の」データ型は次のようになりました。

ArcCatalogでのデータ型設定  |  作成されたShapeファイルのデータ型  |  FMEが翻訳したデータ型

Long Integer  |  N(9,0)  |  fme_decimal(9,0)

Short Integer  |  N(4,0)  |  fme_decimal(4,0)

Float  |  N(13,11)  |  fme_decimal(13,11)

Double  |  N(19,11)  |  fme_decimal(19,11)

Text  |  C(50)  |  fme_char(50)

Date  |  D  |  fme_date

FMEはShapeファイルに定義されているデータ型を正確に翻訳しています。

GDBのShort型は本当のshort（2バイト整数）型なので、-32768～32767の値が格納できます。

しかし、ArcGISがShapeファイルについて表示するShort型はウソのshort型で、実際に設定されるデータ型は N(4,0): 4桁以下の整数（厳密にいえば「十進数表現で4桁以下、小数部桁数が0の数」）です。

GDBのShort型属性には4桁より大きい数値が格納されうるので、その属性値の移行先のShapeファイル属性のデータ型が"Short"=「4桁以下の整数」だと、4桁より大きい値があったときに正しく移行できないというリスクが生じる、というわけです。

[TJ]

確かにShape（DBF）の仕様ではNumberしかなければ、ArcGISではShortとLongに分けているのがややこしいですね。

更に、そのShortは一般的なShort型ではないのが誤解を招く分け方ですよね。

ちなみに、ArcGISでShapeのShort型の属性にためしに32767を入力して保存しようとしたところ、ちゃんと「この数値フィールドは4桁までの値を確認します。」のメッセージが表示されました。

試してManualにし、型をnumber(4,0)に設定して変換してみたところ、ArcGIS側でShortと認識することができました。

今回処理する属性に実際１桁の整数しか格納されていないため、Manualにし、number(4,0)で対応いたします。

今後Shapeを扱う場合、この違いを意識して注意します。

貴重な情報ありがとうございました。

[Takashi Iijima]

> 今回処理する属性に実際１桁の整数しか格納されていないため、Manualにし、number(4,0)で対応いたします。

1桁の整数しかあり得ないのであれば、"number(1,0)"でもOKです。

Shape属性ファイル（dbf）では、実際の数値の桁数に関わりなく、全てのレコードについてデータ型で指定された桁数（バイト数）分のデータ格納領域を用意します。

したがって、1桁の値しかないということが保証されているのならば、そのフィールドのデータ型を"number(1,0)"にすることでdbfファイルのサイズを小さくすることができます。

[TJ]

dbfはそのような性質も持っているのですか、Shapeはdbfを使っている為、結構いろいろ特性持っていますね。本当に勉強になりました。今後必要な分だけでサイズを定義するよにします。

ありがとうございました。