SpatialRelator propagates wrong feature type ?

perhaps is there a ListExploder to explode the list generated by the SpatialRelator?

 

 

redgeographics wrote:

I think @takashi is right. If you only use the SpatialRelator the requestors will retain their fme_feature_type, but if you then use a ListExploder it will overwrite the fme_feature_type of the requestor with the one from the supplier.

That's what the ListExploder does I'm afraid.

There is a workaround:

1. Expose the fme_feature_type attribute on the suppliers
2. Set the SpatialRelator to only add selected attributes and don't select the fme_feature_type attribute

That should do it.

Hi red,

 

 

Ah, I needed to upgrade the SpatialRelator (and ListExploder) transformers to the latest versions before I got the "selected attributes" possibility :-)

 

 

To clarify, the "fme_feature_type" of the features being output from SpatialRelator are all "SpatialRelator_OUTPUT", but the list "_relationsships[].fme_feature_type" are all equal to the SpatialRelator's suppliers' feature_type. But after ListExplode, the feature all have type "ListExploder_ELEMENTS". At least according to Data Inspector, which I'm not sure is correct.

 

 

So I added a couple of inspectors, one after SpatialRelator and one after ListExplode, and the former reports the correct feature-type, whereas the latter report the wrong (from the SpatialRelator suppliers, i.e. "_relationsships[].fme_feature_type".

 

 

So it looks like it's WAD behaviour after all, as the relationships supposedly defines what the requester feature encounters, including their feature-types.

 

 

So to enforce the requester feature-types, I'll stick to my work-around for now then :-)

 

 

Ps! The two transformers are located inside a custom transformer, and the only attribute in "selected attributes" were "fme_feature_type", so that unfortunately didn't help med out. But if located in the main window, it might just work nicely.

 

 

Cheers