Check Geometry not finding invalid self-touching polygons

[MartinDavis]

I have a dataset with over 24M polygons in it, which I need to load into SDE.  I am using FME to perform the load.  The load fails due to some polygons having invalid structure according to ESRI rules.  The invalid polygons consist of an outer shell and holes which touch the shell at a single point.  This is invalid according to the ESRI polygon structure rules (which I have seen documentation for, but can't find a link for right now).  Instead, according to the ESRI rules these kinds of area should be formed as "inverted polygons".

The attached screenshot shows an example of an invalid polygon.

Because of the large size of the dataset, I need an automated way to detect and fix these invalid polygons.  The obvious tool to do this is Check Geometry and Repair Geometry.The problem is that Check Geometry does not identify these polygons.  Also, Repair Geometry does not repair them. 

Is this a bug in Check Geometry? 
Is Check Geometry expected to work on FGDBs?
Is there another way of detecting and fixing these polygons?

I'm running ArcGIS 10.

[SandyLyle]

Thought I'd throw another factor into the pot of thngs to think of.
Database precision can be a problem. We use FME (so much faster and flexible for so many things) but had some trouble with the repair geometry tool and using FME to do the fixes brought some problems with DB precision.

[MitaHajirakar]

Hi Martin,

Thanks for also notifying Safe Software of the problem.  We did some testing and found that sending that feature through an AreaBuilder make it load successfully to ArcSDE.  Another option for you anyways.

Kind regards,
Mita Hajirakar
Safe Software Inc.

[KenHartling]

We've taken a look at the "offending" features that will not load to ArcSDE using FME, here's what we have found.

1. The features are simple (meaning valid). 
2. Using all ArcGIS data loading tools these features successfully load to ArcSDE.
3. ArcSDE's geometry validation routines are slightly different than GDB validation. See ArcSDE validation rules: http://edndoc.esri.com/arcsde/9.2/concepts/geometry/shapes/verificationrules.htm
4. The recommended workflow that should be used to take care of this difference is for 3rd party developers to use SE_generate_from_binary or SgShapeFromBinary to import a simple polygon and make it valid for SDE.

In summary, it appears that FME is not using SE_generate_from_binary or SgShapeFromBinary when loading features to ArcSDE.

Ken

[JeffKruys]

In following up on this self-same problem, I've just stumbled on something. Inverted polygons (ie. polygons with a hole that shares a vertex with the outer shell) that are stored in the FGDB with the SDE-invalid vertex ordering seem to have their vertices rearranged and made SDE-valid by the following:

• In an FGDB, create a feature dataset and import the feature class into it


• Create a topology that acts on the feature class -- no topology rules are necessary


• Validate the topology

See the attached FGDB containing a few polygons before and after the process.

Is this behaviour expected? Are there any potential dangers, eg. could polygon geometries be modified in ways I'm not expecting? I haven't run my entire polygon feature class through this process yet, but I expect this will work on all of the problem polygons I have, and thus solve the problem by fixing the polygons in the FGDB before FME has a chance to choke on them while transferring them to SDE.

[KenHartling]

From the ValidateTopology tool doc:
Validate Topology performs the following operations:
    Cracking and clustering of feature vertices to find features that share geometry (have common coordinates)
    Inserting common coordinate vertices into features that share geometry
    Running a set of integrity checks to identify any violations of the rules that have been defined for the topology

So there are possible modifications to your features.  I'd suggest reading the Topology topic at the bottom of the ValidateTopology tool documentation to determine if the changes made to the features are acceptable for your workflow.

Ken