NeighborhoodAggregator does not seem to work as it creates multi-parts and fills in all of the donuts.
Have a look at the custom transfomer the listcombiner. After you get a list determining relationships from a spatial relator you can assign a common id to shapes that are within or contained by each other. You can then dissolve by this group
A quick example
dissolve_shapes.fmwt
Which takes you from 7 shapes down to 4
Have a look at the custom transfomer the listcombiner. After you get a list determining relationships from a spatial relator you can assign a common id to shapes that are within or contained by each other. You can then dissolve by this group
A quick example
dissolve_shapes.fmwt
Which takes you from 7 shapes down to 4
This is a good idea, but unfortunately fails as much of the geometry that is entirely within also touches the outer boundary. It was able to simplify 10 of the 192 objects.
This is a good idea, but unfortunately fails as much of the geometry that is entirely within also touches the outer boundary. It was able to simplify 10 of the 192 objects.
I think the problem is what you think entirely within is not in fact entirely within. It shouldn't matter if there is a point where shapes touch or have a coincident boundary. The smaller square would be dissolved into the larger square in this scenario
Unfortunately, if there are very tiny overlaps it makes your process more problematic, as you then have to evaluate if 99.9% of the area of the polygon is within another.
You could try applying a negative buffer to your suppliers before a spatial relator
Having looked more closely at your sample data and intended output I'm don't think you've accurately defined how you want things to be dissolved. On the right you have shown 3 polygons dissolved together but none of the original polygons would be described as entirely within?
I think the problem is what you think entirely within is not in fact entirely within. It shouldn't matter if there is a point where shapes touch or have a coincident boundary. The smaller square would be dissolved into the larger square in this scenario
Unfortunately, if there are very tiny overlaps it makes your process more problematic, as you then have to evaluate if 99.9% of the area of the polygon is within another.
You could try applying a negative buffer to your suppliers before a spatial relator
That very well could be as it is possible that some of the objects do in fact slightly slip outside of the larger polygon. I will give your solution a go after running another possible solution. Thanks!
That very well could be as it is possible that some of the objects do in fact slightly slip outside of the larger polygon. I will give your solution a go after running another possible solution. Thanks!
Using the GeographicBufferer did indeed help a little more with a buffer at -5 for my dataset. Going beyond that caused issues with creating donuts. So down from 192 to 165. Can't help but think someone has run into a geometric issue like this before. Possibly dissolve all and just chop it, though I imagine the resources necessary to do that are substantial for the full dataset. I also think that could cause more validation issues but I am running it to see.
to look for within and not touching, you need to query the cardinality or the d9im matrix.
First one is easiest.
Set calculate cardinality = yes.
Concatenate the _relationships list{}.card_line and card_area with no separator.
Then test card_area concatenation >0 && car_line = 0
to look for within and not touching, you need to query the cardinality or the d9im matrix.
First one is easiest.
Set calculate cardinality = yes.
Concatenate the _relationships list{}.card_line and card_area with no separator.
Then test card_area concatenation >0 && car_line = 0
Within & Not Touching is the easy one and SpatialRelator does that. However, I am needing ENTIRELY WITHIN & TOUCHING. As egomm stated, if it slightly goes over I can buffer it back slightly but it is still possible that it is touching.
@bkingston
The predicates EQUAL,WITHIN AND CONTAIN are always met, as the requestor = supplier.
This is an issue for your query.
The help file pertaining this transformer sates:
Contains:
The interiors intersect and no part of the candidate's interior or boundary intersects the base's exterior. It is possible for the boundaries to intersect.
and
Within:
The interiors intersect and no part of the base's interior or boundary intersects the candidate's exterior. It is possible for the boundaries to intersect.
If you set calculate cardinality = yes and list concatenate relationships{}pass.
and select all predicates except EQUALS,CONTAINS, WITHIN, and INTERSECT.
And then use a stringsearcher to lok for TOUCHES, you will see none have this relationships.
None of them touch in your sample data.
You can also test this by using a LineOnAreaOverlayer.
Use a counter to ID the objects. Coerce to line a stream for the line input and have it make a list.
Remove duplicate ID' from the list (ListDuplicateRemover). Count the resulting element (Listelementcounter) And then test for elementcount>2.
You get al the touching line pieces, where it is not only their own boundary.
IT seems you have no adequate criterion to do what you want on the sample data. Maybe step back and start form the original data? The posted data is/seems already dissolved or buffered with a buffer size that is too large for this.
@bkingston
The predicates EQUAL,WITHIN AND CONTAIN are always met, as the requestor = supplier.
This is an issue for your query.
The help file pertaining this transformer sates:
Contains:
The interiors intersect and no part of the candidate's interior or boundary intersects the base's exterior. It is possible for the boundaries to intersect.
and
Within:
The interiors intersect and no part of the base's interior or boundary intersects the candidate's exterior. It is possible for the boundaries to intersect.
If you set calculate cardinality = yes and list concatenate relationships{}pass.
and select all predicates except EQUALS,CONTAINS, WITHIN, and INTERSECT.
And then use a stringsearcher to lok for TOUCHES, you will see none have this relationships.
None of them touch in your sample data.
You can also test this by using a LineOnAreaOverlayer.
Use a counter to ID the objects. Coerce to line a stream for the line input and have it make a list.
Remove duplicate ID' from the list (ListDuplicateRemover). Count the resulting element (Listelementcounter) And then test for elementcount>2.
You get al the touching line pieces, where it is not only their own boundary.
IT seems you have no adequate criterion to do what you want on the sample data. Maybe step back and start form the original data? The posted data is/seems already dissolved or buffered with a buffer size that is too large for this.
I think that is going to be necessary to revisit the original data which is a real mess! Thanks for the info. There is a good chance that all of the suggestions here will be used in one way or another in new workspaces. I appreciate all of the suggestions given!
