Solved

custom transformer behaviour

  • 6 February 2014
  • 6 replies
  • 8 views

Badge +3
Hi again!

 

 

New uissue.

 

Concerning custom transformers.

 

 

I made a transformer doing some spatial operations.

 

At the end i have a new attribute and a lot of the input attributes.

 

I use a keeper to only pass the new attribute and a ID-type field.

 

 

The purpose is to use this customtransformer multiple times in a workbench.

 

 

What now happens is, as soon as i enter a second or more instance(s) of this transformer, it turns some fields to parameters. No problem yet..

 

 

But then i get a red eclamation mark, so i choose the parameters...then the excalmation mark moves to a transformer connected to the output of the customtransformers.

 

It appears some attributes wont pass.

 

 

I found out that the problem was the attributekeeper in the custom transformer.

 

If i remove that, and do the keeping outside the transformer, everything is AOK again.

 

 

Why is this?

 

 

Thanks for answering.

 

 

Greeting again,

 

Gio

 

But the weird thing is some key fields wont pass.
icon

Best answer by takashi 7 February 2014, 12:20

View original

6 replies

Userlevel 2
Badge +17
Hi Gio,

 

 

Try adding an AttributeExposer before the AttributeKeeper to expose the input attribute name which you need to keep.

 

It's hard to explain the reason in my poor English...

 

 

Takashi

I was having a different problem that was apparently also related to this behaviour of the AttributeKeeper. It seems that the AttributeKeeper also removes attributes that are not exposed! I figured this out by replacing the AttributeKeeper with an AttributeRemover.

 

I regard this unexpected behaviour, and it can be annoying. Since it is not mentioned in the documentation, if your workbench purposely doesn't expose all attributes, it takes a lot of time to find out why these non-exposed attributes aren't fed to your writer at the end of the workflow.

(Mind you: I'm using FME 2016.1)

Badge +22

I was having a different problem that was apparently also related to this behaviour of the AttributeKeeper. It seems that the AttributeKeeper also removes attributes that are not exposed! I figured this out by replacing the AttributeKeeper with an AttributeRemover.

 

I regard this unexpected behaviour, and it can be annoying. Since it is not mentioned in the documentation, if your workbench purposely doesn't expose all attributes, it takes a lot of time to find out why these non-exposed attributes aren't fed to your writer at the end of the workflow.

(Mind you: I'm using FME 2016.1)

The documentation says:

Once connected to input features, the AttributeKeeper provides pick lists (one for attributes and one for list attributes) for you to choose which attributes to retain. All other attributes are removed, and the modified features are output.

Geometry and FME attributes are not removed.

Format attributes will be removed whether exposed or not . Exposed FME attributes will simply be hidden - not removed permanently.

To me *all* other attributes implies unexposed as well as exposed attributes.

The documentation says:

Once connected to input features, the AttributeKeeper provides pick lists (one for attributes and one for list attributes) for you to choose which attributes to retain. All other attributes are removed, and the modified features are output.

Geometry and FME attributes are not removed.

Format attributes will be removed whether exposed or not . Exposed FME attributes will simply be hidden - not removed permanently.

To me *all* other attributes implies unexposed as well as exposed attributes.

Thank you jdh, for pointing this out. However, I would interpret it the opposite direction: since they are not mentioned, user attributes wil be removed dependent on their exposure.

And if not, I would expect the AttributeKeeper to show the hidden attributes in the list, so I can choose which ones to keep. Of course, then the whole idea of of hiding attributes becomes futile - just like resistance.

 

If I explicitly hid user attributes so that they won't be affected by my workbench, why would the AttributeKeeper suddenly ignore this?

Perhaps someone from Safe can clarify?

 

Badge +2

Thank you jdh, for pointing this out. However, I would interpret it the opposite direction: since they are not mentioned, user attributes wil be removed dependent on their exposure.

And if not, I would expect the AttributeKeeper to show the hidden attributes in the list, so I can choose which ones to keep. Of course, then the whole idea of of hiding attributes becomes futile - just like resistance.

 

If I explicitly hid user attributes so that they won't be affected by my workbench, why would the AttributeKeeper suddenly ignore this?

Perhaps someone from Safe can clarify?

 

Hi @ferdinandbogman,

@jdh is correct and this is further explained in the Usage Notes section of the AttributeKeeper documentation:

  • If the number of attributes you want to keep is greater than the number of attributes you want to remove, consider using the AttributeManager.
  • Use the AttributeManager to remove selected individual attributes from a feature.
  • Use the BulkAttributeRemover to remove all attributes that match a pattern.
  • To keep a Format attribute, expose it first, either in the reader or by using the AttributeExposer
  • If you choose to keep a list element attribute, for example member{0}.type, it won’t appear under the transformer unless this element has already been exposed. See Exposing List Attributes for more information.

Depending on the number of attributes you are keeping vs. removing, you may want to consider the AttributeManager or AttributeRemover as they will only remove the specified attributes/lists.

Hope that helps.

Hi @ferdinandbogman,

@jdh is correct and this is further explained in the Usage Notes section of the AttributeKeeper documentation:

  • If the number of attributes you want to keep is greater than the number of attributes you want to remove, consider using the AttributeManager.
  • Use the AttributeManager to remove selected individual attributes from a feature.
  • Use the BulkAttributeRemover to remove all attributes that match a pattern.
  • To keep a Format attribute, expose it first, either in the reader or by using the AttributeExposer
  • If you choose to keep a list element attribute, for example member{0}.type, it won’t appear under the transformer unless this element has already been exposed. See Exposing List Attributes for more information.

Depending on the number of attributes you are keeping vs. removing, you may want to consider the AttributeManager or AttributeRemover as they will only remove the specified attributes/lists.

Hope that helps.

Hello Chris,

 

Thank you for your reaction. In any case we all agree that the AttributeKeeper works this way. But my point is:
  1. The documentation describes the behaviour of the AttributeKeeper for geometry, FME and Format attributes explicitly. The Usage Notes even suggest a workaround if you want to keep a Format attribute (use the AttributeExposer). Since there is no mention of any specific behaviour for User attributes, I would expect those not to be removed if they are hidden.

     

     

  2. Apparently, with the AttributeKeeper, I have to expose hidden User attributes, just like Format attributes (as Takashi suggested), to prevent them from being removed. That makes no sense to me when I had hidden them so they would not be affected by any transformers at all...

Perhaps I don't understand the concept of hiding or exposing attributes very well. I'm rather new to FME and I haven't found much information about it yet.

Reply