Skip to main content
  • EN

Hello,

I'm having difficulty getting the results I want out of the Spatial Relator and AreaOnAreaOverlayer. Essentially, I'm trying to identify overlapping polygons within the same layer, where the overlap area is of a significant size, so that I can separate these out into separate layers in a fan out at the end of the process.

I want to do this by creating a field and populating that with a value, where the first / bottom polygon remains in the original layer, but additional overlapping polygons are allocated an increasing number so they can be separated into a new layer - all the '0's, '1's and '2's together.

I don't want to identify or attribute what are essentially topology errors (very slight overlaps), as these need to be reviewed and fixed manually, just what are considered 'legal' overlaps so they can be topologically cleaned separately.

I have an (incredibly bulky and inefficient) solution, using both SpatialRelator and AreaOnAreaOverlayer and a hefty amount of conditional value calculations for attributes, but there's got to be a better way.

The SpatialRelator seems to identify not only areas that overlap but also lines and points, and these should fall into the 'insignificant / topology error' category. If there was some way to only select area cardinality from the SpatialRelator, and then check the size of these overlaps, I think that might work.

The AreaOnAreaOverlayer only gives me the intersection of the overlapping areas, whereas I need to select the whole of the original polygon and allocate it an attribute, so this can only be used as a supplier in a merge or the like. Also, it occasionally throws out a rejected feature which stops the translation, and I'm stumped as to what to do to fix that.

Any ideas?

My build is 2018.0. I'm attaching the current mess of a workflow and three shapefiles. The 'Licences' shapefile produces what I want to see, but only if you disable the feature merger, and only because it doesn't overlap any adjacent polygons. For the other two, the final AttributeManager creates an attribute OVERLAPS_LAYER_NUMBER_2, which is almost right, but doesn't create the right sequence of numbers - ie, it starts at '2' rather than '1'.

Any help much appreciated!

Hi @katrinaopperman, the attached workspace resolves topology errors and then extract polygons contained by other one. I think the result would be close to your desired one.

extract-polygons-within-other-polygon.fmwt (FME 2018.0.1.1)

 

Note: The workspace extracts polygons which are Within or Equal to other one, but not detect Overlap. For example, in this screenshot, A and B overlap on the area surrounded by red line. I'm unclear how Overlap areas should be treated. How should it be treated?

overlap

Hi @katrinaopperman, the attached workspace resolves topology errors and then extract polygons contained by other one. I think the result would be close to your desired one.

extract-polygons-within-other-polygon.fmwt (FME 2018.0.1.1)

 

Note: The workspace extracts polygons which are Within or Equal to other one, but not detect Overlap. For example, in this screenshot, A and B overlap on the area surrounded by red line. I'm unclear how Overlap areas should be treated. How should it be treated?

overlap

The Generalizer may not be essential in your case.

 

 

Hi @takashi, thank you for your prompt reply!

I was probably not very clear. The end result I'm after is an attribute that identifies if a feature overlaps or is overlapped by another feature (as noted, of significant size, not topology errors), and allocates the higher feature to an incremental number, so that it can be used as a fan out for the datasets at the end. In your example, Feature A would receive an overlap_layer number of 0, and Feature B would get 1, so that they could be separated into two different layers.

overlaps-example.png

In my screenshot above, the blue underlying shapes (names with a lower number than the name of the shapes above them) have an overlap_layer number of 0, and the ones that overlap them - the green - have an overlap_layer number of 1. If there were 6 overlapping features here, then each additional feature should receive an incrementally increasing number, so there would be values of 0, 1, 2, 3, 4, & 5 in the overlap_layer attribute.

All features that are Equal To or Overlap would need to be discovered and attributed. If the feature 'within' the first feature is the hole for a legal donut that does not overlap in any other way, then it should not be separated out - both of those features would be in layer 0.

Am I right in assuming that when you store and then retrieve the geometry, the original geometry is not altered in any way? It's important that we retain the original definition of the areas, and any topology errors are investigated and fixed by our data managers not during the process.

Thanks for your help, as always!

Hi @takashi, thank you for your prompt reply!

I was probably not very clear. The end result I'm after is an attribute that identifies if a feature overlaps or is overlapped by another feature (as noted, of significant size, not topology errors), and allocates the higher feature to an incremental number, so that it can be used as a fan out for the datasets at the end. In your example, Feature A would receive an overlap_layer number of 0, and Feature B would get 1, so that they could be separated into two different layers.

overlaps-example.png

In my screenshot above, the blue underlying shapes (names with a lower number than the name of the shapes above them) have an overlap_layer number of 0, and the ones that overlap them - the green - have an overlap_layer number of 1. If there were 6 overlapping features here, then each additional feature should receive an incrementally increasing number, so there would be values of 0, 1, 2, 3, 4, & 5 in the overlap_layer attribute.

All features that are Equal To or Overlap would need to be discovered and attributed. If the feature 'within' the first feature is the hole for a legal donut that does not overlap in any other way, then it should not be separated out - both of those features would be in layer 0.

Am I right in assuming that when you store and then retrieve the geometry, the original geometry is not altered in any way? It's important that we retain the original definition of the areas, and any topology errors are investigated and fixed by our data managers not during the process.

Thanks for your help, as always!

You could add a test in Takashi's SpatialRelator to also check for Requestor overlay Supplier, and then you will get the areas that only overlaps a little. It will give you 3 different layer, 0, 1, 2, and I think that might be right after Takashi removed the sliver problem.

 

 

The Generalizer may not be essential in your case.

 

 

@takashi, @paalped, thank you! With the addition of the overlaps supplier, I get the right outcomt.

Hi @takashi -

Please forgive me if I'm missing something obvious here, but I'd love to try extract-polygons-within-other-polygon.fmwt. I don't see it available for download here. Any help you may be able to provide would be much appreciated!

Hi @takashi -

Please forgive me if I'm missing something obvious here, but I'd love to try extract-polygons-within-other-polygon.fmwt. I don't see it available for download here. Any help you may be able to provide would be much appreciated!

Hi @redmenace​ - apologies for the broken link. Our team has repaired the link to the template file so you should be able to download and try it out now :)

Hope that helps!

Reply


Community Stats

30,176
Posts
114,544
Replies
37,837
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.