Skip to main content
  • EN

When I use a PythonCaller (on build 16673) to set the feature type by calling


feature.setFeatureType('something')

it actually doesn't seem to do anything, because when I connect a FeatureTypeFilter transformer to the PythonCaller and filter on 'something', nothing comes out of that port. 

I discovered that it only works if I do:

feature.setAttribute(fmeobjects.kFMEFeatureTypeAttr, 'something')

Where kFMEFeatureTypeAttr resolves to the string 'fme_feature_type'.

 

But then what is the point of the setFeatureType() method?

 

Is this method actually not implemented, perhaps?

Just tested, can confirm that setFeatureType() doesn't seem to do anything re fme_feature_type, or any other attribute for that matter.

Just tested, can confirm that setFeatureType() doesn't seem to do anything re fme_feature_type, or any other attribute for that matter.

Hi David, thanks for your confirmation :)

 

Can anyone from Safe confirm this too? And maybe create a PR to either make the method work or remove it from the API? I think a fix makes more sense, since getFeatureType() does work.

In my observation, the "feature type" value that is treated with the set/getFeatureType method is different from "fme_feature_type" and also automatically changes every time the feature is output from a transformer. I'm wondering if the "feature type" and those methods have a special role in the internal processing of FME engine.

The FMEFeature.setFeatureType() method is not that useful within a workspace, since whatever feature type you set will be modified by the PythonCaller and subsequent transformers. In the workspace context, the generic attribute 'fme_feature_type' retains the original feature type from the reader, and is what the FeatureTypeFilter filters on.

However, in a purely FMEObjects context (ie. external Python, C# application), or if you are using a writer within the PythonCaller, the actual feature type set by setFeatureType() is what is used by the writers and pipelines, and not the contents of the 'fme_feature_type' attribute.

The FMEFeature.setFeatureType() method is not that useful within a workspace, since whatever feature type you set will be modified by the PythonCaller and subsequent transformers. In the workspace context, the generic attribute 'fme_feature_type' retains the original feature type from the reader, and is what the FeatureTypeFilter filters on.

However, in a purely FMEObjects context (ie. external Python, C# application), or if you are using a writer within the PythonCaller, the actual feature type set by setFeatureType() is what is used by the writers and pipelines, and not the contents of the 'fme_feature_type' attribute.

Thanks Dave, that is some very useful information.

 

I also noticed the "inconsistent" behavior there. I was hoping to use the setFeatureType() method to "tag" output features in my PythonCaller so I could filter on them afterwards using the FeatureTypeFilter, but I guess I need to use the 'fme_feature_type' attribute for that then. But now I know I could basically set any attribute and just use an AttributeFilter instead...

 

Thanks Dave, that is some very useful information.

 

I also noticed the "inconsistent" behavior there. I was hoping to use the setFeatureType() method to "tag" output features in my PythonCaller so I could filter on them afterwards using the FeatureTypeFilter, but I guess I need to use the 'fme_feature_type' attribute for that then. But now I know I could basically set any attribute and just use an AttributeFilter instead...

 

If you haven't already, feel free to vote for this idea, which is kind of related:

 

https://knowledge.safe.com/idea/24903/add-rejected-port-to-the-pythoncaller.html

 

If you haven't already, feel free to vote for this idea, which is kind of related:

 

https://knowledge.safe.com/idea/24903/add-rejected-port-to-the-pythoncaller.html

 

I already did that a while ago :)

 

In fact, I would love to expand that idea by having any number of custom in- and output ports for the PythonCaller (similar to the new FeatureWriter for instance) that each receive their own method (not just input(self, feature)). If that doesn't require a major overhaul of the API, of course...

 

Reply


Community Stats

30,126
Posts
114,347
Replies
37,758
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.