Solved

How to turn fake holes into proper ones? Opposite of DonutBridgeBuilder?

  • 20 September 2018
  • 12 replies
  • 8 views
tim_wood
Rank
Badge +7

I have a polygon layer that has various geometry issues, mostly self-intersections. I have used the GeometryValidator to clean these up, but it has had the unfortunate consequence of filling in the holes. This is because they are not proper holes, but "fake" ones created by digitising a zero width corridor. So the hole boundary is actually part of the exterior boundary (highlighted in example below). The corridors are detected as self-intersections. Is there anything I can do to output the polygons with proper holes, or at least detect the polygons with fake holes so they can be edited manually? There are too many self-intersections reported by GeometryValidator to use for manually repairing the holes.

I've found this similar topic but I'm not quite sure if @offermann82 is looking for the same solution...

https://knowledge.safe.com/questions/59610/how-to-split-polygons-with-holes-that-touch-the-bo.html

I think I want the opposite of what DonutBridgeBuilder does...

https://docs.safe.com/fme/2018.0/html/FME_Desktop_Documentation/FME_Transformers/Transformers/donutbridgebuilder.htm

I'll try overlaying/comparing the unrepaired polygons with the repaired ones to try and catch the bits that have been filled in but I'm not sure if this will be affected by self-intersections and tiny geometry changes resulting from GeometryValidator repairs.

icon

Best answer by takashi 22 September 2018, 04:05

View original

12 replies

david_r
Rank
Userlevel 4

Here's one way to get rid of the yellow lines and get "proper" donuts:

  1. Counter to assign a unique id to each polygon
  2. Chopper with max 2 vertices
  3. AreaBuilder with group by on the counter value, drop donut holes set to yes

If you need to, you can then use the Matcher between the before/after polygons to see which ones changed as a result of this operation, which is maybe what you're looking for.

takashi
Rank
Userlevel 2
Badge +17

The GeometryValidator (Issue to Detect: Self-Intersections in 2D, Attempt Repair: Yes) could transform polygons with "fake holes" into donuts with "proper holes". Check the resulting features output via the Repaired port.

tim_wood
Rank
Badge +7

The GeometryValidator (Issue to Detect: Self-Intersections in 2D, Attempt Repair: Yes) could transform polygons with "fake holes" into donuts with "proper holes". Check the resulting features output via the Repaired port.

Repairing self-intersections in 2D is what is causing the holes to be filled in.

 

tim_wood
Rank
Badge +7

Here's one way to get rid of the yellow lines and get "proper" donuts:

  1. Counter to assign a unique id to each polygon
  2. Chopper with max 2 vertices
  3. AreaBuilder with group by on the counter value, drop donut holes set to yes

If you need to, you can then use the Matcher between the before/after polygons to see which ones changed as a result of this operation, which is maybe what you're looking for.

I've tried that but the output looks the same as the input.

 

takashi
Rank
Userlevel 2
Badge +17

The GeometryValidator (Issue to Detect: Self-Intersections in 2D, Attempt Repair: Yes) could transform polygons with "fake holes" into donuts with "proper holes". Check the resulting features output via the Repaired port.

Filling holes won't happen theoretically. There might be some other issues on the geometries. Could you please share a minimal sample data that contains the polygon features having "fake holes"?

 

 

tim_wood
Rank
Badge +7
Filling holes won't happen theoretically. There might be some other issues on the geometries. Could you please share a minimal sample data that contains the polygon features having "fake holes"?

 

 

I've attached an example polygon as Well Known Binary (WKB) and Well Known Text (WKT). The source data is an SQL Server table where the geometry is stored as WKB but in a varbinary(max) column, not a geometry type column. So to create the geometry in FME, I'm using a GeometryReplacer with Hex Encoded OGC Well Known Binary as the encoding format. The GeometryReplacer is not filling in the holes as I have written out the result to an FGDB before using GeometryValidator and the hole is still there.

 

polygon-with-holes-as-wkt.txt

 

polygon-with-holes-as-wkb.txt

 

ebygomm
Rank
Userlevel 1
Badge +10
Your geometry is actually 'twisted' - it's not just a case of it containing a zero width corridor.

 

 

The line shows the order of the points

 

 

 

 

ebygomm
Rank
Userlevel 1
Badge +10
Your geometry is actually 'twisted' - it's not just a case of it containing a zero width corridor.

 

 

The line shows the order of the points

 

 

 

 

tim_wood
Rank
Badge +7
Your geometry is actually 'twisted' - it's not just a case of it containing a zero width corridor.

 

 

The line shows the order of the points

 

 

 

 

Ah! Is that why it's getting filled in by the self-intersection repair?

 

I wondered if it might be possible to use an unrepaired version of the data to cut out the holes in the repaired version but that could also affect valid repairs....

 

takashi
Rank
Userlevel 2
Badge +17
@egomm is right. It's the reason why the GeometryValidator (Self-Intersections in 2D) repairs the geometry to fill the "fake holes". In this case, the GeometryValidator won't work as expected.

 

Further, the geometry has many duplicate consecutive vertices, and also there seems to be tiny gaps between the segments forming the "corridor". It's the reason why @david_r's method didn't work.

 

In order to clean the geometry up, consider adding the GeometryValidator (Issue to Detect: Duplicate Consecutive Points) and the Snapper to the workflow. e.g.

 

takashi
Rank
Userlevel 2
Badge +17
Your geometry is actually 'twisted' - it's not just a case of it containing a zero width corridor.

 

 

The line shows the order of the points

 

 

 

 

@egomm is right. It's the reason why the GeometryValidator (Self-Intersections in 2D) repairs the geometry to fill the "fake holes". In this case, the GeometryValidator won't work as expected.

 

Further, the geometry has many duplicate consecutive vertices, and also there seems to be tiny gaps between the segments forming the "corridor". It's the reason why @david_r's method didn't work.

 

In order to clean the geometry up, consider adding the GeometryValidator (Issue to Detect: Duplicate Consecutive Points) and the Snapper to the workflow. e.g.

 

tim_wood
Rank
Badge +7
@egomm is right. It's the reason why the GeometryValidator (Self-Intersections in 2D) repairs the geometry to fill the "fake holes". In this case, the GeometryValidator won't work as expected.

 

Further, the geometry has many duplicate consecutive vertices, and also there seems to be tiny gaps between the segments forming the "corridor". It's the reason why @david_r's method didn't work.

 

In order to clean the geometry up, consider adding the GeometryValidator (Issue to Detect: Duplicate Consecutive Points) and the Snapper to the workflow. e.g.

 

Thanks @takashi @egomm and @david_r that's fixed that example :-)

 

I think there's a bit more work for me to do to test this with other polygons in the same layer that don't have "fake" holes, but may have their own issues e.g. more typical self-intersections. It's a good lesson in A) digitising features properly; B) deciding whether you're going to get FME to fix issues or simply report them.

Reply


Community Stats

28,631
Posts
109,154
Replies
36,507
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.