“AreaOnAreaOverlayer” fails: “The spatial comparator received a feature with invalid geometry”,

Hi,

 

 

look at the blue warning-line in your logfile, 4 lines up...

 

 

David

 

 

 

Thanks David,

 

 

These Areas (72 polygons) are converted from the hatches of AutoCAD. These polygons are geometrically correct at the AutoCAD and the FME detects them properly when the “GeometryFilter” is used. The issue appears as the “AreaOnAreaOverlayer” is applied.

 

 

 

 

 

 

However, how the issue of “Feature contains invalid holes -- Holes must have at least 4 coordinates” can be fixed in the FME?

 

 

Is there any tool in the FME that can solve this issue?

I guess you could try the GeometryValidator.

 

 

If that doesn't work, you're probably in for a custom job using DonutHoleExtractor, CoordinateCounter, GeometryFilter/Coercer etc.

 

 

David

Despite the fact that my structure in the FME is quite simple, I couldn’t figure out why I should all these problems

 

 

Our daily work:

 

• The hatches of Landuse are converted to polygons

 

• The hatch of the Boundary is converted to polygons

 

• The Roads are extracted by subtracting the polygons of Landuse from the polygon of Boundary

 

 

Roads = Boundary – Landuse

 

 

 

All the commands fail to let the “clipper” to produce proper Roads

 

 

 

 

 

All the tools below fails to fix the issue and to let the “clipper” works are expected

 

 

 

 

 

what other approaches should I consider?

Hi Jamal,

 

 

 

The problem in this and your other posts are the hatches.

 

Hatches are build using either picking an interior point or picking boudnaries in Autocad.

 

This can lead to bad boundaries. A hatch does not need to have very tight boundary topology to get created, espescially when u hand pick border sections.

 

 

In most of your posted dwg's it is not possible to recreate the boundaries (except with (a lot) of manual labour).

 

I u study your dwg,s there are realy a lot of gaps, non-closed borders, crossings and overlaps.

 

 

Also different hatchtypes create geometric objects, again breaking boundary.

 

 

I would never use hatches as "polygons" if i can avoid it.

 

I use the boundary objects to create a closed boundary (actual closed boundaries. If u can join boundary lines in autocad, then it is closed, esl it is not). When i am done with all boundary, i check topology. That is, check wether they touch and not cross eachother, and of course no selfintersecitons.

 

U don't even need to turn those into areas or polygons using autoacad to use them in fme.

 

Thats how the inserted image was created, someone made the autocad files in sessions and i geometricaly and topology-wise corrected and perfected those.

 

The image has no gaps, overlaps, slivers or whatever, its perfect.

 

 

And you might know that there is a tool in Aurtocad to build actual polygons.

 

 

This metod is beter then using hatches.

 

I have had a lot of drawings with hatches to do some analysis on. Every time im forced to clean-up these.

 

 

This way when u finaly use clipping, there are no issues, slivers, dangles and other not wanted objects.

 

 

You have several topics on thes landuse/road issues. All suffer from badly matching objects.

 

 

My advice would be to prepare the data better before sending them to fme geometrical transformers.

 

 

Gio

 

City of Leiden

 

Thank you Gio for the very useful elaboration.

 

 

That you have already pointed out is correct. But the end we have tens of dwg files that we need to manipulate to extract the Roads.

 

 

The only approach that I have at the moment is:

 

 

1. to extract the Boundary and Landuse usinf FME (workbench)

 

 

 

 

 

 

 

 

 

2. to extract the Roads using the ArcGIS (model)

 

 

 

 

This way, I never face catastrophic problem like the ones I had.

 

 

I preferred to do all the work in the FME but it appears tremendous errors are generated.

CAD file:

 

http://www.mediafire.com/download/bgfdqa0go1drji7/Tamoun_Tubas_UrbanMasterPlan_02.dwg

 

 

transformers already applied to solve the issue (but fails)