Skip to main content
Solved

InlineQuerier - dropping autocad_entity (and maybe other) attributes

  • December 3, 2025
  • 5 replies
  • 119 views
k_lander
Contributor
Forum|alt.badge.img+9

In a workspace processing AutoCAD data, I have recently replaced a bunch of transformers with an InlineQuerier, and downstream of it is an AttributeFilter, filtering on the autocad_entity attribute. Because of this, I found that the InlineQuerier is dropping this attribute, regardless of whether it’s exposed when entering.

I don’t need the attribute for my queries, so I had not originally added it to query columns, but after some testing, the only way I can get the attribute to persist on the features exiting is to include it in the query columns, specifically include it in my SELECT statement, and also not include fme_feature_content in the SELECT. 


With a simplified query:

Works - autocad_entity is present on output
Not working - autocad_entity missing in output

I found this post  Geometry Replacer - missing attribute after output | Community where the replies note the GeometryReplacer will remove this attribute (among others) to avoid issues downstream - this makes sense, and I’ve found that renaming the attribute does indeed preserve it in the output.
 

To my question: Does anyone know if this is the same thing the InlineQuerier is doing? I’m guessing since it does have the ability to work with geometry, it may be doing this when fme_feature_content is included, though anything included in fme_feature_content could not have been modified by the InlineQuerier if my understanding is correct, maybe it should be dropped only if a geometry type column is included in an Input table, or if geometry is created in the query? - but there’s probably some other scenario I’m not thinking of that could happen here.

The renaming trick isn’t too bad in the grand scheme of things, but I’ll likely be using the InlineQuerier much more in the future since it’s so powerful, and knowing if I need to watch for this issue with other attributes as well might save time in the future. Thanks!

Best answer by k_lander

Thanks for looking into this as well ​@s.jager ​@geomancer ! It is a really good point that the autocad_original_entity_type could be used in autocad_entity’s place, though I should point out that the two attributes are a bit different: autocad_original_entity_type is a more precise description of the entity, and in a lot of cases will be different, here’s a slice of my data just before entering the InlineQuerier (you’ll see I added the leading underscore to _autocad_entity for the workaround):
 

Now in my case and I guess maybe for most cases, autocad_original_entity_type would work just fine with more exhaustive filtering, or an AttributeValueMapper to basically recover the autocad_entity attribute, but I don’t think the InlineQuerier is creating it.

I had some more time to test my theory that it’s doing something similar to the GeometryReplacer, and ran a Shapefile through it with a simple query:

SELECT "Mask.fme_feature_content"
FROM "Mask";
Input data has shapefile_type attribute.
Output data is missing shapefile_type

I think this is probably enough evidence to safely say it behaves the same way as the GeometryReplacer: see Usage Notes here https://docs.safe.com/fme/html/FME-Form-Documentation/FME-Transformers/Transformers/geometryreplacer.htm

The documentation mentions referring to the fme_ attributes after the GeometryReplacer as well, and that is another perfectly workable solution here, so I think I’ll mark this as answered, but if anyone has further insight I’d love to hear it!

I also feel like the InlineQuerier documentation should maybe mention this behaviour.

danilo_fme

5 replies

s.jager
Influencer
Forum|alt.badge.img+23
  • s.jagerInfluencer
  • Influencer
  • December 4, 2025

Could it be that the InlinceQuerier is getting confused because the fully qualified description of the fme_feature_content attribute is “CAD”.”CAD.fme_feature_content”? Right now you’re missing the “CAD”. in front of it.

But the fact that it only passes on the attributes that are in the select does not surprise me, to me that is actually as expected.

 

k_lander
Contributor
Forum|alt.badge.img+9
  • k_landerContributor
  • Author
  • Contributor
  • December 4, 2025

Thanks for looking, good eye on the missing table name, but I tested that out and it doesn’t seem to make a difference here. Here are the attributes that are output from either of these queries (with or without explicitly selecting autocad_entity) - autocad_entity is missing: 

SELECT "CAD"."autocad_layer", "CAD"."CAD.fme_feature_content"
FROM "CAD";

SELECT "CAD"."autocad_layer", "CAD"."autocad_entity", "CAD"."CAD.fme_feature_content"
FROM "CAD";

 

And this query:

SELECT "CAD"."autocad_layer", "CAD"."autocad_entity"
FROM "CAD";

So fme_feature_content is storing and carrying forward all attributes when selected (except for autocad_entity in this case)


If I add an underscore to the attribute name beforehand, making: _autocad_entity, then this is the result:

SELECT "CAD"."autocad_layer", "CAD"."CAD.fme_feature_content"
FROM "CAD";

In fact the result is the same if I only select "CAD"."CAD.fme_feature_content"
 

s.jager
Influencer
Forum|alt.badge.img+23
  • s.jagerInfluencer
  • Influencer
  • December 5, 2025

 

Thanks for looking, good eye on the missing table name, but I tested that out and it doesn’t seem to make a difference here. 

Hmm. Very strange. It almost seems as if like the InlineQuerier is renaming it:

 

Coincidence has it that I’ve been asked to convert a bunch of dwg’s to something QGis can handle this week, so that’s why my attention was caught by your question. I’ll have a look at some of my own stuff, see if I can reproduce. Because this might affect the webapp I am building to let folks do it themselves, if this is a bug or ‘feature’ of the InlineQuerier.

 

Edit: After reading the post that you linked to, I am pretty sure that is what the InlineQuerier is doing: Renaming the autocad_entity to autocad_original_entity_type to prevent geometry issues down the line. A bit unexpected to see the InlineQuerier doing that, but since the InlineQuerier can handle (simple) spatial stuff, I suppose it is prudent.

 

 

 

geomancer
Evangelist
Forum|alt.badge.img+60
  • geomancerEvangelist
  • Evangelist
  • December 5, 2025

Good find about autocad_original_entity_type!

After a quick test in FME 2023.1.1 it appears to work like this:

  • When fme_feature_content is part of the SELECT, the attribute autocad_entity in fme_feature_content is renamed to autocad_original_entity_type
  • When the attribute autocad_entity is exposed, and fme_feature_content is part of the SELECT, the exposed attribute autocad_entity loses its value
  • When the attribute autocad_entity is exposed, and fme_feature_content is NOT part of the SELECT, the exposed attribute autocad_entity keeps its value
k_lander
Contributor
Forum|alt.badge.img+9
  • k_landerContributor
  • Author
  • Contributor
  • Best Answer
  • December 5, 2025

Thanks for looking into this as well ​@s.jager ​@geomancer ! It is a really good point that the autocad_original_entity_type could be used in autocad_entity’s place, though I should point out that the two attributes are a bit different: autocad_original_entity_type is a more precise description of the entity, and in a lot of cases will be different, here’s a slice of my data just before entering the InlineQuerier (you’ll see I added the leading underscore to _autocad_entity for the workaround):
 

Now in my case and I guess maybe for most cases, autocad_original_entity_type would work just fine with more exhaustive filtering, or an AttributeValueMapper to basically recover the autocad_entity attribute, but I don’t think the InlineQuerier is creating it.

I had some more time to test my theory that it’s doing something similar to the GeometryReplacer, and ran a Shapefile through it with a simple query:

SELECT "Mask.fme_feature_content"
FROM "Mask";
Input data has shapefile_type attribute.
Output data is missing shapefile_type

I think this is probably enough evidence to safely say it behaves the same way as the GeometryReplacer: see Usage Notes here https://docs.safe.com/fme/html/FME-Form-Documentation/FME-Transformers/Transformers/geometryreplacer.htm

The documentation mentions referring to the fme_ attributes after the GeometryReplacer as well, and that is another perfectly workable solution here, so I think I’ll mark this as answered, but if anyone has further insight I’d love to hear it!

I also feel like the InlineQuerier documentation should maybe mention this behaviour.

geomancer
s.jager

Community Stats

32,207
Posts
122,305
Replies
39,891
Members

Latest FME

Terms & ConditionsCookie settingsAccessibility statement
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.