Skip to main content
  • EN

I know the issue of dynamically exposing attributes in a feature reader from the Generic port comes up often, but I thought I would ask anyway. I have two issues with the FeatureReader regarding scripted parameters.

 

Firstly, I have a text file which contains a list of feature classes to read. As feature classes are added to the database, the name will be added to the text file. I have a Python Scripted Parameter which is called "FeatureTypes" with the following code:
f = open(r"D:\Scripts\DEV\List of Feature Classes.txt", 'r')
featureTypes = ''
for line in f.read().split('\n'):
    featureTypes += (line + " ")
f.close
return featureTypes

This returns a nice list of all feature classes to read. In my FeatureReader, I set the Feature Types to Read paramter, to this $(FeatureTypes) parameter. However, when the database tries to read it, it's reading the literal string "$(FeatureTypes)" instead of the list. I got around this by using a ParameterFetcher and storing the list of feature classes into an attribute called _FeatureTypes. That's a suitable workaround to what seems like a bug.

Next, because each of these feature classes have a lot of different attributes, I have another text file which contains all possible attributes across all feature classes. The idea is, that when a new feature class is added, and it gets added to the text file of feature classes, any fields that hadn't been previously on the list will get added to the text file of attributes.

I have another python scripted parameter called $(AssetAttributes) which will, in theory, do the same thing for attributes.

f = open(r"D:\Scripts\DEV\List of Asset Attributes.txt", 'r')
AssetAttributes = ''
for line in f.read().split('\n'):
    AssetAttributes += (line + " ")
f.close()
return AssetAttributes

I set the generic port to expose these attributes by selecting the $(AssetAttributes) parameter,

0684Q00000ArF34QAF.png

However, the issue is that it's treating the parameter as a literal string. So, instead of exposing the attributes, I get this:

0684Q00000ArFEMQA3.png

Note, I cannot hard-code the attributes because it is possible that people will add new feature classes with new attributes. I want this to run without any manual intervention. Also, I don't mind if features have NULL values for attributes that aren't on the original feature.

I'm using FME 2020.0.2.1 Build 20238 Win64.

Is this a bug? Or is what I'm trying to do simply not possible?

Hi @rchoucroun​ 

make sure that the list created by the python scripted parameter is using correct separator. For my workspace I am using spaces between attribute names and it works for the "Attributes to Expose:" parameter.

I have the same issue with the parameter of the Transformer - AttributeValidator which seems to use comas (not spaces) but when I create such a list as a user parameter and select it in the "Attributes to Validate" transformer parameter, it seems not to pick them up...

@rchoucroun​  - did you ever figure out the python to list the attributes in a scripted parameter? I am trying to accomplish the same thing due to the limitations with the FeatureReader transformer and exposing attributes on the generic port.

Also, to add information, I am able to use a python scripted parameter to get the list of field names/attributes and they do populate with the scripted parameter as expected:

 

Example:

Scripted Parameter Name: $(scriptedParameter)

Returns the value of:

OBJECTID COMPONENT SITE_NAME JOINT_BASE STATE_TERR COUNTRY OPER_STAT IS_FIRRMA SE_ANNO_CAD_DATA SHAPE_LENG Shape_Length Shape_Area

 

However, when using the same scripted parameter in the FeatureReader Transformer - Generic Port - Attributes to Expose, the result is missing values in an attribute called $(scriptedParamter) (the same name as the parameter).

 

If I hardcode the value of the parameter to my list of attributes, things work fine.

 

Is this a bug with the FeatureReader transformer, or do scripted parameters not work in the FeatureReader Transformer - Generic Port - Attributes to Expose?

 

 

Reply


Community Stats

30,133
Posts
114,383
Replies
37,770
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.