This must be trivial but after long workday my brains are not working.
I have a text file which I need to convert to table.
Here is a simple example to demonstrate the problem. Input text file contains street names for cities. City-keyword indicate when the city change.
Input text file:
Output table:
For this sort of problem in FME you need an AttributeCreator with Adjacent Feature Attributes turned on. Then a conditional formula which says, if line starts with City get the city, if not get the City from the feature above. Best to create a blank City attribute in an earlier AttributeCreator first otherwise the workspace complains (but still works). Then just some tidying up afterwards to get rid of the city lines
Alternatively, use the VariableSetter if the line starts with "City:", otherwise use the VariableRetriever to get the city name for the following lines.
A quick example attached
as @david_r
says.
Test for "City" by using a stringsearcher. WHen matched, set a variable.
If not read the variable.
In your case there is just 1 searcher needed.
Al you need to take care of is to make sure the variable is set before you retrieve it (else mostlikely an error wil be your reward)
is obviously faster then using lead and lag. (prior and adjacent in fme)
Alternatively, use the VariableSetter if the line starts with "City:", otherwise use the VariableRetriever to get the city name for the following lines.
I avoid using this method these days due to transformers no longer preserving feature order across output ports unless explicitly set and feature caching - both can lead to unexpected results
I avoid using this method these days due to transformers no longer preserving feature order across output ports unless explicitly set and feature caching - both can lead to unexpected results
That's an interesting thought! But wouldn't that be an issue with the Adjacent feature as well, if the feature order changes before the AttributeCreator?
I avoid using this method these days due to transformers no longer preserving feature order across output ports unless explicitly set and feature caching - both can lead to unexpected results
Typically i used to see Variable Setting and Retrieving done like this, which will work only if the tester has preserve Feature Order Across Output ports. Adjacent attribute mapping would just use one AttributeCreator/Manager to do the same with no opportunity to mess up the feature order (unless of course further upstream)
I avoid using this method these days due to transformers no longer preserving feature order across output ports unless explicitly set and feature caching - both can lead to unexpected results
Any set split will mess up ordering. (and StatsCalculator aals messes it up)
AS you say yourself : if you do it this way.
Which is why you shoudl do it inline. For you can use the conditionas statement in the setter, making the test superfluous.
I avoid using this method these days due to transformers no longer preserving feature order across output ports unless explicitly set and feature caching - both can lead to unexpected results
He refers to the fact thatg the proces of testing (tester) splits the stream and hence the ordering.
Why i suggest, if thats i an issue, to use setter and retriever inline.
USing conditional statement to test wether to set the value.
That would prevent the splitting and order messing.
I avoid using this method these days due to transformers no longer preserving feature order across output ports unless explicitly set and feature caching - both can lead to unexpected results
I'm not sure how you can do this inline? I can't see how you use the conditional value to not set the variable? There doesn't appear to be a do nothing option
I avoid using this method these days due to transformers no longer preserving feature order across output ports unless explicitly set and feature caching - both can lead to unexpected results
@david_r Tester/testFilter now has an Advanced option that allows you to select how to preserve the feature ordering, by Port (preserves the Feature Tables) , or across all the ports (splits the Feature Tables). But in general, feature tables do not re-order features, so AttributeCreator Adjacent features should continue to work.
Here is a sample of an inline...
Partionizing with counters.
strictly you don't need to use the variablesetter and retriever in this workbench. You could replace them with 1 attr creator.
I avoid using this method these days due to transformers no longer preserving feature order across output ports unless explicitly set and feature caching - both can lead to unexpected results
in the setter a conditional with a tcl regexp and capture
Thx for the answers and tips.
VariableSetter and VariableRetriever is excellent solutiuon for my problem. That city-street example was just easy case to demonstarte the problem. My actual case has nothing to do with geography. It contains lot of nested kinky and irregular structures.
But with V-Setter and V-Triever I managed to solve this.
Thx for the answers and tips.
VariableSetter and VariableRetriever is excellent solutiuon for my problem. That city-street example was just easy case to demonstarte the problem. My actual case has nothing to do with geography. It contains lot of nested kinky and irregular structures.
But with V-Setter and V-Triever I managed to solve this.
Of course, it always was.
But @ebygomm 's qualm was that the (non linear) v-setter/retriever messes the sorting order.
And you can do the exact same thing using a attributecreator, with or without prior/adjecent functionality..
I don't really understand your workspace as an example of inline variable setting and retrieving, the variable setter and variable retriever aren't really doing anything here that can't be achieved by a conditional statement in an attributecreator, all the work is done in another 7 transformers inside a custom transformer
I don't really understand your workspace as an example of inline variable setting and retrieving, the variable setter and variable retriever aren't really doing anything here that can't be achieved by a conditional statement in an attributecreator, all the work is done in another 7 transformers inside a custom transformer
..that is what i have stated in my post.
Let mer reiterate:
strictly you don't need to use the variablesetter and retriever in this workbench. You could replace them with 1 attr creator.
Just showing that you can do it inline using setters . As you wondered how that can be.
And the partinoinizer is generic (if you of course make the city attribute in the custom a paramter.)
It is the smart way of using counters that makes it fun.
And of course it undeniably yields a correct result. Wheter you understand it or not ;)
It is no requirement to like it.