Skip to main content
  • EN

Does FME have a transformer for "hiding", as opposed to "removing" an attribute? I am using the FeatureReader to dynamically read a feature class that is specified by parameter. This script is then called for many feature classes. The attributes of any one feature class are thus not exposed.

However, for some features I need to access the ID field of the feature class, for example, "FID". I do this by an AttributeExposer in a custom transformer that is only called for a particular feature class.

But I don't want the ID field to carry on as an attribute when it is time to write the feature class to the output table. It would be great if I could then "un-expose", or "hide" the attribute, back to the level of visibility it had when I used the feature reader. Is it possible?

Hiding an attribute will not keep it from being written.

For that you will need an AttributeRemover or AttributeKeeper transformer.

You can hide an attribute using a quirk in the pythonCaller, there is a parameter for attributes to hide.

That said, if you are writing a table dynamically, then it's the schema that controls whether or not an attribute is included, not whether it is visible on the canvas or not.

Hiding an attribute will not keep it from being written.

For that you will need an AttributeRemover or AttributeKeeper transformer.

It is not a dynamic writer though, only a dynamic reader. The script is writing errors into an error table. For generic errors I don't need the ID field, but for errors specific to a given feature class, say, sewer pipes, I do need that ID field. Hiding it just keeps the noise down.

 

It is not a dynamic writer though, only a dynamic reader. The script is writing errors into an error table. For generic errors I don't need the ID field, but for errors specific to a given feature class, say, sewer pipes, I do need that ID field. Hiding it just keeps the noise down.

 

I see. In that case it makes sense!

 

 

You can hide an attribute using a quirk in the pythonCaller, there is a parameter for attributes to hide.

That said, if you are writing a table dynamically, then it's the schema that controls whether or not an attribute is included, not whether it is visible on the canvas or not.

I had to look at this one twice, and actually it does work. My only concern is that it works because of a 'quirk' in the PythonCaller, as @jdh described it. Someday that quirk might go away. I think it would be better to have an "attributehider" transformer that explicitly does the same thing.

 

You can hide an attribute using a quirk in the pythonCaller, there is a parameter for attributes to hide.

That said, if you are writing a table dynamically, then it's the schema that controls whether or not an attribute is included, not whether it is visible on the canvas or not.

It's a "quirk" in that I cannot think of a reason why the pythonCaller would have attributes that need to be hidden rather than exposed.

 

 

You can however vote on Takashi's idea on the subject. https://knowledge.safe.com/idea/27259/add-attributeslists-to-hide-option-to-the-attribut.html

 

 

Or mine: https://knowledge.safe.com/idea/19546/attributehider.html

 

Reply


Community Stats

30,193
Posts
114,604
Replies
37,855
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.