Read Schema Features with FeatureReader

FeatureReaderでスキーマフィーチャーを読み込む

FME 2015.1 has been released a few days ago.
FME 2015.1が数日前にリリースされました。

In FME 2015.1, a new output port named <Schema> has been added to the FeatureReader transformer. From this port, schema features will be output for each feature type, each feature contains the following attributes as a schema information of a feature type.

FME 2015.1では、FeatureReaderトランスフォーマーに <Schema> という名前の出力ポートが追加されました。このポートからは、フィーチャータイプごとのスキーマフィーチャーが出力され、各フィーチャーはフィーチャータイプのスキーマ情報として次のような属性を持ちます。

attribute{}.name

attribute{}.fme_data_type

attribute{}.native_data_type

fme_feature_type_name

etc.

Since the structure is same as the schema feature read by the Schema (Any Format) reader, it can be used to configure dynamic schema applying the method described in this article.

> Destination Schema is Derived from List Attributes

この構造は Schema (Any Format) リーダーで読み込まれるスキーマフィーチャーと同じなので、次の記事で説明されている方法を応用してダイナミックスキーマを構成するのに使用できます。

> Destination Schema is Derived from List Attributes

Think of a case like this.

- There are many Shape files which are saved in a certain folder.

- Their schemas are unknown when creating the workspace.

- You have to create a new File Geodatabase (*.gdb) and export all Shape features to the gdb.

- The destination schemas should be same as the source schemas.

次のような場合について考えます。

- あるフォルダにたくさんのShapeファイルが保存されている。

- ワークスペースの作成時点でそれらのスキーマは不明。

- 新しいファイルジオデータベース (*.gdb) を作成し、全てのShapeフィーチャーをそのgdbにエクスポートしなければならない。

- 出力先のスキーマはソーススキーマと同じでなければならない。

=====
2015-05-23: oops! It was not essential to merge the schema to data features. Since the Schema feature will be outputted first from the FeatureReader, you can send it directly to the Dynamic writer. Then, the writer can configure the destination schema based on it.
Revised the following.
おっと、データフィーチャーにスキーマをマージすることは必須ではありませんでした。スキーマフィーチャーはFeatureReaderから最初に出力されるので、それを直接ダイナミックライターに送ることができます。ライターはそれに基づいて出力先のスキーマを構成できます。
下記修正。
=====

With the FeatureReader in FME 2015.1, this approach is available.

(1) Get all Shape file paths (*.shp) with a Directory and File Pathnames reader.

(2) Send them to a FeatureReader, select "path_windows" or "path_unix" attribute for the "Dataset" parameter.

(3) Merge schema feature to data features with a FeatureMerger.
Requestor (data feature)  fme_feature_type
Supplier (schema feature)  fme_feature_type_name

(4) (3) Send both the Schema feature and the Data features to a FILEGDB writer with Dyanmic Schema mode. Set "Schema from first feature" to the "Schema Sources" parameter.

FME 2015.1のFeatureReaderでは、次のアプローチが可能です。

(1) Directory and File Pathnames リーダーで全てのShapeファイルパス(*.shp)を取得する。

(2) それらをFeatureReaderに送り、"Dataset"パラメータで"path_windows"または"path_unix"属性を選択する。

(3) FeatureMergerでスキーマフィーチャーをデータフィーチャーに結合する。
Requestor (データフィーチャー)  fme_feature_type
Supplier (スキーマフィーチャー)  fme_feature_type_name

(4) (3) スキーマフィーチャーとデータフィーチャーを両方ともダイナミックスキーマモードのFILEGDBライターに送る。"Schema Sources"パラメーターは"Schema from first feature"（フィーチャータイプごとに最初のフィーチャーのスキーマを使用する）に設定してください。

2015-05-23
Deprecated the left image.
左の図は廃止しました。

There are some changes regarding Feature Types in FME 2015.1. See also this article.

FME 2015.1ではフィーチャータイプに関していくつかの変更があります。次の記事も参照してください。

The Safe Software Blog > The Feature Types They Are a-Changin’

FME 2015.1 build 15479

Change of ListExploder Default Behavior

ListExploderのデフォルトの動作の変更

In FME 2015, the "Attribute Accumulation" parameters group has been introduced into several transformers such as FeatureMerger, PointOnAreaOverlayer, ListExploder and so on.
FME 2015では、FeatureMerger、PointOnAreaOverlayer、ListExploderなどいくつかのトランスフォーマーに"Attribute Accumulation"パラメーターグループが導入されました。

In almost all the transformers having "Attribute Accumulation" group, the behavior with default parameter settings is same as the default behavior of the previous version. They are following the general principle that the backward compatibility should be kept.
"Attribute Accumulation"グループを持つほぼ全てのトランスフォーマーでは、デフォルトのパラメーター設定での動作は以前のバージョンのデフォルトの動作と同じです。これらは後方互換性を保つべきであるという一般原則に従っています。

However, I noticed the ListExploder is not following the principle.
しかし、ListExploderはその原則に従っていないことに気がつきました。

The new ListExploder has these four options depending on the Attribute Accumulation settings.
新しいListExploderには、Attribute Accumulationの設定に応じてこれらの4つのオプションがあります。

	Accumulation Mode	Conflict Resolution
1	Merge Incoming List	Use Original	(default)
2	Merge Incoming List	Use Incoming List
3	Prefix Incoming List
4	Only Use Incoming List

The 1st option is set by default, but the default behavior of the previous version is equivalent to the 2nd option.
1番目のオプションがデフォルトで設定されていますが、以前のバージョンのデフォルトの動作は2番目のオプションに相当します。

I had discussed about this change with Safe support team.
Safe acknowledges that the default behavior of new ListExploder is different from the previous version. And, according to their explanation, the change has been done intentionally to unify the default behavior of the transformers which have "Attribute Accumulation" parameters group.
この変更についてSafe社のサポートチームと話し合いました。
Safe社も新しいListExploderのデフォルトの動作が以前のバージョンと異なることは認めています。そして、彼らの説明によれば、この変更は、"Attribute Accumulation"パラメーターグループを持つトランスフォーマーのデフォルトの動作を統一するために意図的に行われたということです。

I understand that the change is reasonable, but it might cause a confusion to some users who are familiar with the default behavior of the previous ListExploder.
この変更が合理的であることは理解しますが、以前のListExploderのデフォルトの動作に親しんでいるユーザーに混乱をもたらすかも知れません。

Check the parameters always when you use the ListExploder in FME 2015.
FME 2015でListExploderを使うときは、これらのパラメーターをいつも確認してください。

=====
So, I still think it's better that the Attribute Accumulation group will be shown by default, at least in the ListExploder...
なので、Attribute Accumulationグループはデフォルトで表示された方が良いとまだ思っています。少なくともListExploderでは。。。

Use Time Positions on Time Line

タイムライン上の時間位置の利用

Summary of this thread.
このスレッドのまとめ。
FME Community Answers > Merge features based on time

Assuming you have two datasets:
- one contains rasters having a datetime attribute,
- another contains GPS points also having a datetime attribute.
The goal is to give each raster the geographic coordinate of a point having smallest time difference from the raster.
二つのデータセットがあるものとします。
- ひとつは日付時刻属性を持つラスターから成り、
- もう一つはやはり日付時刻属性を持つGPSポイントから成る。
目標は、各ラスターに、そのラスターからの時間差が最も小さいポイントの地理座標を与えることです。

Seemingly the solution would be complicated, but you can solve it easily with the NeighborFinder if you replace every geometry with a time position on a time line - i.e. a coordinate (time, 0) on the X axis.
一見、解決策は複雑になりそうですが、ジオメトリをタイムラインにおける時間位置 - つまりX軸上の座標 (時間, 0) に置き換えれば、NeighborFinerを使って簡単に解決できます。

(1) Convert the datetime value to the count of seconds since the epoch, using a DateFormatter (Destination Date Format: %s).
DateFormatter (Destination Date Format: %s) によって日付時刻値をエポックからの秒数に変換します。

(2) Extract the raster data as an attribute by a RasterExtractor, and replace the geometry with a point (X=seconds, Y=0) by a VertexCreator.
RasterExtractorによってラスターデータを属性として抽出し、VertexCreatorによってジオメトリをポイント (X=秒数, Y=0) に置き換えます。

(3) Extract geographic coordinate (x, y) of the GPS points by a CoordinateExtractor, and replace the geometry with a point (X=seconds, Y=0) by a VertexCreator, as well.
CoordinateExtractorによってGPSポイントの地理座標 (x, y) を抽出し、同様にVertexCreratorによってジオメトリをポイント (X=秒数, Y=0) に置き換えます。

Here, the point (X=second, Y=0) represents the time position of a feature on a time line (X-axis).
ここで、ポイント (X=秒数, Y=0) がタイムライン（X軸）上のフィーチャーの時間位置を表します。

(4) Add a NeighborFinder; send the (2) features to the Base port; send the (3) features to the Candidate port. Then, each Matched feature will have the geographic coordinate (x, y) of a GPS point which has smallest time difference.
NeighborFinderを追加し、(2)のフィーチャーをBaseポートに、(3)のフィーチャーをCandidateポートに送ります。すると、Matchedフィーチャー は、時間差が最小のGPSポイントの地理座標 (x, y)を持つことになります。

(5) Finally, restore the original raster of each Matched feature by a RasterReplacer.
最後にRasterReplacerによってMatchedフィーチャーを元のラスターに復元します。

I think you have ever learned about "Number Line" in school. In fact, the time line is not any one other than the Number Line.
Elementary mathematics is also very helpful in some cases.
学校で「数直線」について習ったことがあると思います。実のところ、タイムラインは数直線に他なりません。
初等数学も時にはとても役に立ちます。

Change Multiple Data Types Simultaneously

複数のデータ型を同時に変更する

FME 2015.1 is coming soon.
FME 2015.1は間もなくリリースされます。

Found a wonderful enhancement of writer feature type in FME 2015.1 beta.
You can change data types of multiple attributes simultaneously.
FME 2015.1ベータでライターフィーチャータイプの素晴らしい機能強化を見つけました。
複数の属性のデータ型を同時に変更することができます。

Select multiple rows with Ctrl+Click.
Ctrlキーを押しながらクリックして複数行を選択。

Change data type of a row in the selection. e.g. char -> number
選択行内のどれかの行でデータ型を変更。例: char -> number

Change width and precision if necessary.
必要に応じて幅と精度も変更。

Quick and intuitive. I have waited for this for long time :)
迅速かつ直感的。長い間これを待っていました(^^)

FME 2015.1 Beta build 15468

Create Schema Features with Python Script

Pythoスクリプトによるスキーマフィーチャーの作成

From this thread.
このスレッドから。
Community Answers > Oracle Spatial to SHAPE

In many cases, you can use the Schema (Any Format) reader to read schemas of source feature types from any format dataset. Schema features contains "attriubte{}" list, it can be used to configure dynamic schema with this method.
"Destination Schema is Derived from List Attributes"
多くの場合には、Schema (Any Format)リーダーを使って、どんなフォーマットでも、そのデータセットからソースフィーチャータイプのスキーマを読むことができます。スキーマフィーチャーは "attribute{}" リストを持っており、次の方法によってダイナミックスキーマを設定するのに使えます。
"Destination Schema is Derived from List Attributes"

However, in the case where the feature type (table) names will be determined at each run-time (i.e. they are unknown when creating the workspace), you cannot use the Schema reader since the feature types cannot be set to the reader beforehand.
しかし、フィーチャータイプ（テーブル）名が実行時に決定されるような場合（つまり、ワークスペース作成時にはそれらが未知である場合）には、フィーチャータイプをあらかじめ設定することができないため、Schemaリーダーを使うことができません。

In such a case, I think a Python script is an effective solution. fmeobjects.FMEUniversalReader class provides the functionality equivalent to the Reader in Workbench.
そのような場合には、Pythonスクリプトが効果的だと思います。fmeobjects.FMEUniversalReaderクラスが、ワークベンチのリーダーに相当する機能を提供します。
=====
Note: Safe is planning to do enhancement regarding schema reading functionality in the near future. This Python approach could be unnecessary after the enhancement has been done.
See also Dale's comment.
注: Safe社は近い将来におけるスキーマ読込に関する機能強化を計画しています。それが実現すると、このPythonによるアプローチは不要になるかも知れません。
デールさんのコメントも参照してください。
=====

For example, if the source feature type (e.g. Oracle Non-spatial database table) names will be given by an input feature which contains an attribute (e.g. "table_list") storing them in comma-delimited format, a PythonCaller with this script creates schema features for each table.
例えば、ソースフィーチャータイプ（例: Oracle Non-spatial データベーステーブル）名が、それらをカンマ区切り形式の属性（例: "table_list"）として持つ入力フィーチャーによって与えられる場合には、次のスクリプトを設定したPythonCallerが各テーブルに対応するスキーマフィーチャーを作成します。
-----
class SchemaReader(object):
    def input(self, feature):
        # Create SCHEMA reader.
        # Set comma-delimited feature type (table) names to "IDLIST" directive.
        directives = ['IDLIST', feature.getAttribute('table_list')]
        reader = fmeobjects.FMEUniversalReader('SCHEMA', False, directives)
     
        # Open dataset.
        # The parameter setting is an example for ORACLE_NONSPATIAL format.
        # Required parameters other than "REAL_FORMAT" are different
        # depending on the real format.
        # See "Mapping File Directives" section in the help documentation
        # on the real format to learn more about the format specific parameters.
        dataset = <service name>
        parameters = [
            'REAL_FORMAT', 'ORACLE_NONSPATIAL',
            'USER_NAME', <user name>,
            'PASSWORD', <password>,
        ]
        reader.open(dataset, parameters)
     
        # Read and output schema features.
        while True:
            schema = reader.read()
            if schema == None:
                break
            self.pyoutput(schema)
         
        # Close the dataset.
        reader.close()

-----

It's simple and efficient, but I noticed that FME will write all the parameter values including password into the log file. For higher security, it might be better to create a format specific reader, rather than the Schema reader.
In this case, you will have to create the "attribute{}" with the script.
これは簡単で効率的ですが、FMEは、パスワードを含む全てのパラメーターの値をログファイルに書き込むことに気がつきました。より高いセキュリティのためには、Schemaリーダーではなく、フォーマット固有のリーダーを作成する方が良いかも知れません。
その場合、"attribute{}"はスクリプトで作成する必要があります。
-----
class SchemaReader(object):      
    def input(self, feature):
        # Create ORACLE_NONSPATIAL reader.
        # Set comma-delimited feature type (table) names to "IDLIST" directive.
        directives = ['IDLIST', feature.getAttribute('table_list')]
        reader = fmeobjects.FMEUniversalReader('ORACLE_NONSPATIAL', False, directives)
     
        # Open dataset.
        # The parameter setting is an example for ORACLE_NONSPATIAL format.
        # Required parameters are different depending on the format.
        # See "Mapping File Directives" section in the help documentation
        # on the real format to learn more about the format specific parameters.
        dataset = <service name>
        parameters = [
            'USER_NAME', <user name>,
            'PASSWORD', <password>,
        ]
        reader.open(dataset, parameters)
     
        # Read and output schema features.
        while True:
            schema = reader.readSchema()
            if schema == None:
                break
         
            # Set Feature Type Name.
            schema.setAttribute('fme_feature_type_name', schema.getFeatureType())
         
            # Create "attribute{}".
            for i, name in enumerate(schema.getSequencedAttributeNames()):
                type = schema.getAttribute(name)
                schema.setAttribute('attribute{%d}.name' % i, name)
                schema.setAttribute('attribute{%d}.fme_data_type' % i, type)
             
            # Ouput Schema Feature.
            self.pyoutput(schema)
         
        # Close the dataset.
        reader.close()
-----

See here to learn more about the FMEUniversalReader class and its methods.
FMEUniversalReaderクラスとそのメソッドの詳細についてはここを参照してください。
Python FME Objects API Reference

Although the example above is for the ORACLE_NONSPATIAL format, I think the same mechanism can also be applied to any other formats.
上の例はORACLE_NONSPATIALフォーマット用ですが、同じ仕組みは他のすべてのフォーマットにも適用できると思います。

FME 2015.0 build 15253