The mesh system is a national standard of Japan. It's used frequently in various geographic data processing scenarios, I often translate mesh codes to geometries with FME workspace.
The following workflow example creates a rectangular polygon representing a mesh area based on the mesh code. Assume every input feature has a primary, secondary or tertiary mesh code as its attribute named "_mesh_code".

Bookmark 1
The three StringSearchers validate format of the mesh code and split it into code elements - AA BB [C D [E F]], the elements will be stored in a list attribute named "_mcode{}". Then, the AttributeCreator calculates mesh width and height depending on mesh type. Mesh type can be determined based on the number of code elements, i.e. a primary mesh has 2, a secondary mesh has 4 and a tertiary mesh has 6 elements.

Bookmark 2
The AttributeCreator calculates coordinate (latitude, longitude) of the mesh left-bottom corner based on the code elements. Here, the number of list elements from Bookmark 1 is variable - 2, 4, or 6. So I've used the NullAttributeMapper beforehand so that the number of elements would be 6 and also values of the ex-missing-elements would be 0. Thereby, the AttributeCreator can always calculate without any error.

The workflow above is a use case of the NullAttributeMapper. I think it can be also used in many cases other than handling <null>.
And I guess many countries have standards about geographic data. Hope the information will be exchanged through various channels.

====
2014-01-02: Number of StringSearchers (Bookmark 1) can be reduced to just only one with this regular expression.
-----
^([0-9]{2})([0-9]{2})(-?([0-7])([0-7])(-?([0-9])([0-9]))?)?$
-----
But in that case, since the number of list elements will be always 8, mesh type cannot be determined based on it. Other approach will be necessary instead of the ListElementCounter and the AttributeCreator. And, the NullAttributeMapper (Bookmark 2) settings should be:
- Map: Selected Attributes
- Selected Attributes: _mcode{3} _mcode{4} _mcode{6} _mcode{7}
- If Attribute Value Is: Empty
- Map To: New Value
- New Value: 0
=====

2013-12-23

Important, 2014-01-29: I heard that Safe is planning to change the implementation of Python API fmeobjects.FMEFeature.getAttribute() method, so that it returns an empty string when specified attribute stores <null>. Currently - FME 2014 build 14234 - it returns "None" in that case.
After confirming the change, I will revise related descriptions (underlined) in this article.
-----
2014-02-14: I noticed that the method in FME 2014 SP1 Beta (build 14255) returns an empty string for <null>. The change of implementation seems to be done for SP1.
-----
2014-02-25: The change about FME Objects Python API has been announced. I revised related descriptions in this article (underlined).

(FME 2014 Beta build 14223)

These Python API methods and Tcl procedures have been added in FME 2014 to handle <null> attributes appropriately.

New Python Methods

FMEFeature.getAttributeNullMissingAndType(attrName)

FMEFeature.setAttributeNullWithType(attrName, attrType)

New Tcl Procedures

FME_IsAttributeNull attrName

FME_SetAttributeNull attrName

I tried them to learn those functions and usage, this article summarizes the result. If there are wrong descriptions, please point them out.
Official descriptions on those methods / procedures can be seen in
- FME Objects Python API: [FME_HOME]/fmeobjects/python/apidoc/index.html
- FME pre-defined Tcl procedures: TclCaller transformer help documentation

1. Determine if an attribute contains <null>Python: FMEFeature.getAttributeNullMissingAndType MethodFME 2014 SP1+ (build 14252 or later):FMEFeature.getAttribute method returns an empty string when specified attribute is <null>.If it's necessary to distinguish <null> from empty string in the script, we have to use the getAttributeNullMissingAndType method (added in FME 2014).FME 2014 without SP*:FMEFeature.getAttribute method returns None when specified attribute is <null> or <missing>.If it's necessary to distinguish <null> from <missing> in the script, we have to use the getAttributeNullMissingAndType method (added in FME 2014).

3. Handle <null> elements in a list attribute
Python FMEFeature.getAttribute method returns a string list when an existing list attribute name (e.g. "_list{}") is specified to its argument. It's very convenient functionality to handle list attributes easily; I have often used it.
But now (in FME 2014+), we should be aware that every <null> element will be interpreted to empty string in that case.

If <null> elements in the source list have to be treated as <null> in the destination list too, the script should be like this. Assume there is no <missing> element in the source list.
-----
import fmeobjects
def copyList2(feature):
i = 0
while True:
isNull, isMissing, type = feature.getAttributeNullMissingAndType('_src{%d}' % i)
if isMissing:
break
if isNull:
feature.setAttributeNullWithType('_dest{%d}' % i, type)
else:
feature.setAttribute('_dest{%d}' % i, feature.getAttribute('_src{%d}' % i))
i += 1
-----

I think the difference between the results of "copyList1" and "copyList2" should be memorized.

Alternatively, if the number of list elements has been stored as an attribute (e.g. _element_count) beforehand, this script makes the same result. The number of list elements can be stored with the ListElementCounter transformer.

2014-01-29: If implementation of getAttribute changed, this script would not be able to determine whether the value is <null>. It would bring unexpected result.
I will remove the description and this script after confirming the change.
-----
2014-02-25: Removed.

2013-12-21

The Excel reader (XLSXR) creates default attribute names when the user doesn't specify "Field Names Row".
In FME 2013, those are formatted in "col_**" (** is 1-based sequential number), but the manner has been changed in FME 2014. The default attribute names will be equal to Excel column names, i.e. A, B, C, ...
Since many Excel users are familiar with the column names, this change would be welcomed. I also basically welcome it.

Now, I have several workspaces which have Excel readers. Since source Excel spread sheets don't have any available field names row, the workspaces rename old style default names (col_**) to appropriate names using the SchemaMapper. And I have created common schema definition tables for the SchemaMappers and Dynamic Schema writers.
The same way could be effective to new similar workspace which has to read Excel spread sheets without field names row.
In such a case, I want to use old style default attribute names. Because A, B, C, ... have to be typed manually when creating schema definition tables; it's not only troublesome but also easy to make typos. "col_**" can be input easily by drag copying on an Excel spread sheet.

As a workaround, I'm thinking of a processing with a PythonCaller which renames the Excel column names (A, B, C) to the old style default attribute names (col_**).
This script is a prototype, not tested enough.
-----
import fmeobjects, re

Important, 2014-02-05: I heard that Safe is planning to change the implementation of Python API fmeobjects.FMEFeature.getAttribute() method, so that it returns an empty string when specified attribute stores <null>. Currently - FME 2014 build 14234 - it returns "None" in that case.
After confirming the change, I will revise related descriptions (underlined) in this article.
-----
2014-02-14: I noticed that the method in FME 2014 SP1 Beta (build 14255) returns an empty string for <null>. The change of implementation seems to be done for SP1.
-----
2014-02-25: The change about FME Objects Python API has been announced. I revised related descriptions in this article (underlined).

2) When the schema of input features is the same (not vary), it's inefficient to create new attribute names for every input feature. But any feature may have missing attributes, so it's necessary to check all attribute names for every feature.

This is an improved version. Also a little more Pythonic? (FME 2014 Beta build 14223)
-----
import fmeobjects, re

=====
2103-12-23: The TclCaller can be also used. Since FME pre-defines FME_RenameAttribute procedure, it's not necessary to care about <null> and <missing> when renaming attributes.
-- Why doesn't Python API provide a method to rename attributes?
Anyway, this is a Tcl script example.
-----
set oldNames {}
set newNames {}

The NullAttributeMapper transformer has been added to FME 2014.
It can be used to convert between <null> and non-null; the functionality of the NullAttributeReplacer transformer in FME 2013 has been integrated to it.

This workspace example creates a feature having these attributes:
attrValue = NULL *string value. not <null>
attrNull = <null>
attrEmpty = <empty>
attrMissing = <missing>
Note: Saying strictly, the feature doesn't have "attrMissing" although it appears on the Canvas. The AttributeExposer exposes attribute names, but it doesn't create any real content of attributes.

The NullAttributeMapper with this setting replaces <null>, <empty> and <missing> with a non-null value - "NULL".

The conversion is reversible. This setting replaces an attribute value with <null> if the attribute holds "NULL" or <empty>, or is <missing>.

One of "Null", "Missing", "Empty String" and "New Value" can be specified to the replacement value, i.e. "Map To" parameter. If specifying "New Value", "New Value" parameter has to be specified.
Both "Or If Attribute Value Is" and "New Value" parameter can be also set as Attribute Value, String / Math Expression, Parameter or Conditional Value.

The NullAttributeMapper has enough functionality for converting between <null> and non-null. I think it would become one of the most frequently used transformers for workspaces performing <null> operation.

If regular expression could be used as the matching condition, it could become more powerful.

2013-12-19

FME 2014 starts supporting null as attribute values.
In my understanding, null is a special value, should be distinguished from both an empty string and a missing (not existing) attribute.

We can set null to an attribute using the AttributeCreator.

And the Tester can be used to test whether an attribute value is null. This test condition passes the input feature if "attrNull" holds null.

The Tester provides "Attribute Is Null", "Attribute Is Empty String" and "Attribute Is Missing" operators, and those can strictly determine whether the Left Value is null, empty string or missing.

Well, "attrEmpty" holds an empty string now. If I set the test condition like this, the feature goes to which port, Passed or Failed?

I thought the feature would go to the Failed port, but the result was not so. The feature goes to the Passed port. I got a little confused. How should I think of this result?
Null is a special value, but it could be treated as an empty string in some cases?

Have to continue to explore about the null.
=====
2013-12-20: I noticed that the feature goes to the Passed port even if "attrEmpty" is missing. null seems to be also treated as missing attribute in some cases. hmm...

2013-12-17

=====
2014-01-16: FME 2014 (build 14230) has been released.
Almost all the Japanese character problems has been solved. Wonderful!
This article ends up here. Thanks.
=====
2014-01-12: I'm happy that the remaining issue (PR#50788) has been fixed in build 14229 :-)
Release coming soon!
=====
2013-12-22: I tried FME 2014 Beta build 14223 for Mac OS X in Japanese environment.
It works fine. There were some problems related to Japanese characters in build 14205, but those have been solved now, and the workspace files (*.fmw) are compatible between Mac and Windows. Great.
=====
2013-12-19: FME 2014 Beta build 14220 works fine in Japanese Windows. Great!
I confirmed that all the problems I reported last week have been solved. Although garbled characters sometimes appear on Log window, those are not so serious issues for me. I believe that those will be also solved in the near future.
Many many thanks for Safe's efforts.
=====

Previous: Japanese character problem
I tried FME 2014 Beta build 14212 - 14218. The result, almost all the Japanese character problems occurring in FME 2013 or earlier have been solved. Wonderful!
Many thanks, Safe and the great developers.

However, found several new problems related to Japanese character unfortunately. I guess that some of them are side-effects caused by changing encoding of fmw file.
I've reported detailed situation to Safe via my reseller already, would appreciate some more efforts to solve them. Thanks in advance.

2013-12-15

From this thread. > Community: conditional execution of densifying
To simplify explanation, assume there are two feature types - e.g. TypeA and TypeB; TypeA features have to be processed only when one or more TypeB feature exists. In other words, it's not necessary to process TypeA features when there is no TypeB feature.

My first inspiration was to use unconditional merging like this image.
The Sampler and the AttributeKeeper are not essential but I think those are effective to prevent unnecessary processing in the FeatureMerger as much as possible.
About unconditional merging, see "Join On" Parameter of the FeatureMerger.

A PythonCaller followed by a FeatureTypeFilter would be also one of options.
-----
# Python Script Example
# Hold every features, output them only when a TypeB feature exists.
# If there is no TypeB feature, output a Signal feature.
import fmeobjects

Not only for this case, I think that various Transformers (maybe within Workflow category) for flow control can be considered.

Note: fmeobjects.FMEFeature class (FME Objects Python API) has "getFeatureType" and "setFeatureType" methods. I thought I can use them to get / set "fme_feature_type" attribute value (i.e. feature type name), but it is not always so in my testing. I couldn't confirm exact functions of those methods.

Note: There is one more list type - "nested list", but I don't touch it in this article.
=====
2013-12-18: "complex list" is also called "structured list" in other documentation."The function also accepts a "structured list" specification, such as "attrInfo{}.name", ..."
-- description about FMEFeature.getAttribute function, FME Objects Python API, [FME_HOME]/fmeobjects/python/apidoc/index.html (FME 2014 Beta build 14218)
=====

Well, there are two feature types named "foo" and "bar". Both of them have a simple list attribute named "_list{}", and also have a merging key attribute named "_key".
Assume that both "foo" and "bar" don't have list attributes other than "_list{}".

Consider merging those features. Merged features should have a complex list attribute which retains every element of the original list attributes from "foo" and "bar" features.
i.e.
_list{i} of "foo" should be converted to _list{i}.foo
_list{i} of "bar" should be converted to _list{i}.bar

I found the BulkAttributeRenamer can be used to do that (FME 2013 Build 13547).
This workflow does it. The functionality is similar to "zip" function of Python.

The "zip trick" with the BulkAttributeRenamer and the FeatureMerger flashed on this thread.

Although the SchemaMapper would be suitable in this case, I think there should be some cases that "zip trick" can be effective.

Moreover, I expect that the ListRenamer transformer will be upgraded to have new options for conversion between simple list and complex list.

=====
2013-12-17: A complex list (e.g. _list{}.foo) can be converted to a simple list (e.g. _list{}) using a BulkAttributeRenamer with this setting as well, for what it's worth.
-----
Rename: All Attributes
Action: Regular Expression Replace
Text to Find: }.foo$
String: }
-----
=====
2014-01-27: The BulkAttributeRenamer of FME 2014 (build 14234) also works for converting type of list with the way mentioned above. However, I noticed that the list name shown on the Canvas will not change, even though internal list name has been changed.
As a meantime workaround, the AttributeExposer can be used to expose the correct list name after renaming. But the original simple list name ("_list{}") cannot be hidden (:-(

=====
2014-01-28: I noticed the PythonCaller can be used to expose and hide list names. Just specify "Attributes to Expose" and "Lists to Hide" parameters. The script doesn't need to do any thing.
-----
def processFeature(feature):
# do nothing
pass
-----
Although it's a weird usage, can be effective.
Of course using the AttributeExposer or the PythonCaller is a temporary workaround. I expect the BulkAttributeRenamer will be fixed in the near future.

Followings are valid representation examples. An attribute value matched with one of these representations can be replaced with formatted date(time) string using the ＤａｔｅFormatter.
(tested in FME 2013 SP4 Build 13547)
-----
now
today
tomorrow
yesterday
last Sunday
next Sunday

Well, today is Friday 2013-12-13 (Friday the 13th!).
"last Sunday" was replaced with "2013-12-08", it's good.
"next Sunday" was "2013-12-22", but in Japanese, 「次の日曜日」 (means "next Sunday" by literal translation) usually points "2013-12-15". Is there any difference in culture?
中国朋友们，「下星期日」也是"2013-12-15"吧?

=====
2013-12-14: Mark gave me an answer to my last question. See his comment.
English I learned in junior high maybe was British. FME was born in Canada, the mother tongue would be North American English.
In the DateFormatter, just "Sunday" will be replaced with "2013-12-15".
Today is Saturday, 2013-12-14. I got the following results.
-----

Representation

Formatted

last Saturday

2013-12-07

last Sunday

2013-12-08

last Monday

2013-12-09

...

Saturday

2013-12-14

Sunday

2013-12-15

Monday

2013-12-16

...

next Saturday

2013-12-21

next Sunday

2013-12-22

next Monday

2013-12-23

-----
Probably I use those representations rarely in practical workspaces, but a rarer case should be treated more carefully. Anyway, we have to be aware it when making an appointment in North America.
Thanks, Mark.

2013-12-07

Through learning about the basic usage of Tcl in FME, I understand that Tcl is very useful for string processing. But, comparing with Python, I didn't think Tcl in FME has much capability for geometric operations. Really so?

Consider creating a line geometry based on a list attribute containing coordinates.
Assuming that the input feature has no geometry, but has a list attribute like this.
_coord{}.x
_coord{}.y
_coord{}.z

Then, create a 3D line. I expected this script would work fine as well.
-----
proc create3DLine {} {FME_Coordinates dimension 3
for {set i 0} {[FME_AttributeExists "_coord{$i}.x"] == 1} {incr i} {
set x [FME_GetAttribute "_coord{$i}.x"]
set y [FME_GetAttribute "_coord{$i}.y"]
set z [FME_GetAttribute "_coord{$i}.z"]
FME_Coordinates addCoord $x $y $z
}
}
-----
But it failed unfortunately. Created line was still in 2D, Z-values were missing.
It seems that "dimension" option of FME_Coordinates command is invalid when the feature has no geometry. If I set dimension to 3D after creating line, every Z-value becomes 0 although the line becomes 3D. It works like the 3DForcer transformer, but is not the expected functionality.

A workaround I found is: Add a dummy coordinate, set dimension to 3D, and remove the dummy coordinate before creating a line.Note: There is more appropriate workaround as after-mentioned (2013-12-14).
-----
proc create3DLine {} {
FME_Coordinates addCoord 0 0 0
FME_Coordinates dimension 3
FME_Coordinates resetCoords
for {set i 0} {[FME_AttributeExists "_coord{$i}.x"] == 1} {incr i} {
...
}
}
-----
It worked, but I don't like wasting steps for the dummy coordinate.
I expect the geometry to become 3D automatically when Z is given as the third argument for "FME_Coordinates addCoord".

=====
2013-12-14
I had requested Safe support about this problem; they provided a more appropriate workaround. That is, to set a geometry type beforehand.
If I set both geometry type and dimension like this, a 3D line will be created expectedly. It seems that "dimension" option will be valid after setting geometry type.
This is more desirable script. Thanks, Dan@Safe.
-----
proc create3DLine {} {FME_Coordinates geomType fme_lineFME_Coordinates dimension 3
for {set i 0} {[FME_AttributeExists "_coord{$i}.x"] == 1} {incr i} {
...
}
}
=====

For geometric operations, FME_Execute procedure can be also used. FME_Execute calls an FME Function directly.
"Close" function, for example, can be used to change a line to a polygon when the line consists of 3 or more coordinates. It's similar to the LineCloser transformer.
Just append a line to the procedure like this.
-----
proc createPolygon {} {
for { ...
...
}FME_Execute Close
}
-----

There are many FME Functions for geometric operations. If we could see detailed documentations about them, Tcl could be used much more effectively.
I remember that we could see the documentation "FME Functions and Factories" a few years ago, but it cannot be accessed now (2013-12-07).FMEpedia > Documentation: FME Functions and Factories

...so, my answer to the title is maybe a little negative, currently.
(FME 2013 SP4 Build 13547)
=====2014-03-21: I discovered that the documentation has been enabled. So I now change my answer to the title into "positive"!> FME Factory and Function Documentation

=====
2013-12-14: Found another way to change an unclosed line to a polygon.
FME_Coordinates procedure with "geomType" option can be also used to do that.
If I set explicitly the geometry type to "fme_polygon" before or after creating an unclosed line, then the line will be closed automatically and the resultant geometry will be a polygon.
-----FME_Coordinates geomType fme_polygon
-----
There seems to be many things which are not told in published documentations.

Of course FME Transformers without any scripting can do those operations.
I think a general approach will be like this.
ListExploder --> 2D/3DPointReplacer --> PointConnector (--> LineCloser LineJoiner)
2013-12-15: corrected a typo of "LineCloser". sorry.

2. Line Segment
Line segment is a special curve i.e. a straight line having only 2 end nodes; the CenterPointReplacer can be also used to get its midpoint.
The CenterPointReplacer creates center point of the bounding box, it's equivalent to midpoint if the original geometry is a straight line.

When testing for the Snipper method, I noticed the resultant coordinates could contain a slight computational error (very very slight, about 10-14 - 10-15 order in my testing). I guess that "FME stores all attributes as character strings" causes such a computational error.

I think such a very slight error will not be an issue in almost all the cases. But if it will be an issue, consider using a PythonCaller. Python could generate higher-precision result (but is not mathematically exact, computational error cannot be avoided).
-----
# Python Script Example: Replace Curve with Middle Point
# When input geometry is not a curve, do nothing.
# Measure length in 2D.
import fmeobjects
def replaceCurveWithMidpoint(feature):
geom = feature.getGeometry()
if isinstance(geom, fmeobjects.FMECurve):
measure3D = False
len = geom.getLength(measure3D) * 0.5
geom.snip(fmeobjects.SNIP_DISTANCE, measure3D, len, -1)
feature.setGeometry(geom.getStartPoint())
-----

2013-12-06

The FeatureMerger is one of the most frequently used transformers, it can be said that the basic functionality is similar to JOIN in SQL.

There are these JOIN types.
INNER JOIN
LEFT / RIGHT OUTER JOIN
CROSS JOIN

Consider sets of REQUESTOR and SUPPLIER features as database tables.
In the general parameter settings, set of MERGED features corresponds to the result table of INNER JOIN; union of MERGED and NOT_MERGED features corresponds to LEFT OUTER JOIN; union of MERGED and UNREFERENCED features corresponds to RIGHT OUTER JOIN.
=====
2013-12-07: When multiple suppliers can match with a requester, set of output features is not strictly same as the result of "JOIN" unless processing duplicate suppliers.
=====

Well, how's CROSS JOIN?
To perform the operation like CROSS JOIN, the following parameter settings will be necessary.
1. Merge features unconditionally
Specify the same constant (e.g. "1") to "Join On" for both Requestor and Supplier.
2. Process duplicate suppliers
Specify "Yes" to "Process Duplicate Suppliers".
3. Create list attribute
Specify a list name to "Supplier List Name".

Then, every REQUESTOR feature goes to MERGED port, and will have a complex list attribute which contains all attributes of every SUPPLIER feature. We can change the list elements to non-list attributes using the ListExploder if necessary.

As mentioned above, it's also possible to perform CROSS JOIN with the FeatureMerger. However, it might be inefficient in certain cases.
For example, if the purpose of CROSS JOIN is to select just a few matched suppliers with a condition based on attributes of the requester, the process of creating and exploding list attributes will waste memory and time for many mismatched features.

Use the InlineQuerier instead of the FeatureMerger in such a case.
Since the InlineQuerier uses SQLite internally, it consumes certain time for creating temporary database. But the querying could be much faster than other ways, so it could be efficient solution as a result.

2013-12-01

Resultant line segments should be (id 0 - id 1), (id 1 - id 2) and (id 2 - id 3), and also they should have attributes of the start node ("id" and "attr").
Just to create line segments, connect all points to create a polyline (2DPointReplacer + PointConnector), and then chop it into individual line segments (Chopper). It would be the quickest way, but will be necessary to recover attributes for every segment after chopping.

I think it was an enough elegant solution. However, in FME 2013 SP2+, since we can use both "Multiple Feature Attribute Support" and "Conditional Value" in the AttributeCreator, there could be more elegant and / or efficient solutions currently.
(FME 2013 SP4 Build 13547)

Example 1: Use the 2DPointReplacer and the 2DPointAdder
I think this is one of the plainest ways.

Example 2: Use @XValue and @YValue from FME Feature Functions
In this example I used the FMEFunctionCaller to call @XValue and @YValue. Those functions can be also called in the AttributeCreator etc..

2013-11-24

=====
2013-11-25: Found a custom transformer example called RegularPolygonCreator, the approach is different from my example. FMEpedia > RegularPolygonCreator
=====
This custom transformer example transforms an input point into a regular polygon; number of vertices and radius of the resultant polygon are given through parameters.

The strategy is:
1) Create a line segment directing to north (positive direction of Y axis) from the input point; its length is equal to the given radius.
2) Rotate the line segment by specific angle (= 360 / number of vertices) repeatedly; get coordinate of its end node at each time, transform coordinate values into XML element (<coord x="x value" y="y value" />), and append it to XML fragment.
3) After appending all vertex elements, complete the XML, replace it with a line geometry, and transform the line into a polygon.

For example, the final XML for a triangle should be like this.
-----
<?xml version="1.0" ?>
<geometry>
<line>
<coord x="0" y="0.4" />
<coord x="-0.346410161513776" y="-0.2" />
<coord x="0.346410161513775" y="-0.2" />
</line>
</geometry>
-----
This is in the "FME XML" encoding format, so it can be replaced with a line geometry using the GeometryReplacer transformer. Finally close the line to create a polygon using the LineCloser.

Originally, I needed to create radiational lines in an actual project. The example above is derived from that.
Radiational Lines:

=====
2015-10-16: A simpler way to create a regular N-gon.
(1) Create a circle area with the 2DEllipseReplacer.
(2) Stroke it with the ArcStroker.
Stroke By: Number of Interpolated Edges
Number of Interpolated Edges: <N>
That's it :)

2013-11-23

This example is a part of an actual project I recently completed.
The source dataset contains fine mesh polygons covering a local government area; each polygon has land-use type code as an attribute named "lu_type", its value can be one of 12 different codes:
0100, 0200, 0500, 0600, 0700, 0901, 0902, 1000, 1100, 1400, 1500, 1600

The purpose is to clip the meshes by other polygons (representing some specific land lots), and create a table of every land-use sum area inside of each lot.
Columns of the destination table should be:
lot_id | A0100 | A0200 | A0500 | ... | A1600

In the AreaCalculator, I specified "A" to the Area Attribute name; then the value of "lu_type" (0100, 0200, and so on) is appended to "A" as suffix, in the BulkAttributeRenamer.
So, after exposing those attribute names (AttributeExposer), all land-use areas of a lot can be aggregated into a feature (Aggregator 2).

That is, if the feature is the first one of a group, _cumulative_total should be equal to its own _value; otherwise should be sum of _cumulative_total of the previous feature and its own _value.

The AttributeCreator (FME 2013 SP2+) can do that easily.

There are two AttributeCreators in this workflow.
The 1st AttributeCreator creates an attribute named _cumulative_total, and initialize it by _value.
The 2nd AttributeCreator updates _cumulative_total using the "Multiple Feature Attribute Support" option and the "Conditional Value" setting.
If _group of the current feature is equal to _group of the previous feature, it sums _cumulative_total of the previous feature and _value of the current feature, then assign the result into _cumulative_total.
If not, it does nothing. i.e. not update _cumulative_total (= _value).
I think this will be a typical use case of the "Multiple Feature Attribute Support" option.

2013-11-14

Just write a line like this in the script, then a macro (parameter) named MY_PARAM can be used in the workspace. But the name will not appear in parameter list of the Workbench interface.
-----
puts "MACRO MY_PARAM Value"
-----

2013-11-10

When processing multiple datasets, the wildcard (*) is often used in Dataset setting of the Reader. The wildcard is very useful to read many datasets at once, but sometimes I need to do more complicated searching. I've tried some regular expressions, but those didn't work.

Those patterns can be used also in Dataset parameter of other Readers?

In my trial, the answer is Yes. Those worked fine in various Readers.
Just be aware that the file path has to be always quoted by double quotations when using a pattern with { } or [ ].
e.g.
"C:\tmp\{folder1,folder2}\*.shp" -- *.shp in C:\tmp\folder1 and C:\tmp\folder2
"C:\tmp\**\[ACE]*.shp" -- A*.shp, C*.shp, E*.shp in C:\tmp and any subdirectories below it

2013-11-09

This is a river system. The data are given as lines representing river spans, and a point of the river mouth. Assume that the lines are edges of a complete network.
The goal is to extract river lines which are within the specified distance from the river mouth. Distance has to be measured along the lines.
The workflow consists of 3 parts.

Part 1: The two Snippers creates both end nodes of every river span (Snipping Mode: Vertex), and the Matcher selects end nodes of the network except the river mouth.

Part 2: The CoordinateExtractor extracts (x, y) of the end nodes, the FeatureMerger appends unconditionally every (x, y) to the river mouth (Process Duplicate Suppliers: Yes), and the 2DPointAdder is used to create line segments between the river mouth and every end node.

This image shows the end nodes and the line segments. These line segments will be used as FROM-TO lines for the ShortestPathFinder in the next part.

Part 3: The ShortestPathFinder finds shortest paths from the river mouth to each end node, the Snipper snips the paths into the specified length if the path length is greater than the specified length, and the PathSplitter and the Matcher are used to remove duplicated lines.

Red lines are the result. The river lines in the downstream have been extracted.

There are various exceptional conditions in the actual data, getting practical solution is not so easy. This is just a skeleton of the workspace.

2013-11-03

Create normal (perpendicular) lines against a line segment. Make the start node of the resultant lines be equal to the start node of the input line segment.
This image illustrates the expected result.

Workflow Example (FME 2013 SP4 Build 13547)

One possible approach is: offset the line segment so that its start node is located at (0, 0); rotate the line about (0, 0) by 90 (Left) / -90 (Right) degree; scale the lines into specified lengths; offset the scaled lines so that those start nodes are equal to the start node of the input line segment.

If the Scaler origin could be set to any location, the Offsetters would not be necessary. But options of the current Scaler origin are "0, 0" and "Center Point" only, so the workflow became cluttered a little.
A custom transformer which performs scaling based on specified origin coordinate can be created, and it might be useful to not only this workflow but also many scenarios.

Addition 2013-11-04: There is another approach using characteristics of unit vector and normal vector. This workflow looks more elegant and also efficient to me.

Application Examples:

These images were created with the workflow and several existing transformers.

The PythoCaller with this script can do the same operation as the workflow.