As I understand it FeatureMerger only do exact matches, that is A = B. What I want to accomplish is more like the LIKE condition in SQL as in:
B LIKE B% ( B Like Boink = true )
or
B LIKE %B% (B Like oinkBoink = true)
Is this posible in any way?
I have two features that I want to merge based on adresses. One of the two features that the merge will be based on sometimes contains extra information (like apartement numbers) and the other have the coordinates that I want to add to the first feature nut misses that extra part. Problem is when doing FeatureMerger these features containing the extra info dont match with the features that dont.
Page 1 / 1
Hi,
As you say, matching rule of the FeatureMerger is exact match. Consider using the InlineQuerier instead. It's much more flexible, and also may be more efficient in many cases.
Takashi
Hi,
You can actually do that using the conditional mode of the featuremerger:
and conditons
In the "Parameter Condition Definition" window (try saying that 3x very fast...lol), rightclick in the output value and choose "open string editor".
For ease you can switch to advance mode (left bottom of string editor window).
..must admit i never did or do that..
i just checked wether it is possible..
this one is weird:
it actually works, as long as the requester is "B" or opther single letter. If i make it "Boo" it fails.
Als the exclamation mark stays red??
Shame, that might make this solution useless.
addendum:
If u use this technique, the non merged objects will not appear on the "NOT MERGED" output.
Instead they will appear on the "UNREFFERENCED" output.
is this transfromer like a bit broken i wonder or can it not handle this type of abuse?
Gio, I don't think it's possible to refer to attributes of Requester in the conditional value setting for Supplier.
One possible way to use the FeatureMerger somehow is unconditional merging (FeatureMerger) and filtering (Tester).
Merge features unconditionally with "Process Duplicate Suppliers" option. The result is similar to CROSS JOIN. Then, use a Tester to select features matching the condition.
It's possible, but might consume huge memory and time. I think it's better to consider using the InlineQuerier...
Hi Takashi,
the merging construction does work. I just teid it out. I admit it is a bit strange,
u can acces the atributes trough the string editor. I think this is maybe not inteded?
Strange that it actualy lets you pick the attribute. ( i did not enter it, i picked it from the list in advance mode string editor, wich u can acces by clicking on test conidtion field)
Look:
Suplier==>testcondition==>Set to attribute value...uc an acces both requester and suplier attributes.
If u open string editor you can enter funtions like the Left function.
Do you think this is a fault?
Is that why you can pick the attribute in the list, but it doe'snt realy acces it....that
If i enter "Boo" instead of "B" it does not merge, because @Left(@Value(Torequest),1)% does not yield "B". I understand.
Indeed I can select requestor's attributes in the condition value settings for supplier, but the transformer doesn't work if I did so. Did you get a correct result from the workspace?
I think it would be right that you cannot access requester's attributes from supplier's condition value settings (vice versa). If both requester and supplier have an attribute with same name, how can the FeatureMerger determine which side it belongs to?
Maybe it's a kind of bug on the interface of condition settings dialog.
Hi takashi,
The transformer has a red exclamation mark, but it does work.
U have to set up the test, then it can actualy merge.
Strange thing is that @Left(@Value(Torequest),1)% in the testcondition only works if my attribute "Toreguest" is 1 letter: "B", "N", etc works but not "BOO","Naruto".
But yes it realy works..il post it to you, its fme2013 try it out.
It performs conditional merging just like Tinkergnome asked for.
Hi again,
Why this will not work for oinkBoink but does for Boink.
The problem is that the outputvalue of the testcondition cannot acces the supplied requestor attribute.
So i can output:
@Substring(@Value(ToSuplies),0,1)
(wich grabs the leading "B" in oinkboink)
but i cannot output:
@Substring(@Value(ToSuplies),@FindString(@Value(ToSuplies),@Substring(@Value(Torequest),0,1),1),1)
(this latter one would grab the "B" in oinkBoink.)
The right and leftvalues can acces both attributes.
Furthermore it is possible to use stringparsing in the requestor like in supplier with the saem limitation in reverse.
One can still do quite some variations of conditional merging.
Why the outputvalue would be limited in such a way, i find strange. As the testconditions left and right can acces the attributes, albeit with a red exclamation mark, might as wel let the outputs enjoy the same freedom. Would make it more versatile too.