Question

Custom Transformer Feature' Attritbutes vs Parameters

  • 19 February 2014
  • 10 replies
  • 4 views
D
Badge
Hi,

 

 

We are 2 guys and want to create some work bench to handle dozen of different data from dozen of different DB (btw the purpose is to create some XML and populate a single common DB with all this data ).

 

 

The thing is we also want some "end user" to be able to write some work bench.

 

 

Actually we have made ~30 custom transformer (CT) already (all are linked)

 

 

Here is our question:

 

What is the best way to specify (or not) CT parameters ?

 

 

1_ copy feature attribute in CT parameters and add a AttributeCreator from parameters to feature attribute.

 

We thinks it's a bit ugly, but the clearer for the end user: specify what we expect.

 

 

2_assume the feature have an attribute called "foo" and handle it that way ... and let the user deal with errors if his feature are missing attributes.

 

 

3_?? we don't know how to say "we want a feature with 'foo' and 'bar'".

10 replies

david_r
Rank
Userlevel 4
Hi,

 

 

in FME 2014 there are a couple of new published parameter types that might be of interest. Here is one of them:

 

 

 

 

The ListExploder (for "_attribute_list") and the AttributeDereferencer might also be relevant.

 

 

David
D
Badge
Thanks David.

 

 

Actually our problem is not really to get values; but to tell what we want.

 

 

If it was python, solution 1 is:

 

 

  for f in all_features:

 

    my_ct(param1, param2, f.foo, f.bar, f)

 

 

def my_ct(param1, param2, foo, bar, f):

 

    f.foo = foo

 

    f.bar = bar

 

    do_something(f.foo, f.bar)

 

Solution 2 is: for f in all_features:

 

    my_ct(param1, param2, f)

 

 

def my_ct(param1, param2, f):

 

    do_something(f.foo, f.bar)

 

What I would like is something to have solution 2 AND tell the user wich parameters I'm using (if it's possible).

 

If not, what is the "best" solution / good practice / better for performance / better for buritos etc... ?

 

david_r
Rank
Userlevel 4
Sounds like you should have a good look at the PythonCaller, it might just offer you the flexibility you need.

 

 

The API is documented under <FME install>/fmeobjects/python/apidoc/index.html

 

 

David
D
Badge
David,

 

 

I know Python and I know about PythonCaller, that's not why I'm searching for.

 

I used python to illustrate what I want.

 

 

 

My problem is how can I work with users, and share my CustomTransformers without them to have to know how it's done.
david_r
Rank
Userlevel 4
Hi,

 

 

have you looked at how it's done in the FME Store (http://fmestore.safe.com/transformers.htm)? Should be good for a few ideas.

 

 

David
takashi
Rank
Userlevel 2
Badge +17
Hi,

 

 

As my personal guideline, I basically receive feature attribute values through Published Parameters in order to keep generality and maintainability of the custom transformer (except embedded one for a specific workspace).

 

Probably my thought is common to your "solution 1". But I don't think it's always necessary to copy attribute values using the AttributeCreator. In many cases, you can refer to a parameter value (i.e. feature attribute value) via parameter name e.g. $(PARAMETER_NAME). So I think it's rare that you cannot avoid "ugly" workflow.

 

What kind of case are you assuming?

 

 

Takashi
D
Badge
Thanks Takashi,

 

 

My "ethical problem" with parameters is that I consider them as some kind of "constant" in my process.

 

For exemple: user id/pwd for data connection etc...

 

 

In my case, a feature is a row in DB; and I get the ID of each row as parameter for my CT (well, obviously, I ask for it).

 

So the CT become "like" a specific process for each feature, and not a part of the "flow".

 

For me it's awkward.

 

That's why, I prefere to create attribute for the feature.

 

 

The other positive effect of having feature attribute (and not parameters) is that every task in FME work with attributes and can highlight missing attributes.

 

 

Alex

 

 

takashi
Rank
Userlevel 2
Badge +17
An attribute name can be also treated as a parameter value (Parameter Type: Attribute Name, FME 2013+). And you can fetch the value which is associated to the attribute name with "@Value($(ID_ATTR_NAME))" in parameter settings of transformers.

 

Does this mechanism help your case?
D
Badge
Thanks Again Takashi.

 

 

Actually that's the way I'm doing things in my solution 1/

 

Followed by an AttributeCreator that does this:

 

Attribute Name: ITEM_ID  # <- so I know the attribute I want

 

Value: @Value($(ID_PARAM)) # <- the asked parameter

 

 

And so I've got my attribute in my feature.

 

 

 

 

 

takashi
Rank
Userlevel 2
Badge +17
That's an intelligible way, I don't think it's "ugly". But in many cases, I use the parameter name directly in any transformer parameter setting.

 

e.g.

 

Group By: $(PARAM)  (refer to attribute name for grouping)

 

ID_@Value($(PARAM)) (refer to attribute value for string concatenation)

 

etc.

Reply


Community Stats

28,737
Posts
109,567
Replies
36,577
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.