Question

FeatureReader won't accept my Attributes to expose input

  • 24 July 2015
  • 5 replies
  • 36 views
T
I have an Excel parameter file with tabular information indicating which files/feature classes/tables to read, which queries to use, which fields to expose, etc. I figured the FeatureReader would be a good option to use for grinding through my various datasets. I've managed to get most of what I need to work, but I am seriously struggling with the Attributes to expose.

 

 

I first thought I could simply use an attribute from my parameter file as input, but it seems the FeatureReader only accepts User Parameters for this option. I therefore created a separate workspace for the FeatureReader, calling it from my main workspace through a WorkspaceRunner, with Attributes to expose as an input parameter. But...no joy. While it now seemingly accepts input from my parameter file attribute, it doesn't do anything with it. I have tried various settings for the user parameter (text, attribute, attribute list, ...). I have created a user parameter straight from the FeatureReader dialog (it seems to be an attribute list parameter). The only thing that seems to work is to have a text user parameter and hardcode the attribute name(s) in there. But that obviously does not help me.

 

 

I am using FME 2015.1.0.3, and I have so far tested while reading data from ESRI SDE and file geodatabases. The input from the parameter file is typically just a string or a series of space-separated strings (e.g. '<attribute1>' or '<attribute1> <attribute2> <attribute3>).

 

 

I reckon I am just muddling my parameter types or missing something obvious! Can anybody guide me through this part of the FeatureReader? If not, are there any other ways of exposing attributes based on input from my parameter file? I do need to expose the attributes in order to use them in subsequent transformers.

 

 

Thanks,

 

Tale

5 replies

takashi
Rank
Userlevel 2
Badge +17
Hi Tale,

 

 

Unfortunately there is no way to expose attribute names at run-time dynamically, you will have to expose them statically when creating the workspace if necessary.

 

However, the features read by the FeatureReader will internally have the attributes which are defined in the source data even if their names are not exposed in the workspace. In some cases, it might be enough that you expose statically several attributes only for the subsequent transformers. This depends on your final goal.

 

 

Takashi
T
Hi Takashi,

 

 

Thanks for the quick reply!

 

 

Not being able to expose attributes dynamically is a bit of a bummer. I guess this will be my number one Christmas wish to Safe! On the positive side, though, this means I am not completely thick for not being able to make it work:).

 

 

I have spent the weekend concocting a workaround, involving a set of workspaces being called sequentially with WorkspaceRunner:
  1. Workspace reading my parameter file and making a simple mapping table with my original dataset names, their attribute names and an output attribute name. The output attribute will always have the same name, "Valuefield". If there are more than one attributes I need to keep, then it is just to expand this pattern in the mapping table production.
  2. Workspace reading the original datasets through a FeatureReader, passing them through a SchemaMapper with my mapping table, and then writing them temporarily to .ffs with a Writer with Valuefield defined as the only attribute. I then end up with a bunch of ffs-files named <originalDatasetName>.ffs with a single "significant" attribute, Valuefield.
  3. Workspace reading all the temporary ffs-files through a FeatureReader, exposing the attribute Valuefield (either through the FeatureReader itself, or through a tagged on AttributeExposer), and then chugging along with my processing.
It isn't particularly elegant as this involves reading and writing the data twice, rather than the once I was aiming for. I do hope it will do the job, though, as I potentially have hundreds of input datasets all with a different significant attribute.

 

 

Tale
takashi
Rank
Userlevel 2
Badge +17
If you can somehow add an attribute (e.g. "oldName") which stores the attribute name that should be changed to "ValueField" to every feature, the TclCaller with this "Tcl Expression" can be used to rename the attribute.

 

-----

 

FME_RenameAttribute ValueField [FME_GetAttribute oldName]

 

-----

 

And also you can expose "ValueField" by the "Attributes to Expose" parameter in the TclCaller.

 

 

Alternatively, in the same condition, the FMEFunctionCaller with this "FME Function" works as well. 

 

-----

 

@RenameAttributes(ValueField,@Value(oldName))

 

-----

 

In this case, it would be necessary to add an AttributeExposer to expose "ValueField".

 

 

FYI

 

E

I just tried to do the same thing (workspace 1 reads configuration file, calls workspace 2 through a WorkspaceRunner and passes the Attribute(s) to expose to the pub. parameter linked to a FeatureReader). However, also FME 2017.1 does ignore this information. However, since parameters are handled before runtime, it should be possible to do so. Otherwise, offering the option to link the parameter "attributes to expose" of a FeatureReader to a published/private parameter would be quite misleading.

Or am I doing something wrong and it works by now?

Greetings, André

G
Badge +3

@tale

There is a trick to doing this.

Using a AttributeExploder, AttributeFileWriter and a FeatureReader.

Reply


Community Stats

28,707
Posts
109,478
Replies
36,552
Members
Terms & ConditionsCookie settings
A product of
Safe Software respectfully acknowledges that we live, learn and work on the traditional and unceded territories of the Kwantlen, Katzie, and Semiahmoo First Nations.