ダイナミック・ワークフロー チュートリアル発見！
Although the Dynamic Schema is a frequently used functionality in practical workspaces, I had felt that technical materials about that were too few.
ダイナミック・スキーマは実用的なワークスペースでしばしば使われる機能ですが、それに関する技術資料が少なすぎると感じていました。
However, when I was surfing on the Knowledge Base today, by chance I found that the related documentations have been updated and enhanced wonderfully in this summer.
しかし今日、ナレッジ・ベースをながめていた時にたまたま、この夏に関連のドキュメントが更新され、素晴らしく強化されていることを見つけました。
I would recommend you to start to learn about the Dynamic Schema from this page.
ダイナミック・スキーマについて次のページから学びはじめることをお勧めします。
> Dynamic Workflow Tutorial: Introduction
2014-10-16
2014-10-13
010 < 9 is True or False?
010 < 9 は真か偽か？
The answer depends on the context.
In some cases, a string which consists of digits beginning with zero will be interpreted as an octal number (010 is equal to 8 in decimal number). But there also be cases where a digit string will be always interpreted as a decimal number, i.e. leading zero(s) will be ignored.
その答はコンテキストに依存します。
ある場合は、数字からなる文字列で先頭がゼロのものは八進数として解釈されますが（010は十進数の8に等しい）、常に十進数として解釈される（つまり、先頭部のゼロが無視される）場合もあります。
=====
2014-12-09: I heard that the numeric interpretation will be changed in FME 2015. That is, new transformer instances in FME 2015 always attempts to interpret a numeric value as a decimal number even if its representation begins with zero.
Note that this article is true for FME 2014 and earlier, but will not be true for FME 2015+.
2014-12-09: FME 2015では数値の解釈に変更があると聞きました。つまり、FME 2015の新しいトランスフォーマーインスタンスは、ゼロから始まっていたとしても常に十進数として解釈しようとします。
この記事はFME 2014以前には当てはまりますが、FME 2015以降には当てはまらないことに注意してください。
=====
Arithmetic Expressions 数式
In an arithmetic expression that is evaluated by @Evaluate function, "010" will be interpreted as an octal number; the value is treated as 8 in decimal number. But if the representation is "010.0" - having decimal fraction, the value is treated as 10.0 in decimal number even though it begins with zero(s).
@Evaluate関数で評価される数式においては、"010"は八進数として解釈され、十進数での値8として扱われます。ただし、表現が"010.0"である（小数部がある）場合は、ゼロから始まっていたとしても十進数での値10.0として扱われます。
Check resultant values generated by the AttributeCreator with the following settings.
- n1 will store "010" (the representation was assigned as-is),
- n2 will store "8" (evaluated as an octal number),
- n3 will store "10.0" (evaluated as a decimal number), after the processing.
次の設定で AttributeCreator が生成する結果を確認してください。処理後、
- n1 は"010"（文字列表現がそのまま割り当てられた）、
- n2 は"8"（八進数として評価された）、
- n3 は"10.0"（十進数として評価された）を格納することになります。
Comparison in Test Clauses テスト句における比較
In a test clause (Automatic or Numeric Mode), the transformer attempts to interpret a string as a decimal number; ignores leading zero(s). For example, if an attribute named "src" contains "010", the Tester with this setting routes the feature to the Failed port (10 < 9 is false).
テスト句（AutomaticまたはNumericモード）では、トランスフォーマーは文字列を十進数として解釈しようとし、先頭部のゼロを無視します。例えば、"src"という名前の属性が"010"を格納している場合、次の設定をした Tester は、フィーチャーを Failed ポートに送ります (10 < 9 は偽)。
However, if the Left Value was an arithmetic expression which evaluate the attribute value, the feature goes to the Passed port, since "010" will be evaluated as an octal number (8 < 9 is true).
しかし、Left Value（左辺値）が属性値を評価する数式である場合は、"010"は八進数として評価されるため、フィーチャーは Passed ポートから出力されます (8 < 9 は真)。
Sorter transformer Sorter トランスフォーマー
The Sorter (Numeric mode) seems to always consider a numeric representation as a decimal number. This is a sorted result by numeric ascending.
Sorter（Numericモード）は、数値表現を常に十進数と見なすようです。これは数値の昇順でソートした結果です。
I sometimes come across a case where code numbers beginning with 0 should be treated as numeric values. In such a case, be aware that there are differences on the interpretation depending on the context.
ときどき、0から始まるコード番号を数値として扱わなければならないような場合がありますが、そのような場合、コンテキストに応じて値の解釈が異なることに注意しましょう。
The answer depends on the context.
In some cases, a string which consists of digits beginning with zero will be interpreted as an octal number (010 is equal to 8 in decimal number). But there also be cases where a digit string will be always interpreted as a decimal number, i.e. leading zero(s) will be ignored.
その答はコンテキストに依存します。
ある場合は、数字からなる文字列で先頭がゼロのものは八進数として解釈されますが（010は十進数の8に等しい）、常に十進数として解釈される（つまり、先頭部のゼロが無視される）場合もあります。
=====
2014-12-09: I heard that the numeric interpretation will be changed in FME 2015. That is, new transformer instances in FME 2015 always attempts to interpret a numeric value as a decimal number even if its representation begins with zero.
Note that this article is true for FME 2014 and earlier, but will not be true for FME 2015+.
2014-12-09: FME 2015では数値の解釈に変更があると聞きました。つまり、FME 2015の新しいトランスフォーマーインスタンスは、ゼロから始まっていたとしても常に十進数として解釈しようとします。
この記事はFME 2014以前には当てはまりますが、FME 2015以降には当てはまらないことに注意してください。
=====
Arithmetic Expressions 数式
In an arithmetic expression that is evaluated by @Evaluate function, "010" will be interpreted as an octal number; the value is treated as 8 in decimal number. But if the representation is "010.0" - having decimal fraction, the value is treated as 10.0 in decimal number even though it begins with zero(s).
@Evaluate関数で評価される数式においては、"010"は八進数として解釈され、十進数での値8として扱われます。ただし、表現が"010.0"である（小数部がある）場合は、ゼロから始まっていたとしても十進数での値10.0として扱われます。
- n1 will store "010" (the representation was assigned as-is),
- n2 will store "8" (evaluated as an octal number),
- n3 will store "10.0" (evaluated as a decimal number), after the processing.
次の設定で AttributeCreator が生成する結果を確認してください。処理後、
- n1 は"010"（文字列表現がそのまま割り当てられた）、
- n2 は"8"（八進数として評価された）、
- n3 は"10.0"（十進数として評価された）を格納することになります。
Comparison in Test Clauses テスト句における比較
In a test clause (Automatic or Numeric Mode), the transformer attempts to interpret a string as a decimal number; ignores leading zero(s). For example, if an attribute named "src" contains "010", the Tester with this setting routes the feature to the Failed port (10 < 9 is false).
テスト句（AutomaticまたはNumericモード）では、トランスフォーマーは文字列を十進数として解釈しようとし、先頭部のゼロを無視します。例えば、"src"という名前の属性が"010"を格納している場合、次の設定をした Tester は、フィーチャーを Failed ポートに送ります (10 < 9 は偽)。
However, if the Left Value was an arithmetic expression which evaluate the attribute value, the feature goes to the Passed port, since "010" will be evaluated as an octal number (8 < 9 is true).
しかし、Left Value（左辺値）が属性値を評価する数式である場合は、"010"は八進数として評価されるため、フィーチャーは Passed ポートから出力されます (8 < 9 は真)。
Sorter transformer Sorter トランスフォーマー
The Sorter (Numeric mode) seems to always consider a numeric representation as a decimal number. This is a sorted result by numeric ascending.
Sorter（Numericモード）は、数値表現を常に十進数と見なすようです。これは数値の昇順でソートした結果です。
I sometimes come across a case where code numbers beginning with 0 should be treated as numeric values. In such a case, be aware that there are differences on the interpretation depending on the context.
ときどき、0から始まるコード番号を数値として扱わなければならないような場合がありますが、そのような場合、コンテキストに応じて値の解釈が異なることに注意しましょう。
2014-10-12
Cases where Null and Missing are considered as Empty String
Null（ナル値）、Missing（属性の欠落）が Empty String（空文字列）と見なされるケース
As you know, Null has been introduced in FME 2014. It has brought some big benefits to us.
In FME 2014+, many transformers can distinguish Null, Missing, and Empty String strictly.
On the other hand, there also are several cases where Null and Missing are considered as Empty String.
ご存じの通りFME 2014ではNull（ナル値）が導入され、大いに役立っています。
FME 2014以降では、多くのトランスフォーマーはNull, Missing（属性の欠落）及びEmpty String（空文字列） を厳密に区別することができますが、一方では、Null, Missingが空文字列とみなされるケースもあります。
A typical case is the = operator in a test condition setting for a transformer.
For example, the Tester with this setting sends a feature which stores Null as "attr" or doesn't have the "attr", to the Passed port.
It doesn't distinguish both Null and Missing from Empty String.
テスト条件における = 演算子は典型的なケースです。
例えば、次のような設定をしたTesterは、属性"attr"にNullを保持する、あるいは、"attr"を持たないフィーチャーをPassedポートから出力します。つまり、NullやMissingを空文字列と区別しません。
=====
2014-10-14: Some users may feel this behavior strange, but I think it's reasonable as a general manner in FME processing. Dale@Safe added some explanations about the basic concept and the background. See also his comment.
この振る舞いを奇妙に思う方もいらっしゃるかも知れませんが、私は、FMEの処理における一般的な方法として合理的であると思います。Safe社のデールさんが基本的な考え方と背景について説明を加えてくださいました。彼のコメントも参照してください。
=====
If you need to test whether the attribute value is Null or the attribute is Missing, you should use "Attribute Is Null" and "Attribute Is Missing" operators, like this.
属性値がNullであるかどうか、あるいは、属性が欠落しているかどうかを調べる必要がある場合は、次のように Attribute Is Null 演算子や Attribute Is Missing 演算子を使う必要があります。
As well, the Group By parameter does not distinguish them.
If you set an attribute to Group By parameter of a transformer, the transformer will configure one group for every feature which holds Null or Empty String as the attribute, or doesn't have the attribute (i.e. Missing).
There may be some users who feel such a behavior strange. However, it seems to be related to the fundamental mechanism regarding parameters, so I don't think it will change in the future.
* See also the following Note (2014-12-09).
同様に、Group Byパラメーターにおいてもそれらは区別されません。
Group Byパラメーターにある属性が設定されたトランスフォーマーは、その属性にナル値または空文字列を格納する、あるいは、その属性を持たない全てのフィーチャーをひとつのグループとして取り扱います。この振る舞いを奇妙に感じるユーザーもいるかも知れませんが、これはパラメーターの基本的なメカニズムに関係しているようであり、今後もこれが変わることはないと思います。
* 次の注(2014-12-09)もご覧ください。
=====
Note (2014-12-09): Got a great information. I heard that Safe is going to improve the behavior of Group By concerning Null, Missing, and Empty. Now, I update the last paragraph above to:
"Although it seems to be related to the fundamental mechanism regarding parameters, it might be improved in the future."
注 (2014-12-09): 素晴らしい情報を得ました。Safe社は、Null, Missing, 空文字列に関するGroup Byの振る舞いについて改良する予定であるとのことです。上の最後の段落を次のように更新します。
「これはパラメーターの基本的なメカニズムに関係しているようですが、将来は改良される可能性があります。」
=====
Well, how can you make groups separately for Null, Missing, and Empty String?
A possible way I can think of is to assign special values to identify "Null" and "Missing" with the NullAttributeMapper before grouping.
Of course the special values must not be equal to any other possible values for the attribute, but it's not so difficult in many cases, I think.
では、Null、Missing、Empty Stringを区別してグループ化するにはどうすれば良いでしょう？
考えられる方法は、グループ化する前に NullAttributeMapper を使ってNull, Missingを識別するための特別な値を割り当てることです。もちろんその特別な値は、その属性の値として可能な全ての他の値と異ならなければなりませんが、多くの場合、それはそんなに難しいことではないと思います。
Anyway, we need to know that there are cases where Null and Missing are considered as Empty String.
ともあれ、Null, Missing が空文字列として扱われるケースがあることは知っておく必要があります。
As you know, Null has been introduced in FME 2014. It has brought some big benefits to us.
In FME 2014+, many transformers can distinguish Null, Missing, and Empty String strictly.
On the other hand, there also are several cases where Null and Missing are considered as Empty String.
ご存じの通りFME 2014ではNull（ナル値）が導入され、大いに役立っています。
FME 2014以降では、多くのトランスフォーマーはNull, Missing（属性の欠落）及びEmpty String（空文字列） を厳密に区別することができますが、一方では、Null, Missingが空文字列とみなされるケースもあります。
A typical case is the = operator in a test condition setting for a transformer.
For example, the Tester with this setting sends a feature which stores Null as "attr" or doesn't have the "attr", to the Passed port.
It doesn't distinguish both Null and Missing from Empty String.
テスト条件における = 演算子は典型的なケースです。
例えば、次のような設定をしたTesterは、属性"attr"にNullを保持する、あるいは、"attr"を持たないフィーチャーをPassedポートから出力します。つまり、NullやMissingを空文字列と区別しません。
=====
2014-10-14: Some users may feel this behavior strange, but I think it's reasonable as a general manner in FME processing. Dale@Safe added some explanations about the basic concept and the background. See also his comment.
この振る舞いを奇妙に思う方もいらっしゃるかも知れませんが、私は、FMEの処理における一般的な方法として合理的であると思います。Safe社のデールさんが基本的な考え方と背景について説明を加えてくださいました。彼のコメントも参照してください。
=====
If you need to test whether the attribute value is Null or the attribute is Missing, you should use "Attribute Is Null" and "Attribute Is Missing" operators, like this.
属性値がNullであるかどうか、あるいは、属性が欠落しているかどうかを調べる必要がある場合は、次のように Attribute Is Null 演算子や Attribute Is Missing 演算子を使う必要があります。
As well, the Group By parameter does not distinguish them.
If you set an attribute to Group By parameter of a transformer, the transformer will configure one group for every feature which holds Null or Empty String as the attribute, or doesn't have the attribute (i.e. Missing).
There may be some users who feel such a behavior strange. However, it seems to be related to the fundamental mechanism regarding parameters, so I don't think it will change in the future.
* See also the following Note (2014-12-09).
同様に、Group Byパラメーターにおいてもそれらは区別されません。
Group Byパラメーターにある属性が設定されたトランスフォーマーは、その属性にナル値または空文字列を格納する、あるいは、その属性を持たない全てのフィーチャーをひとつのグループとして取り扱います。この振る舞いを奇妙に感じるユーザーもいるかも知れませんが、これはパラメーターの基本的なメカニズムに関係しているようであり、今後もこれが変わることはないと思います。
* 次の注(2014-12-09)もご覧ください。
=====
Note (2014-12-09): Got a great information. I heard that Safe is going to improve the behavior of Group By concerning Null, Missing, and Empty. Now, I update the last paragraph above to:
"Although it seems to be related to the fundamental mechanism regarding parameters, it might be improved in the future."
注 (2014-12-09): 素晴らしい情報を得ました。Safe社は、Null, Missing, 空文字列に関するGroup Byの振る舞いについて改良する予定であるとのことです。上の最後の段落を次のように更新します。
「これはパラメーターの基本的なメカニズムに関係しているようですが、将来は改良される可能性があります。」
=====
Well, how can you make groups separately for Null, Missing, and Empty String?
A possible way I can think of is to assign special values to identify "Null" and "Missing" with the NullAttributeMapper before grouping.
Of course the special values must not be equal to any other possible values for the attribute, but it's not so difficult in many cases, I think.
では、Null、Missing、Empty Stringを区別してグループ化するにはどうすれば良いでしょう？
考えられる方法は、グループ化する前に NullAttributeMapper を使ってNull, Missingを識別するための特別な値を割り当てることです。もちろんその特別な値は、その属性の値として可能な全ての他の値と異ならなければなりませんが、多くの場合、それはそんなに難しいことではないと思います。
Anyway, we need to know that there are cases where Null and Missing are considered as Empty String.
ともあれ、Null, Missing が空文字列として扱われるケースがあることは知っておく必要があります。
2014-10-08
Recent New Transformers for FME Store
FME Store における新作トランスフォーマー
Naturally, all is free to use. If you found an issue in these, please contact me.
もちろん全て無料で自由に使えます。何か問題を見つけたときはお知らせください。
Transformer Gallery / FME Store / Pragmatica
2DVectorCalculator
Calculates (x, y) components of a 2D vector defined by the parameter settings, and stores them as new attributes. Optionally this transformer replaces feature geometry with a line segment representing the resulting vector.
Since it can also calculate a normal vector, may be useful to create a perpendicular line against the original geometry.
The core processing is implemented with Tcl.
パラメータによって定義される二次元ベクトルのx成分とy成分を求め、新たな属性に格納します。また、オプションとして、フィーチャーのジオメトリを、求められたベクトルを表す線分と置き換えます。法線ベクトルも求められるので、元のジオメトリに対する垂線を作成するのに便利かも知れません。
主要な処理は Tcl で実装されています。
RankCalculator
Adds rank number to each feature as an attribute; the rank will be determined based on the descending or ascending order of numeric values stored by an attribute.
If every value is unique, the resulting ranks will be same as the count numbers which can be generated with a combination of Sorter and Counter. Otherwise - i.e. if two or more input features have same value, their ranks will become identical number.
The core processing is implemented with Python.
各フィーチャーに属性としてランク（ある属性に格納されている値の降順または昇順での順位）を与えます。全ての値が一意であれば、ランクは、Sorter と Counter の組み合わせで生成できるカウント値と同じですが、そうでない場合、つまり複数のフィーチャーが同じ値を持っている場合に、それらのランク（順位）は同じになります。
主要な処理は Python で実装されています。
StepSampler
Selects features by an identical interval from the incoming feature sequence.
This transformer is similar to the regular Sampler (Sampling Type: Every Nth Feature), but determines the sampling interval automatically based on the specified number of samples and the number of entire input features.
The core processing is implemented with Python.
入力フィーチャーのシーケンスから一定の間隔でフィーチャーを選択します。
このトランスフォーマーは標準の Sampler (Sampling Type: Every Nth Feature) と似ていますが、ランプリングの間隔は、指定したサンプル数と入力フィーチャー数に基づいて自動的に決定されます。
主要な処理はPythonで実装されています。
Naturally, all is free to use. If you found an issue in these, please contact me.
もちろん全て無料で自由に使えます。何か問題を見つけたときはお知らせください。
Transformer Gallery / FME Store / Pragmatica
Requirement: FME 2014 SP3+
2DVectorCalculator
Calculates (x, y) components of a 2D vector defined by the parameter settings, and stores them as new attributes. Optionally this transformer replaces feature geometry with a line segment representing the resulting vector.
Since it can also calculate a normal vector, may be useful to create a perpendicular line against the original geometry.
The core processing is implemented with Tcl.
パラメータによって定義される二次元ベクトルのx成分とy成分を求め、新たな属性に格納します。また、オプションとして、フィーチャーのジオメトリを、求められたベクトルを表す線分と置き換えます。法線ベクトルも求められるので、元のジオメトリに対する垂線を作成するのに便利かも知れません。
主要な処理は Tcl で実装されています。
RankCalculator
Adds rank number to each feature as an attribute; the rank will be determined based on the descending or ascending order of numeric values stored by an attribute.
If every value is unique, the resulting ranks will be same as the count numbers which can be generated with a combination of Sorter and Counter. Otherwise - i.e. if two or more input features have same value, their ranks will become identical number.
The core processing is implemented with Python.
各フィーチャーに属性としてランク（ある属性に格納されている値の降順または昇順での順位）を与えます。全ての値が一意であれば、ランクは、Sorter と Counter の組み合わせで生成できるカウント値と同じですが、そうでない場合、つまり複数のフィーチャーが同じ値を持っている場合に、それらのランク（順位）は同じになります。
主要な処理は Python で実装されています。
StepSampler
Selects features by an identical interval from the incoming feature sequence.
This transformer is similar to the regular Sampler (Sampling Type: Every Nth Feature), but determines the sampling interval automatically based on the specified number of samples and the number of entire input features.
The core processing is implemented with Python.
入力フィーチャーのシーケンスから一定の間隔でフィーチャーを選択します。
このトランスフォーマーは標準の Sampler (Sampling Type: Every Nth Feature) と似ていますが、ランプリングの間隔は、指定したサンプル数と入力フィーチャー数に基づいて自動的に決定されます。
主要な処理はPythonで実装されています。
2014-10-02
ZIP Archive and Dataset Fanout
ZIPアーカイブと Dataset Fanout (データセット・ファンアウト)
FME 2014 SP3 build 14391
There are many files in a directory; the files are grouped by the prefix of those names.
たくさんのファイルがひとつのディレクトリ内にあり、それらはファイル名のプレフィクスによってグループ分けされています。
-----
a_01.ext, a_02.ext, a_03.ext, ...
b_01.ext, b_02.ext, b_03.ext, ...
c_01.ext, c_02.ext, c_03.ext, ...
and so on.
I needed to archive them with zip-compression for each group. The required output is:
それらを次のように、グループごとにzip圧縮、アーカイブする必要がありました。
-----
a.zip, b.zip, c.zip ...
At first, I thought it can be realized easily with the Directory and File Pathnames reader [PATH], some Transformers, and the File Copy writer [FILECOPY] with Dataset Fanout, like this.
はじめは、次のように Directory and File Pathnames リーダー [PATH]、いくつかのトランスフォーマー、および、データセット・ファンアウトを使用した File Copy ライター [FILCOPY] によって簡単に実現できるだろうと考えました。
The workspace was able to compress the source files, but didn't fanout. Just one zip file which has archived every file was created as the result. This may be a limitation of the current FME.
このワークスペースはソースファイルを圧縮することはできましたが、ファンアウトはしませんでした。全てのファイルをアーカイブしたひとつのzipファイルが作成されただけです。これはおそらく、現在のFMEにおける制約でしょう。
=====
2014-10-11: I found this description in FME Workbench documentation.
"Note: You cannot create multiple zip files using Dataset Fanout (therefore, you cannot set the Fanout Suffix parameter to .zip)."
Yes, that's indeed a limitation of the current FME.
FME Woekbench のドキュメントで次のような説明をみつけました。
「注: データセット・ファンアウトを使用して複数のzipファイルを作成することはできません（したがって Fanout Suffix パラメーターに .zip を設定することはできません）」
そうです。確かに現在のFMEにおける制約でした。
=====
2015-11-24: FME 2016.0 beta build 16133
In FME 2016, the ability to create multiple zip files will be added to the Dataset Fanout. See here.
FME 2016 では、データセットファンアウトに複数の zip ファイルを作成する機能が追加されます。ここを参照してください。
=====
The first approach failed, unfortunately.
But don't give up. The WorkspaceRunner would be a workaround in the interim.
最初のアプローチは残念ながら失敗でした。
しかし、あきらめることはありません。WorkspaceRunner が当面の回避策になります。
The main workspace is simple. It just copies every file to a directory from the source directory. The only point is that it publishes the "Path Filter" parameter of the PATH reader.
メインワークスペースは単純で、全てのファイルをソースディレクトリから他のディレクトリにコピーするだけです。唯一のポイントは、PATH リーダーの"Path Filter"パラメーターを公開していることです。
Then, create another workspace with a WorkspaceRunner to run the main workspace for each prefix. The data flow contains these transformers.
1) AttributeSplitter, AttributeRenamer: extract prefix from every file name, store it as attribute named "_prefix". The renaming is not essential since "_list{0}" can be used instead of "_prefix".
2) DuplicateRemover: remove duplicate prefixes.
3) StringConcatenator: create a preferable zip file path string based on the specified output directory path and the extracted prefix. i.e. "<directory path>\<prefix>.zip"
そして、そのメインワークスペースをプレフィクスごとに実行するために、WorkspaceRunner を含むもうひとつのワークスペースを作成します。データフローには以下のトランスフォーマーが含まれます。
1) AttributeSplitter, AttributeRenamer: 全てのファイル名からプレフィクスを抽出し、"_prefix"という属性に格納します。"_list{0}"が"_prefix"の代わりに使えるので属性名の変更は必須ではありません。
2) DuplicateRemover: 重複したプレフィクスを削除します。
3) StringConcatenator: 出力先のディレクトリパスと抽出されたプレフィクスに基づいて、適切なzipファイルパス"<directory path>\<prefix>.zip"を作成します。
Finally, pass the source directory path, a path filter (i.e. "<prefix>_*"), and the zip file path to the main workspace through the WorkspaceRunner.
最後に、WorkspaceRunner 経由でソースディレクトリのパス、パス・フィルター（"<prefix>_*"）、および zipファイルパスをメインワークスペースに渡します。
It worked fine as expected. But I believe that the first approach - the Dataset Fanout will be available in the near future.
これは期待した通りに動作しました。しかし、最初のアプローチ - データセット・ファンアウトも、近い将来には利用可能になると思います。
=====
2015-11-24: FME 2016.0 beta build 16133
In FME 2016, you can create multiple zip files using Dataset Fanout. See here.
FME 2016 では、データセットファンアウトで複数の zip ファイルが作成できます。ここを参照してください。
=====
FME 2014 SP3 build 14391
There are many files in a directory; the files are grouped by the prefix of those names.
たくさんのファイルがひとつのディレクトリ内にあり、それらはファイル名のプレフィクスによってグループ分けされています。
-----
a_01.ext, a_02.ext, a_03.ext, ...
b_01.ext, b_02.ext, b_03.ext, ...
c_01.ext, c_02.ext, c_03.ext, ...
and so on.
I needed to archive them with zip-compression for each group. The required output is:
それらを次のように、グループごとにzip圧縮、アーカイブする必要がありました。
-----
a.zip, b.zip, c.zip ...
At first, I thought it can be realized easily with the Directory and File Pathnames reader [PATH], some Transformers, and the File Copy writer [FILECOPY] with Dataset Fanout, like this.
はじめは、次のように Directory and File Pathnames リーダー [PATH]、いくつかのトランスフォーマー、および、データセット・ファンアウトを使用した File Copy ライター [FILCOPY] によって簡単に実現できるだろうと考えました。
The workspace was able to compress the source files, but didn't fanout. Just one zip file which has archived every file was created as the result. This may be a limitation of the current FME.
このワークスペースはソースファイルを圧縮することはできましたが、ファンアウトはしませんでした。全てのファイルをアーカイブしたひとつのzipファイルが作成されただけです。これはおそらく、現在のFMEにおける制約でしょう。
=====
2014-10-11: I found this description in FME Workbench documentation.
"Note: You cannot create multiple zip files using Dataset Fanout (therefore, you cannot set the Fanout Suffix parameter to .zip)."
Yes, that's indeed a limitation of the current FME.
FME Woekbench のドキュメントで次のような説明をみつけました。
「注: データセット・ファンアウトを使用して複数のzipファイルを作成することはできません（したがって Fanout Suffix パラメーターに .zip を設定することはできません）」
そうです。確かに現在のFMEにおける制約でした。
=====
2015-11-24: FME 2016.0 beta build 16133
In FME 2016, the ability to create multiple zip files will be added to the Dataset Fanout. See here.
FME 2016 では、データセットファンアウトに複数の zip ファイルを作成する機能が追加されます。ここを参照してください。
=====
The first approach failed, unfortunately.
But don't give up. The WorkspaceRunner would be a workaround in the interim.
最初のアプローチは残念ながら失敗でした。
しかし、あきらめることはありません。WorkspaceRunner が当面の回避策になります。
The main workspace is simple. It just copies every file to a directory from the source directory. The only point is that it publishes the "Path Filter" parameter of the PATH reader.
メインワークスペースは単純で、全てのファイルをソースディレクトリから他のディレクトリにコピーするだけです。唯一のポイントは、PATH リーダーの"Path Filter"パラメーターを公開していることです。
Then, create another workspace with a WorkspaceRunner to run the main workspace for each prefix. The data flow contains these transformers.
1) AttributeSplitter, AttributeRenamer: extract prefix from every file name, store it as attribute named "_prefix". The renaming is not essential since "_list{0}" can be used instead of "_prefix".
2) DuplicateRemover: remove duplicate prefixes.
3) StringConcatenator: create a preferable zip file path string based on the specified output directory path and the extracted prefix. i.e. "<directory path>\<prefix>.zip"
そして、そのメインワークスペースをプレフィクスごとに実行するために、WorkspaceRunner を含むもうひとつのワークスペースを作成します。データフローには以下のトランスフォーマーが含まれます。
1) AttributeSplitter, AttributeRenamer: 全てのファイル名からプレフィクスを抽出し、"_prefix"という属性に格納します。"_list{0}"が"_prefix"の代わりに使えるので属性名の変更は必須ではありません。
2) DuplicateRemover: 重複したプレフィクスを削除します。
3) StringConcatenator: 出力先のディレクトリパスと抽出されたプレフィクスに基づいて、適切なzipファイルパス"<directory path>\<prefix>.zip"を作成します。
Finally, pass the source directory path, a path filter (i.e. "<prefix>_*"), and the zip file path to the main workspace through the WorkspaceRunner.
最後に、WorkspaceRunner 経由でソースディレクトリのパス、パス・フィルター（"<prefix>_*"）、および zipファイルパスをメインワークスペースに渡します。
It worked fine as expected. But I believe that the first approach - the Dataset Fanout will be available in the near future.
これは期待した通りに動作しました。しかし、最初のアプローチ - データセット・ファンアウトも、近い将来には利用可能になると思います。
=====
2015-11-24: FME 2016.0 beta build 16133
In FME 2016, you can create multiple zip files using Dataset Fanout. See here.
FME 2016 では、データセットファンアウトで複数の zip ファイルが作成できます。ここを参照してください。
=====
Subscribe to:
Posts (Atom)