Question

Spatial Relator Attribute handling. Replacing values unexpectedly

kalbert
Rank
Badge +9

I'm using a SpatialRelator with default settings (Generate List = checked, Merge Attributes = un-checked).

A polygon class serves as both (Requester and Supplier) to identify polygons containing others within the class. This works perfectly well.

The issue is on the attribute level: Each requestor attribute that has a <null> value is filled with a not <null> value from one of the suppliers. All not <null> attributes of the requestor remain unchanged as expected.

It seems the SpatialRelator performs an attribute merge even if 'Merge attribute' is unchecked.

I tried 'Merge attribute' with conflict resolution 'use requestor' as mitigation. But even then requestor <null> values are filled with non <null> from the supplier

Is this a bug or intended? If intended is it documented anywhere?

 

regards

Klaus

 

FME Desktop 2017.1.1 and FME 2018.1.1.1 build 18578 WIN 64

12 replies

ebygomm
Rank
Userlevel 1
Badge +10

I've never seen that behaviour before. Are you sure if you're using the same features as both requestor and suppliers that the output you're seeing is a requestor with a null value merged rather than a requestor that already has the value?

kalbert
Rank
Badge +9

Yes. My objects have unique keys so that I can refer to it and can compare the object's attribute values before and after the SpatialRelator.

takashi
Rank
Userlevel 2
Badge +17

In my quick test, the symptom didn't appear when the Merge Attributes option wasn't checked.

However, if you checked the option, <null> attributes in a Requestor feature were overwritten with non-null values in conflict attributes from a spatially related Supplier feature even if the Conflict Resolution parameter was set to "Use Requestor".

I'm not sure if the behavior is intentional. Hope someone from Safe will check this. @DanAtSafe

Comparison: This FeatureJointer preserves <null> in the attribute "a" from the Left feature if the Conflict Resolution is set to "Use Left".

The FeatureMerger has the "Ignore Nulls" parameter to control relevant behavior, but it is set to "No" by default. I feel something inconsistent on the behavior in the SpatialRelator.

redgeographics
Rank
Userlevel 5
Badge +25

I've never seen that behaviour before. Are you sure if you're using the same features as both requestor and suppliers that the output you're seeing is a requestor with a null value merged rather than a requestor that already has the value?

I agree: haven't seen this myself before and I can't seem to reproduce it. Doublecheck your data before and after the SpatialRelator, if this is true I'm sure Safe will want to see it.

kalbert
Rank
Badge +9

@takashi

thanks for your quick test. I'm now waiting for Safe's response. Klaus

fmelizard
Rank
Userlevel 4
Badge +13

In my quick test, the symptom didn't appear when the Merge Attributes option wasn't checked.

However, if you checked the option, <null> attributes in a Requestor feature were overwritten with non-null values in conflict attributes from a spatially related Supplier feature even if the Conflict Resolution parameter was set to "Use Requestor".

I'm not sure if the behavior is intentional. Hope someone from Safe will check this. @DanAtSafe

Comparison: This FeatureJointer preserves <null> in the attribute "a" from the Left feature if the Conflict Resolution is set to "Use Left".

The FeatureMerger has the "Ignore Nulls" parameter to control relevant behavior, but it is set to "No" by default. I feel something inconsistent on the behavior in the SpatialRelator.

Hi @takashi and @kalbert Thanks for finding this problem with the SpatialRelator. I see it with the latest 2019 beta and I've filed a problem report. I'll update here when it's been fixed.

ebygomm
Rank
Userlevel 1
Badge +10

I've encountered this issue, or something very similar today. A spatial relator with a group by merges attributes from the supplier even when merge attributes is unticked. The attributes aren't exposed, so it's not easy to spot.

spatialrelator_merged_attributes_problem.fmw

 

 

fmelizard
Rank
Userlevel 4
Badge +13

@takashi

thanks for your quick test. I'm now waiting for Safe's response. Klaus

Hi @kalbert We plan to fix this problem in FME 2019.1

fmelizard
Rank
Userlevel 4
Badge +13

I've encountered this issue, or something very similar today. A spatial relator with a group by merges attributes from the supplier even when merge attributes is unticked. The attributes aren't exposed, so it's not easy to spot.

spatialrelator_merged_attributes_problem.fmw

 

 

Hi @egomm This has already been fixed in v11 of the SpatialRelator in FME 2019.1

ebygomm
Rank
Userlevel 1
Badge +10

Hi @kalbert We plan to fix this problem in FME 2019.1

Hi @danatsafe - can you confirm the problem I've described is the same issue?

fmelizard
Rank
Userlevel 4
Badge +13

Hi @danatsafe - can you confirm the problem I've described is the same issue?

@egomm I can confirm that the group_by problem is different from @kalbert 's. Yours still exists in FME 2019.0 but not in 2019.1

kalbert
Rank
Badge +9

Hi @kalbert We plan to fix this problem in FME 2019.1

Hi @danatsafe I ran some tests with SpatialRelator and SpatialFilter in 2019.1. The issue is solved. Thanks

Reply


Community Stats

28,669
Posts
109,364
Replies
36,531
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.