Skip to main content
Solved

Where are the attributes created by attributecreator?


Forum|alt.badge.img

I have run attributecreator, creating a field from unique values in a field. I think it worked (no error messages). Where are these attributes? I don't see them.

 

Thank you,

 

Randy McGregor

Note: Can't prrovide specifics of the data. Hopefully explaining it will work?

 

Best answer by ebygomm

If you're creating an attribute from attribute values you won't see them on the canvas unless they are exposed. If you inspect a feature you should be able to see the created attribute(s) in the feature information window on the right

View original
Did this help you find an answer to your question?

13 replies

danilo_fme
Evangelist
Forum|alt.badge.img+45
  • Evangelist
  • May 12, 2020

Hi @ramcgreg

 

Did you create a new attribute inside the transformer AttributeCreator? Could you print it?

 

Thanks,

Danilo

 


danilo_fme
Evangelist
Forum|alt.badge.img+45
  • Evangelist
  • May 12, 2020

Did you run your Workspace after you created the new Attribute? I see you are inspect with cache enable.


ebygomm
Influencer
Forum|alt.badge.img+39
  • Influencer
  • Best Answer
  • May 12, 2020

If you're creating an attribute from attribute values you won't see them on the canvas unless they are exposed. If you inspect a feature you should be able to see the created attribute(s) in the feature information window on the right


bwn
Evangelist
Forum|alt.badge.img+26
  • Evangelist
  • May 12, 2020

@ramcgreg , one of the more useful shortcuts to know for showing other FME users what you have done or are trying to do is Ctrl - Shift - K. If select the AttributeCreator Transformer on the canvas, and use this shortcut, it will create a Summary Annotation that shows other users what Parameters have been set, so they can properly see what has been used in the workspace like this:

Note that AttributeCreator generally puts new Attributes at the Top of the list. In your case, it appears that "facility_id" was created, but that can only be confirmed if we can see what the actual Transformer parameter settings were.


Forum|alt.badge.img
  • Author
  • May 19, 2020

I appreciate the responses, but have not had time to follow up. I use attribute exporter after creating attributes. I create a table of unique values from the field that I want to create field names from, export it to a table, then import those values into the parameters for the attributeexporter.

It feels like about three extra steps, since I have already created the attributes with the attribute creator.

I will investigate your suggestions and get back in here. Thank you,


Forum|alt.badge.img
  • Author
  • May 19, 2020
ebygomm wrote:

If you're creating an attribute from attribute values you won't see them on the canvas unless they are exposed. If you inspect a feature you should be able to see the created attribute(s) in the feature information window on the right

I think this is it. I do expose them, but was hoping there was a way I could eliminate this step. I am getting field names from unique values in a field. To acquire the list of attributes to expose, I have to either enter them by hand or import them from a table that I have to create. I actually create a separate fme process to do this.

 

Maybe this is working as designed and I just need to make peace with it, but I was hoping to streamline this process.

 

Thank you,

Randy


Forum|alt.badge.img
  • Author
  • May 19, 2020
danilo_fme wrote:

Hi @ramcgreg

 

Did you create a new attribute inside the transformer AttributeCreator? Could you print it?

 

Thanks,

Danilo

 

I have created new attributes, I just can't see them without attributeexposer, which may just be how it is supposed to work.

 

Thanks,

 

Randy


ebygomm
Influencer
Forum|alt.badge.img+39
  • Influencer
  • May 19, 2020
ramcgreg wrote:

I think this is it. I do expose them, but was hoping there was a way I could eliminate this step. I am getting field names from unique values in a field. To acquire the list of attributes to expose, I have to either enter them by hand or import them from a table that I have to create. I actually create a separate fme process to do this.

 

Maybe this is working as designed and I just need to make peace with it, but I was hoping to streamline this process.

 

Thank you,

Randy

Unfortunately right now if you want them exposed on the canvas, i.e. available for later transformers then you do need to do this slightly convoluted step. However, if you are just looking to write the newly created attributes to a file for example, with dynamic writers, it's not necessary to have the attributes exposed in order to write them out.


bwn
Evangelist
Forum|alt.badge.img+26
  • Evangelist
  • May 20, 2020
ramcgreg wrote:

I think this is it. I do expose them, but was hoping there was a way I could eliminate this step. I am getting field names from unique values in a field. To acquire the list of attributes to expose, I have to either enter them by hand or import them from a table that I have to create. I actually create a separate fme process to do this.

 

Maybe this is working as designed and I just need to make peace with it, but I was hoping to streamline this process.

 

Thank you,

Randy

@ramcgreg If the Attribute Names are being created with a function like @Value(Attribute Value) instead of a fixed string value, then there is no way that the Workflow can know what the resulting Attribute Names will be at Design time and hence why AttributeExposer exists as the Transformer to address this. Attribute Names created with a function like this only become known once the Workflow is run and the data read and transformed.

As @ebygomm suggests, you only need to use AttributeExposer on Attributes needing to be used as further inputs into later Transformers. Most use cases that create Attribute Names dynamically like this typically don't need the Attribute Names to be exposed because it becomes equally hard to design downstream Transformers with Attribute Names that can be variable.

Any unexposed Attributes can still be written, and can still be reviewed in Data Inspector.

Otherwise the broader question that you may wish to consider is if there really is a need to create a table formatted like this. Most cases that generate dynamic Column labels are as the result of creating a CrossTab. There are better ways of structuring data for processing, and CrossTabbing is a process that generally should be left as the very last step in the data processing workflow, and is usually only for report formatting purposes.

For example, a CrossTab table of:

"Country" "State" (As Row Headers), "Population""GDP""Birth rate".... etc. (As Column Headers)

Works better in most worfklows if the underlying data tables are themselves actually maintained and processed in a relational/normalised way like this:

"Country""State""Measurement Name""Measurement Value"
"United States""AL""Population"4900000
etc.

This way you are dealing with a fixed and known Schema and in which optimal data queries can be performed by Eg. Filtering by Measurement Name.


Forum|alt.badge.img
  • Author
  • July 6, 2020
Sorry for the very long lag. I appreciate everyone's input here. Looks like I am not going to be able to escape the "extra" step of exposing the attributes. I do have a working fme process. I was just wondering if I could drop the extra step of exposing the attributes, but it does not look like it for this particular workflow.

Thanks

Randy McGregor


Forum|alt.badge.img
  • Author
  • July 6, 2020
danilo_fme wrote:

Did you run your Workspace after you created the new Attribute? I see you are inspect with cache enable.

I want to create the attributes from values in a field, then I need to act on those attributes. I am not able to act on them until I can see them and I think I can't see them until I run "expose attributes."

Thanks


Forum|alt.badge.img
  • Author
  • July 6, 2020
bwn wrote:

@ramcgreg If the Attribute Names are being created with a function like @Value(Attribute Value) instead of a fixed string value, then there is no way that the Workflow can know what the resulting Attribute Names will be at Design time and hence why AttributeExposer exists as the Transformer to address this. Attribute Names created with a function like this only become known once the Workflow is run and the data read and transformed.

As @ebygomm suggests, you only need to use AttributeExposer on Attributes needing to be used as further inputs into later Transformers. Most use cases that create Attribute Names dynamically like this typically don't need the Attribute Names to be exposed because it becomes equally hard to design downstream Transformers with Attribute Names that can be variable.

Any unexposed Attributes can still be written, and can still be reviewed in Data Inspector.

Otherwise the broader question that you may wish to consider is if there really is a need to create a table formatted like this. Most cases that generate dynamic Column labels are as the result of creating a CrossTab. There are better ways of structuring data for processing, and CrossTabbing is a process that generally should be left as the very last step in the data processing workflow, and is usually only for report formatting purposes.

For example, a CrossTab table of:

"Country" "State" (As Row Headers), "Population""GDP""Birth rate".... etc. (As Column Headers)

Works better in most worfklows if the underlying data tables are themselves actually maintained and processed in a relational/normalised way like this:

"Country""State""Measurement Name""Measurement Value"
"United States""AL""Population"4900000
etc.

This way you are dealing with a fixed and known Schema and in which optimal data queries can be performed by Eg. Filtering by Measurement Name.

Thank you. That is informative and helpful.


Forum|alt.badge.img
  • Author
  • July 6, 2020
ebygomm wrote:

Unfortunately right now if you want them exposed on the canvas, i.e. available for later transformers then you do need to do this slightly convoluted step. However, if you are just looking to write the newly created attributes to a file for example, with dynamic writers, it's not necessary to have the attributes exposed in order to write them out.

Thanks. That helps.


Cookie policy

We use cookies to enhance and personalize your experience. If you accept you agree to our full cookie policy. Learn more about our cookies.

 
Cookie settings