Geographic Information Systems Stack Exchange is a question and answer site for cartographers, geographers and GIS professionals. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

As it says in the title, is this expected behaviour?

What happens is that the dataset before the area on area overlayer has some features (in the image below, the large green parts are the same feature, there is a point where they touch). The lower part of the green feature is lost when the transformer is run. This shouldn't happen!

I have an example dataset and workspace, here:

There are a number of other cases where this happens in my dataset. Any thoughts?

This image shows, circled in blue, the component of the green area that is lost after running the aeraonareaoverlayer transformer.

share|improve this question
I have a workaround. First, add a counter to store a unique ID. Then use the chopper, then do the analysis, then disolve on the UID. – Alex Leith Apr 16 '13 at 2:18
I have a work around too. see post – Mapperz Apr 16 '13 at 13:21

Adding the GeometryValidator to the workspace solved the issue [Using FME 2013 SP1]

So this is likely to be a data issue rather than an FME bug.

How was the data created?

enter image description here

share|improve this answer
16 features go into the AreaOnAreaOverlay and 17 features come out. – Mapperz Apr 16 '13 at 13:27
What is the extra feature? Is it a duplicate, or a split? – Alex Leith Apr 17 '13 at 3:46
The GeometryValidator is turning the feature into a multi-part polygon, that's divided at the intersecting/touching point. So the output from the AreaOnAreaOverlayer will be correct. It won't have moved or deleted a point. The only issue will be does this form of data get written to your output as you need? If not, you could try a Dissolver transformer, to merge it back into a single polygon; though you would want to be careful about what you are dissolving. Preferably assign a unique ID and dissolve with that as a group-by – Mark Ireland Apr 17 '13 at 16:07
Regardless, I think this could be something that we should fix. To me it's a toss-up between whether it's bad data or bad behaviour by the FME transformer. I'm going to file this with the development team and get their opinion on it. – Mark Ireland Apr 17 '13 at 16:09
Hi Mark, thanks for your response. I did solve it with a chopper, unique ID and dissolver. One of the suggested solution here may have been simpler, but I don't want to mess with my working method! My reason for calling it a bug is that I used the OGC geometry validator and all were valid. I know that it is a polygon with a shared node, or a node that is coincident, but there were other cases where it was failing too (it was a 20,000 feature dataset). I'd prefer not to share the whole dataset though. – Alex Leith Apr 18 '13 at 3:57

Using a Recursive Deaggregator transformer will also solve this issue. Generally the issue is data-related due to invalid geometry parts. Reducing complexity and increasing validity wil solve this problem.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.