I'm not sure I follow as to why the featuremerger is not an option, but you could always extract the geometry into an attribute with a geometryextractor then rebuild after using the featurejoiner with a geometry replacer
I'm not sure I follow as to why the featuremerger is not an option, but you could always extract the geometry into an attribute with a geometryextractor then rebuild after using the featurejoiner with a geometry replacer
FeatureMerger will give the EXTRA_REFFERENCE error. But I am definetely going to try your idea thank you a lot!
FeatureMerger will give the EXTRA_REFFERENCE error. But I am definetely going to try your idea thank you a lot!
You could switch the suppliers and requestor features around to get round that, or process duplicate suppliers in the feature merger, build a list and then explode the list
You could switch the suppliers and requestor features around to get round that, or process duplicate suppliers in the feature merger, build a list and then explode the list
One of the thing is that the cardinality is many-to-many and I believe I tried your last idea but it caused me to lose some information, I'll give it a second go and see
FeatureMerger will give the EXTRA_REFFERENCE error. But I am definetely going to try your idea thank you a lot!
If you get an EXTRA_REFERENCE error, try turning on "Process duplicate suppliers" in the FeatureMerger:
@nademmy
EXTRA_REFERENCE measn dat the supplier key is offered more than once.
You can have them processe as @david_r says by setting "process duplicates".
If you enter a list and then explode it you get the data merged.
But be aware that 1:M can lead to as many duplicate geometries as there are suppliers
If you are going to use it in arcmap you might wanbt to keep the data separated, as in arcmap you can use the table join on the fly.
btw, you don't need to switch suppliers and requestors as you can have the feature merger set to merge mode= "attributes and geometry" if you want the supplier geometry rather than the requestor geometry.