最近FMEストアで公開したトランスフォーマー
AttributeSwapper
Swaps the values of specified two attributes (A and B) unconditionally by default.
Optionally, you can choose one of these conditional swapping modes.
"A < B": Swap the values only when A is less than B.
"A > B": Swap the values only when A is greater than B.
The internal storage data types of the attributes will also be swapped. And also <null> and <missing> will be swapped, but they will be treated as the empty string when comparing values in conditional swapping mode.
The main process has been implemented with a Tcl script.
指定した二つの属性（A及びB）の値を、デフォルトでは無条件で交換します。
必要に応じて、次のうちひとつの条件付きスワップモードを選べます。
"A < B": AがBより小さいときだけ交換する。
"A > B": AがBより大きいときだけ交換する。
属性の内部データ型も交換されます。また、<null>及び<missing>も交換されますが、条件付きスワップモードで値を比較するとき、それらは空文字列として扱われます。
主処理はTclスクリプトで実装されています。
FeatureAlternator
Outputs the features entered from the two input ports (A and B) alternatively. i.e. A, B, A, B, ...
If the number of features entered from one input port is greater than another, the remainder features will be output from RemnantA or RemnantB port after all alternated features have been output.
The main process has been implemented with a Python script.
二つの入力ポート（A及びB）から入力されたフィーチャーを交互に出力します。つまり、A, B, A, B, ...のように。一方のポートから入力されたフィーチャーの数が他方よりも多かった場合、交互のフィーチャーが出力された後、残りのフィーチャーはRemnantAまたはRemnantBポートから出力されます。
主処理はPythonスクリプトで実装されています。
PathSegmentJoiner
Transforms a path into a line by connecting its path segments. By default, the transformer transforms the input path only if it is a linear path that doesn't contain arc-segments.
If you set "Yes" to the "Transform Non-Linear Path after Stroking Arc Segments" parameter, the transformer also transforms non-linear paths into lines after stroking their arc-segments.
The resulting lines will be output from the Touched port; untouched features will be output from the Untouched port.
The main process has been implemented with a Python script.
構成するセグメントを連結することにより、パスをラインに変換します。デフォルトではアーク（弧）セグメントを含まない線形のパスのみを変換します。
"Transform Non-Linear Path after Stroking Arc Segments"パラメーターを"Yes"に設定した場合は、非線形のパスについても、アークセグメントを近似するラインに置き換えてから変換します。
変換後のラインはTouchedポートから出力され、変換されなかったフィーチャーはUntouchedポートから出力されます。
主処理はPythonスクリプトで実装されています。
=====
2015-05-25
ZipArchiver
Compresses a file and appends it into the specified zip file.
The archive name will become the same as the target file name. If a file having the same name as the target file has been archived in the zip file already, the target file will not be archived.
The transformer creates a new zip file when receiving the first file that should be archived into it, if the specified zip file doesn't exist.
-----
Note: Currently this transformer DOES NOT SUPPORT file path strings containing Non-ASCII characters. Unexpected result may occur if the target file path and/or zip file path contain Non-ASCII characters.
ファイルを圧縮し、指定したzipファイルに追加します。
アーカイブ名は対象のファイル名と同じになります。対象とするファイルと同じ名前のファイルがすでにzipファイルにアーカイブされていた場合、その対象ファイルはアーカイブされません。
指定したzipファイルが存在しない場合、このトランスフォーマーはそれにアーカイブすべき最初のファイルを受け取ったときに新しいzipファイルを作成します。
-----
注：現在このトランスフォーマーは、非ASCII文字（半角の英数字・記号以外の文字）を含むファイルパス文字列をサポートしていません。 対象ファイルパスおよび/またはzipファイルパスに非ASCII文字が含まれている場合、予期しない結果が生じることがあります。
=====
FME 2015.1.0.1 build 15480
2015-05-17
2015-05-16
NeighborFinder - Collect All Candidates for Each Base
NeighborFinder - 各ベースに対して全ての候補フィーチャーを集める
The traditional way is to set an enough large value to the "Maximum Distance" parameter and specify a Close Candidate List Name.
伝統的は方法は、"Maximum Distance"（最大距離）パラメーターに十分大きな値を設定し、Close Candidate List Name（近い候補を格納するリスト名）を指定することです。
"To get the distance from a given Base to all Candidate features, use a very large number for this parameter and specify a Close Candidate List Name."
-- Help on the NeighborFinder
「ベースフィーチャーから全ての候補フィーチャーまでの距離を取得するには、このパラメーターに非常に大きな値を設定するとともに、Close Candidate List Nameを指定してください。」
（NeighborFinderのヘルプより）
Now, the "Number of Neighbors to Find" parameter has been added to the transformer in FME 2015. You have to specify at least one of this parameter and the "Maximum Distance".
さて、FME 2015では、"Number of Neighbors to Find"パラメーターが追加されました。このパラメーターと"Maximum Distance"の少なくともどちらか一方は指定する必要があります
You now have these three choices about the method of finding neighbors.
これで、近傍フィーチャーの探し方に関して次の三つの選択肢を持つことになりました。
1. Number of Neighbors to Find: <not set>, Maximum Distance: D
Find neighbors in candidates within D. It's equivalent to the previous version.
距離D以内にある候補の中で近傍を探す。これは以前のバージョンと同じ。
2. Number of Neighbors to Find: N ( > 0), Maximum Distance: <not set>
Find neighbors in closer N candidates. If you want to find the closest neighbor regardless of the distance, you can use this option with setting 1 as N. Probably it's the most frequent use case.
近い方からN個の候補の中で近傍を探す。距離に関係なく最も近い近傍を見つけたいときは、Nに1を設定してこのオプションが使えます。おそらくそれが最も多い使用法でしょう。
3. Number of Neighbors to Find: N ( > 0), Maximum Distance: D
Find neighbors in closer maximum N candidates within D.
距離D以内で近い方から最大N個の候補の中で近傍を探す。
In fact, the traditional way mentioned above is not something special, just is an application of the 1st method. If the maximum distance between base and candidate in the data is known when creating the workspace, there is no problem with the way. Just set a value greater than the maximum D to the "Maximum Distance" parameter. That's it.
実のところ、前述の伝統的な方法は特別なものではなく、第一の方法の応用に過ぎません。ワークスペースの作成時にデータにおけるベースと候補の間の最大距離が既知であれば、この方法には何も問題はありません。単にその最大距離より大きい値を"Maximum Distance"に設定するだけです。
But if it's difficult to determine the maximum distance, how to?
しかし、その最大距離を決めるのが難しいときは、どうします？
In FME 2014 or earlier, it was necessary to estimate the maximum distance anyhow.
In FME 2015, I noticed that the transformer collects all candidates for each base with this setting.
FME 2014以前では、何とかしてその最大距離を推定する必要がありました。
FME 2015では、次の設定によって各ベースに対して全ての候補が集められることに気がつきました。
Number of Neighbors to Find: 0, Maximum Distance: <not set>
Interesting, but it's not documented anywhere. I'm not sure whether it is a correct behavior intended by the developer.
面白いけど、この方法はどこにも記載されていません。開発者が意図した正しい動作であるかどうかは分かりません。
FME 2015.1.0.1 build 15480
The traditional way is to set an enough large value to the "Maximum Distance" parameter and specify a Close Candidate List Name.
伝統的は方法は、"Maximum Distance"（最大距離）パラメーターに十分大きな値を設定し、Close Candidate List Name（近い候補を格納するリスト名）を指定することです。
"To get the distance from a given Base to all Candidate features, use a very large number for this parameter and specify a Close Candidate List Name."
-- Help on the NeighborFinder
「ベースフィーチャーから全ての候補フィーチャーまでの距離を取得するには、このパラメーターに非常に大きな値を設定するとともに、Close Candidate List Nameを指定してください。」
（NeighborFinderのヘルプより）
Now, the "Number of Neighbors to Find" parameter has been added to the transformer in FME 2015. You have to specify at least one of this parameter and the "Maximum Distance".
さて、FME 2015では、"Number of Neighbors to Find"パラメーターが追加されました。このパラメーターと"Maximum Distance"の少なくともどちらか一方は指定する必要があります
You now have these three choices about the method of finding neighbors.
これで、近傍フィーチャーの探し方に関して次の三つの選択肢を持つことになりました。
1. Number of Neighbors to Find: <not set>, Maximum Distance: D
Find neighbors in candidates within D. It's equivalent to the previous version.
距離D以内にある候補の中で近傍を探す。これは以前のバージョンと同じ。
2. Number of Neighbors to Find: N ( > 0), Maximum Distance: <not set>
Find neighbors in closer N candidates. If you want to find the closest neighbor regardless of the distance, you can use this option with setting 1 as N. Probably it's the most frequent use case.
近い方からN個の候補の中で近傍を探す。距離に関係なく最も近い近傍を見つけたいときは、Nに1を設定してこのオプションが使えます。おそらくそれが最も多い使用法でしょう。
3. Number of Neighbors to Find: N ( > 0), Maximum Distance: D
Find neighbors in closer maximum N candidates within D.
距離D以内で近い方から最大N個の候補の中で近傍を探す。
In fact, the traditional way mentioned above is not something special, just is an application of the 1st method. If the maximum distance between base and candidate in the data is known when creating the workspace, there is no problem with the way. Just set a value greater than the maximum D to the "Maximum Distance" parameter. That's it.
実のところ、前述の伝統的な方法は特別なものではなく、第一の方法の応用に過ぎません。ワークスペースの作成時にデータにおけるベースと候補の間の最大距離が既知であれば、この方法には何も問題はありません。単にその最大距離より大きい値を"Maximum Distance"に設定するだけです。
But if it's difficult to determine the maximum distance, how to?
しかし、その最大距離を決めるのが難しいときは、どうします？
In FME 2014 or earlier, it was necessary to estimate the maximum distance anyhow.
In FME 2015, I noticed that the transformer collects all candidates for each base with this setting.
FME 2014以前では、何とかしてその最大距離を推定する必要がありました。
FME 2015では、次の設定によって各ベースに対して全ての候補が集められることに気がつきました。
Interesting, but it's not documented anywhere. I'm not sure whether it is a correct behavior intended by the developer.
面白いけど、この方法はどこにも記載されていません。開発者が意図した正しい動作であるかどうかは分かりません。
FME 2015.1.0.1 build 15480
2015-05-08
Mark End Nodes / Coordinates - Data Inspector
Did you know this? - FME 2015.1 Data Inspector
これ知ってました？
これ知ってました？
2015-05-07
FME stores all attributes as character strings (?): Part 3
FMEは全ての属性を文字列として格納する (?): パート3
Previously I quoted this description from the Workbench help, twice.
以前2回、ワークベンチのヘルプから次の説明を引用したことがあります。
"Feature attributes are usually a primitive type: integers, floats, characters. Internally, FME stores all attributes as character strings and automatically converts between a string representation and a numeric representation as needed."
-- FME Workbench (2015.0 or earlier) > FME Architecture (Reference) > Attribute
2013-05-19 FME stores all attributes as character strings
2013-09-30 FME stores all attributes as character strings: Part 2
Today, I noticed that the "FME Architecture" section has disappeared in FME 2015.1.
今日、FME 2015.1では"FME Architecture"の章が消えていることに気がつきました。
Probably old FME stores all attributes as character strings, but it seems not to be true in the current FME. Actually I frequently see "64 bit integer", "64 bit real" etc.
おそらく古いFMEは全ての属性を文字列として格納するのでしょうが、現在のFMEではそうではないようです。実際、"64 bit integer"、"64 bit real"などをよく見かけます。
I guess a big change about internal attribute data handling has been done for FME 2015, but I'm unclear what the current rule on the data types is.
If the section would be restored with update, it could become clear.
FME 2015では、内部での属性データの取り扱いについて大きな変更があったと推測しますが、データ型についての現在のルールは不明です。
もしその章が更新されて復活したならば明確になるのかも知れませんが。
Previously I quoted this description from the Workbench help, twice.
以前2回、ワークベンチのヘルプから次の説明を引用したことがあります。
"Feature attributes are usually a primitive type: integers, floats, characters. Internally, FME stores all attributes as character strings and automatically converts between a string representation and a numeric representation as needed."
-- FME Workbench (2015.0 or earlier) > FME Architecture (Reference) > Attribute
2013-05-19 FME stores all attributes as character strings
2013-09-30 FME stores all attributes as character strings: Part 2
今日、FME 2015.1では"FME Architecture"の章が消えていることに気がつきました。
Probably old FME stores all attributes as character strings, but it seems not to be true in the current FME. Actually I frequently see "64 bit integer", "64 bit real" etc.
おそらく古いFMEは全ての属性を文字列として格納するのでしょうが、現在のFMEではそうではないようです。実際、"64 bit integer"、"64 bit real"などをよく見かけます。
I guess a big change about internal attribute data handling has been done for FME 2015, but I'm unclear what the current rule on the data types is.
If the section would be restored with update, it could become clear.
FME 2015では、内部での属性データの取り扱いについて大きな変更があったと推測しますが、データ型についての現在のルールは不明です。
もしその章が更新されて復活したならば明確になるのかも知れませんが。
2015-05-04
Destination Feature Type Name Setting in FME 2015.1
FME 2015.1における出力先フィーチャータイプ名の設定
In FME 2015.1, the "Fanout By Attribute" doesn't appear in writer feature type properties dialog. The Feature Type Fanout has been retired?
FME 2015.1では、ライターフィーチャータイププロパティ設定画面で"Fanout By Attribute"が表示されません。フィーチャータイプ・ファンアウトは廃止された？
FME 2015.0 build 15253
FME 2015.1 build 15479
The answer is also "Yes", and can also be "No".
答えは「はい」でもあり、「いいえ」でもあり得ます。
Yes, the term "Feature Type Fanout" will be deprecated in the context of setting a writer feature type properties. But the functionality itself has not been deprecated.
You can use the functionality through setting an attribute to the feature type name field.
はい。「フィーチャータイプ・ファンアウト」という用語は、ライターフィーチャータイププロパティ設定の文脈では使用されなくなります。しかし、その機能自体は廃止されていません。
その機能は、フィーチャータイプ名フィールドに属性を設定することによって使うことができます。
In FME 2015.1, you can set destination feature type name by one of these ways.
(1) Enter a string (static feature type name) to the field directly.
(2) Select an attribute (equivalent to the old "Fanout By Attribute").
(3) Enter a string with the Text Editor.
(4) Select a user parameter (equivalent to entering "$(parameter name)" to the field directly).
FME 2015.1では、これらの方法のどれかひとつによって出力先フィーチャータイプ名を設定できます。
(1) フィールドに直接文字列（静的なフィーチャータイプ名）を入力する。
(2) 属性を選択する（以前の"Fanout By Attribute"と同等）。
(3) テキストエディタを使って文字列を入力する。
(4) ユーザーパラメータを選択する（フィールドに"$(パラメーター名）"を直接入力するのと同等）。
(1), (2), (4) have been also available in the previous version, but (3) is new and interesting. You can perform a string operation here and use the result as the destination feature type name.
(1), (2), (4)は以前のバージョンでも可能でしたが、(3)は新しく、興味深い。ここでなんらかの文字列操作を実行し、その結果を出力先フィーチャータイプ名として使うことができます。
Example:
See also this article.
この記事も参照してください。
The Safe Software Blog > The Feature Types They Are a-Changin’
FME 2015.1 build 15479
In FME 2015.1, the "Fanout By Attribute" doesn't appear in writer feature type properties dialog. The Feature Type Fanout has been retired?
FME 2015.1では、ライターフィーチャータイププロパティ設定画面で"Fanout By Attribute"が表示されません。フィーチャータイプ・ファンアウトは廃止された？
FME 2015.0 build 15253
FME 2015.1 build 15479
The answer is also "Yes", and can also be "No".
答えは「はい」でもあり、「いいえ」でもあり得ます。
Yes, the term "Feature Type Fanout" will be deprecated in the context of setting a writer feature type properties. But the functionality itself has not been deprecated.
You can use the functionality through setting an attribute to the feature type name field.
はい。「フィーチャータイプ・ファンアウト」という用語は、ライターフィーチャータイププロパティ設定の文脈では使用されなくなります。しかし、その機能自体は廃止されていません。
その機能は、フィーチャータイプ名フィールドに属性を設定することによって使うことができます。
In FME 2015.1, you can set destination feature type name by one of these ways.
(1) Enter a string (static feature type name) to the field directly.
(2) Select an attribute (equivalent to the old "Fanout By Attribute").
(3) Enter a string with the Text Editor.
(4) Select a user parameter (equivalent to entering "$(parameter name)" to the field directly).
FME 2015.1では、これらの方法のどれかひとつによって出力先フィーチャータイプ名を設定できます。
(1) フィールドに直接文字列（静的なフィーチャータイプ名）を入力する。
(2) 属性を選択する（以前の"Fanout By Attribute"と同等）。
(3) テキストエディタを使って文字列を入力する。
(4) ユーザーパラメータを選択する（フィールドに"$(パラメーター名）"を直接入力するのと同等）。
(1), (2), (4) have been also available in the previous version, but (3) is new and interesting. You can perform a string operation here and use the result as the destination feature type name.
(1), (2), (4)は以前のバージョンでも可能でしたが、(3)は新しく、興味深い。ここでなんらかの文字列操作を実行し、その結果を出力先フィーチャータイプ名として使うことができます。
Example:
See also this article.
この記事も参照してください。
The Safe Software Blog > The Feature Types They Are a-Changin’
FME 2015.1 build 15479
2015-05-02
AttributeCreator Advanced Attribute Value Handling
AttributeCreatorの高度な属性値処理
The "Multiple Feature Attribute Support" of the AttributeCreator was introduced in FME 2013 SP2, we have been receiving big benefit from that.
The functionality had been called the same name until 2014, maybe the only change during the period would be that the "null support" was added in FME 2014.
AttributeCreatorの"Multiple Feature Attribute Support"（複数フィーチャーの属性サポート）はFME 2013 SP2で導入され、私たちは大きな恩恵を受けてきました。
この機能は2014年までは同じ名前で呼ばれており、おそらく、その間の唯一の変更は、FME 2014で「ナル値のサポート」が追加されたことでしょう。
In FME 2015.0, the functionality itself was not changed basically, although the parameters group name has been changed to "Advanced: Prior/Subsequent Feature Attribute Retrieval".
FME 2015.0では、パラメーターグループ名が"Advanced: Prior/Subsequent Feature Attribute Retrieval"に変わりましたが、基本的には機能そのものに変化はありませんでした。
But there have been a big change in FME 2015.1.
しかし、FME 2015.1で大きな変化がありました。
That is, the "Substitute Missing, Null and Empty by" parameter (called "If Attribute is Missing, Null, or Empty" in the previous version) is now independent from the functionality for accessing prior/subsequent feature attributes.
それは、"Substitue Missing, Null and Empty by"パラメーター（以前は"If Attribute is Missing, Null, or Empty"と呼ばれていた）が、前後のフィーチャー属性にアクセスする機能から独立したことです。
What we can do with that?
これで何ができます？
Maybe a typical use case would be to replace an null, missing or empty attribute with a specific value (Default Value). For example, this setting is effective when you need to treat null or missing as 0 in a math expression.
おそらく典型的なユースケースは、ナル、欠落、空文字列属性をある特定の値（Default Value）に置き換えることでしょう。例えばこの設定は、数式においてナルや欠落を0とみなす必要があるときに効果的です。
It doesn't stand out, but is a wouderful improvement.
目立たないけれども素晴らしい改良です。
FME 2015.1 build 15479
The "Multiple Feature Attribute Support" of the AttributeCreator was introduced in FME 2013 SP2, we have been receiving big benefit from that.
The functionality had been called the same name until 2014, maybe the only change during the period would be that the "null support" was added in FME 2014.
AttributeCreatorの"Multiple Feature Attribute Support"（複数フィーチャーの属性サポート）はFME 2013 SP2で導入され、私たちは大きな恩恵を受けてきました。
この機能は2014年までは同じ名前で呼ばれており、おそらく、その間の唯一の変更は、FME 2014で「ナル値のサポート」が追加されたことでしょう。
In FME 2015.0, the functionality itself was not changed basically, although the parameters group name has been changed to "Advanced: Prior/Subsequent Feature Attribute Retrieval".
FME 2015.0では、パラメーターグループ名が"Advanced: Prior/Subsequent Feature Attribute Retrieval"に変わりましたが、基本的には機能そのものに変化はありませんでした。
But there have been a big change in FME 2015.1.
しかし、FME 2015.1で大きな変化がありました。
That is, the "Substitute Missing, Null and Empty by" parameter (called "If Attribute is Missing, Null, or Empty" in the previous version) is now independent from the functionality for accessing prior/subsequent feature attributes.
それは、"Substitue Missing, Null and Empty by"パラメーター（以前は"If Attribute is Missing, Null, or Empty"と呼ばれていた）が、前後のフィーチャー属性にアクセスする機能から独立したことです。
What we can do with that?
これで何ができます？
Maybe a typical use case would be to replace an null, missing or empty attribute with a specific value (Default Value). For example, this setting is effective when you need to treat null or missing as 0 in a math expression.
おそらく典型的なユースケースは、ナル、欠落、空文字列属性をある特定の値（Default Value）に置き換えることでしょう。例えばこの設定は、数式においてナルや欠落を0とみなす必要があるときに効果的です。
It doesn't stand out, but is a wouderful improvement.
目立たないけれども素晴らしい改良です。
FME 2015.1 build 15479
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.
=====
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から最初に出力されるので、それを直接ダイナミックライターに送ることができます。ライターはそれに基づいて出力先のスキーマを構成できます。
下記修正。
=====
(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.
(3) FeatureMergerでスキーマフィーチャーをデータフィーチャーに結合する。
Requestor (データフィーチャー) fme_feature_type
Supplier (スキーマフィーチャー) fme_feature_type_name
(4) (3) スキーマフィーチャーとデータフィーチャーを両方ともダイナミックスキーマモードのFILEGDBライターに送る。"Schema Sources"パラメーターは"Schema from first feature"（フィーチャータイプごとに最初のフィーチャーのスキーマを使用する）に設定してください。
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.
この構造は Schema (Any Format) リーダーで読み込まれるスキーマフィーチャーと同じなので、次の記事で説明されている方法を応用してダイナミックスキーマを構成するのに使用できます。
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.
FME 2015.1のFeatureReaderでは、次のアプローチが可能です。
(1) Directory and File Pathnames リーダーで全てのShapeファイルパス(*.shp)を取得する。
(2) それらをFeatureReaderに送り、"Dataset"パラメータで"path_windows"または"path_unix"属性を選択する。
2015-05-23
Deprecated the left image.
左の図は廃止しました。
Deprecated the left image.
左の図は廃止しました。
There are some changes regarding Feature Types in FME 2015.1. See also this article.
FME 2015.1ではフィーチャータイプに関していくつかの変更があります。次の記事も参照してください。
FME 2015.1 build 15479