• EN
Question

Dynamic Group-By attributes

  • 2 January 2024
  • 3 replies
  • 12 views
joepk
Rank
Userlevel 4
Badge +17

Hi everyone,

 

I am currently trying to use the NeighborFinder transformer in Group-By mode to match features from SDE A on features from SDE B.

I'm using Group-By to only match objects of the same type (trees with trees, bollards with bollards, etc) and with the same vertical datum class (ground-level with ground-level, below-ground-level with below-ground-level, etc.).

 

However, some feature classes in SDE A do not have a vertical datum class attribute. Using the NeighborFinder in Group-By mode, none of my objects match, since SDE A has <Missing> vertical datum classes, and SDE B has correctly filled in ones.

For these feature classes it is alright for the NeighborFinder to only use the obect type attribute.

I want to avoid using multiple NeighborFinders in my workspace.

 

I have tried constructing a special Group-By attribute, concatenating the two attributes. But I can't seem to find a nice way for SDE B to not include the vertical datum class when the SDE A featureclass doesn't have it.

 

Any ideas on how to do this? Thanks in advance!

3 replies

joepk
Rank
Userlevel 4
Badge +17

As of now I used the StringConcatenator on SDE A features to concatenate @Value(type)_@Value(vertical datum class), resulting in strings like"tree_1" (when both attributes are used correctly) or "bollard_" (when the vertical datum class is missing).

 

I then use a Sampler to get 1 feature, AttributeKeeper to keep only the concatenated attribute and AttributeCreator to create a 1 = 1 attribute for easy joining. I then use the FeatureJoiner to join the SDE A concatenated attribute to all SDE B attributes and I use the Tester to check for the regex "_\\d".

 

The Passed features go to a StringConcatenator with the same concat as SDE A, and the Failed features go to a StringConcatenator without the @Value(vertical datum class) part.

The NeighborFinders can then be grouped by the concatenated attribute.

 

This feels like a pretty sloppy workaround so I prefer to implement a more fancy way of handling this issue.

hkingsbury
Rank
Userlevel 5
Badge +29

Whilst a solution that doesn't use two neighborfinders sounds ideal, in the long run its probably going to cause more issues than it solves. It's likely going to be over complicated and could cause weird edge cases to appear. Also, when you (or someone else) revisits the workbench in the future you might be thoroughly confused as to what you did.

 

I think the cleanest and simplest way is to use two neighborfinders. Pass the data from SDE A through a tester to split it into those with a vertical datum class and those without, then have two neighborfinders, one for those with a vertical datum, and one for those without.

 

Based on what you've said, the ones with no vertical datum are pretty few and far between so it shouldn't have a significant impact on performance (i'm assuming the potential performance implications are why you're not wanting to use two neighborfinders)

Check out the Abley FME Firesides on Youtube: https://www.youtube.com/@ableyltd
joepk
Rank
Userlevel 4
Badge +17

Whilst a solution that doesn't use two neighborfinders sounds ideal, in the long run its probably going to cause more issues than it solves. It's likely going to be over complicated and could cause weird edge cases to appear. Also, when you (or someone else) revisits the workbench in the future you might be thoroughly confused as to what you did.

 

I think the cleanest and simplest way is to use two neighborfinders. Pass the data from SDE A through a tester to split it into those with a vertical datum class and those without, then have two neighborfinders, one for those with a vertical datum, and one for those without.

 

Based on what you've said, the ones with no vertical datum are pretty few and far between so it shouldn't have a significant impact on performance (i'm assuming the potential performance implications are why you're not wanting to use two neighborfinders)

Thanks for your reply. I think you hit the nail on the head with the part about my workspace becoming overly complicated if I try to avoid multiple NeighborFinders, especially since someone else will indeed use (and probably debug) this workspace in the future. I'll just add another NeighborFinder and split my data.

 

I still feel like a dynamic group-by option could be of use, especially when it is not just 2 attributes used to group by.

Reply


Community Stats

28,818
Posts
109,858
Replies
36,638
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.