2015-08-05
2015-05-17
Recently Published FME Store Transformers
最近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
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-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では、内部での属性データの取り扱いについて大きな変更があったと推測しますが、データ型についての現在のルールは不明です。
もしその章が更新されて復活したならば明確になるのかも知れませんが。
Subscribe to:
Posts (Atom)