I am curious why FME's clipper transformer creates aggregates by default. I would think that the this parameter should be set by default to "No". Many data formats can handle aggregates but there are many situations that this will cause major issues. My habit it to change this parameter each and every time I add a clipper. And newer users of FME may not know about this clipper parameter or know what it does.
Solved
Why does the Clipper transformer default to creating aggregates?
+7- Contributor
Best answer by erik_jan
The reason for setting the Aggregate option default to Yes is most likely to avoid duplication of key values. If more than one part of a geometry is inside the clipping boundary and the Aggregates is set to No, multiple objects with the same key value will be created.
This post is closed to further activity.
It may be an old question, an answered question, an implemented idea, or a notification-only post.
Please check post dates before relying on any information in a question or answer.
For follow-up or related questions, please post a new question or idea.
If there is a genuine update to be made, please contact us and request that the post is reopened.
It may be an old question, an answered question, an implemented idea, or a notification-only post.
Please check post dates before relying on any information in a question or answer.
For follow-up or related questions, please post a new question or idea.
If there is a genuine update to be made, please contact us and request that the post is reopened.
+23- Contributor
I know this is no answer to the question, but If you use the "Save as my Default" option you do not need to set this option more than once.
+23- Contributor
- Best Answer
The reason for setting the Aggregate option default to Yes is most likely to avoid duplication of key values. If more than one part of a geometry is inside the clipping boundary and the Aggregates is set to No, multiple objects with the same key value will be created.
I think it all depends on which formats you're used to. In my world, almost all formats I use on a daily basis handle aggregates just fine.
I also agree with erik_jan regarding avoding duplicate primary keys.
+59- Safer
I think another reason would be if you didn't have a key or ID value. Then there would be no way to identify which parts originally belonged to the same feature. By defaulting to aggregates we make sure there is always a way to identify chunks of the same feature.
Also we might have just thought it's easier to spot aggregates (and deaggregate them) than to realize there are multiple features and then aggregate them.
And erik_jan's point about defaults is a good one - this sort of scenario is exactly why we added that capability.
+15- Contributor
I agree to it not being Aggregate by default.
For the objects posed seem a bit suggestive or..well obviously inattentive behaviour towards spatial understanding..
Like objects with no ID's or a "object can be cut mutipletimes by a clipper"...realy..? Who would have tought..
;)
An object with no id, will still have no id trough agregation and deaggregation, up until the user adds one.
Any way, deagegagating adds a partnumber. This could also have been realised trought the clipper without the need to aggregate.