I have a workbench to translate a shapefile to Microstation DGN. In the workbench I have a parameter to let the user specify on with attribute of the shapefile the layernames in the DGN should be based. When I run the workbench in FME Workbench everything works fine and the layers in the DGN are named by the content of the attribute. But when I run the workbench in FME QuickTranslator, the layer in the DGN is named by the attribute itself.
Is this a bug?
Solved
DGN-layernames based on the content of an attribute
+4- Contributor
Best answer by mark2atsafe
OK, it's a sort of bug. Workbench and the Quick Translator are interpreting the value differently. But it's partly because I don't think this is the best way to handle this.
Your published parameter has two options - but they are just strings you are selecting. You aren't selecting an attribute. This video shows how the icon changes from attribute to string when you make a selection:
https://www.screencast.com/t/wAQbOGkh
Workbench chooses to interpret this selection as an attribute, because an attribute of that name already exists. The Quick Translator doesn't. If anything I'd say the Workbench behaviour is wrong, but I doubt we would want to change it now.
The solution is this: In your published parameter definition, instead of the configuration being GME_NAAM%WPSNAAMNEN (i.e. strings) change it to @Value(GME_NAAM)%@Value(WPSNAAMNEN) (i.e. each entry is specified as an attribute).
That way works, but it's a little bit of a hack.
Another solution ought to be to change the parameter type to Attribute Name and then change the writer feature type name to @Value($(_layer)). But that doesn't work (I think it should), and even if it did you'd be giving the end user the full set of attributes to choose from.
Anyway, try that first solution and see what you think. It works for me.
+48- Celebrity
Did you specify the layername as @Value($parameter))? If so it should work, although I am noticing that the Quick Translator doesn't show an attribute list where the Workbench does.
+4- Contributor
redgeographics wrote:
Did you specify the layername as @Value($parameter))? If so it should work, although I am noticing that the Quick Translator doesn't show an attribute list where the Workbench does.
When i change this to @value($_layer) I get an error: Error creating level without any level name
I tried it with ParameterFetcher and Attributecreator, but this didn't work either.
In the uploaded zip the workbench and the shapefile.
layernames-dgn.zip
+48- Celebrity
You do need to select an attribute (this should not be an optional parameter) and it needs to be filled with a value of course.
Anyway, I was able to reproduce your error, it happens for me too if I use the Quick Translator. I think this may be a bug indeed and would recommend that you send this in to Safe's support team, or the support team at your FME reseller.
+17- Contributor
You could use an AttributeCreator to get the attribute name and then the AttributeDereferencer to get the attribute value in a new attribute.
Use that attribute on the output layer name.
+4- Contributor
erik_jan wrote:
You could use an AttributeCreator to get the attribute name and then the AttributeDereferencer to get the attribute value in a new attribute.
Use that attribute on the output layer name.
+17- Contributor
raimond wrote:
When I do that, I get the error: Error creating level without any level name
It should be of this type:
+43- Safer
- Best Answer
OK, it's a sort of bug. Workbench and the Quick Translator are interpreting the value differently. But it's partly because I don't think this is the best way to handle this.
Your published parameter has two options - but they are just strings you are selecting. You aren't selecting an attribute. This video shows how the icon changes from attribute to string when you make a selection:
https://www.screencast.com/t/wAQbOGkh
Workbench chooses to interpret this selection as an attribute, because an attribute of that name already exists. The Quick Translator doesn't. If anything I'd say the Workbench behaviour is wrong, but I doubt we would want to change it now.
The solution is this: In your published parameter definition, instead of the configuration being GME_NAAM%WPSNAAMNEN (i.e. strings) change it to @Value(GME_NAAM)%@Value(WPSNAAMNEN) (i.e. each entry is specified as an attribute).
That way works, but it's a little bit of a hack.
Another solution ought to be to change the parameter type to Attribute Name and then change the writer feature type name to @Value($(_layer)). But that doesn't work (I think it should), and even if it did you'd be giving the end user the full set of attributes to choose from.
Anyway, try that first solution and see what you think. It works for me.
+4- Contributor
Hi Mark,
Thanks, by changing the configuration to @Value(GME_NAAM)%@Value(WPSNAAMNEN) it works like I want to.
The other solutions (parameter type Attribute Name) doesn't work in the Quick Translator, because the parameter has no attributenames.
+43- Safer
raimond wrote:
Hi Mark,
Thanks, by changing the configuration to @Value(GME_NAAM)%@Value(WPSNAAMNEN) it works like I want to.
The other solutions (parameter type Attribute Name) doesn't work in the Quick Translator, because the parameter has no attributenames.
Reply
Helpful Members This Week
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.