4

I have an ArcGIS 10.2.2 for Desktop process which:

  1. Uses the Data Interoperability extension and the Feature Class To Feature Class tool to convert 88 MapInfo TAB files (with the same schema, representing different geographic areas) to 88 file geodatabase feature classes.
  2. Performs a Repair Geometry on each of those 88 feature classes
  3. Performs a Create Feature Class, Project Define (using one of the 88 feature classes as the spatial reference source) and then Append (with NOTEST) on those 88 feature classes to get a merged feature class. Note: I did not use the Merge tool because when I tried to do that only about 6 feature classes were merged before the tool reported that it had completed successfully.

The process appeared to work fine to create the merged feature class of 2.5 million polygons. However, when I ran Check Geometry on this feature class it started to report self intersections before appearing to hang and then failing with an ERROR 999999 five minutes later..

Executing: CheckGeometry C:\Temp\DCDB\Staging.gdb\DCDB C:\Temp\DCDB\RWC_CheckGeom.dbf
Start Time: Fri Jun 03 09:42:08 2016
WARNING 000442: self intersections at 883 in C:\Temp\DCDB\Staging.gdb\DCDB
WARNING 000442: self intersections at 1479 in C:\Temp\DCDB\Staging.gdb\DCDB
WARNING 000442: self intersections at 6003 in C:\Temp\DCDB\Staging.gdb\DCDB
WARNING 000442: self intersections at 6004 in C:\Temp\DCDB\Staging.gdb\DCDB
WARNING 000442: self intersections at 6015 in C:\Temp\DCDB\Staging.gdb\DCDB
WARNING 000442: self intersections at 6016 in C:\Temp\DCDB\Staging.gdb\DCDB
WARNING 000442: self intersections at 6417 in C:\Temp\DCDB\Staging.gdb\DCDB
WARNING 000442: self intersections at 7285 in C:\Temp\DCDB\Staging.gdb\DCDB
WARNING 000442: self intersections at 11813 in C:\Temp\DCDB\Staging.gdb\DCDB
WARNING 000442: self intersections at 12127 in C:\Temp\DCDB\Staging.gdb\DCDB
WARNING 000442: self intersections at 14861 in C:\Temp\DCDB\Staging.gdb\DCDB
WARNING 000442: self intersections at 16328 in C:\Temp\DCDB\Staging.gdb\DCDB
WARNING 000442: self intersections at 16847 in C:\Temp\DCDB\Staging.gdb\DCDB
WARNING 000442: self intersections at 16893 in C:\Temp\DCDB\Staging.gdb\DCDB
WARNING 000442: self intersections at 21008 in C:\Temp\DCDB\Staging.gdb\DCDB
WARNING 000442: self intersections at 22254 in C:\Temp\DCDB\Staging.gdb\DCDB
WARNING 000442: self intersections at 25064 in C:\Temp\DCDB\Staging.gdb\DCDB
WARNING 000442: self intersections at 26671 in C:\Temp\DCDB\Staging.gdb\DCDB
WARNING 000442: self intersections at 26872 in C:\Temp\DCDB\Staging.gdb\DCDB
WARNING 000442: self intersections at 27513 in C:\Temp\DCDB\Staging.gdb\DCDB
WARNING 000442: self intersections at 27521 in C:\Temp\DCDB\Staging.gdb\DCDB
WARNING 000442: self intersections at 27540 in C:\Temp\DCDB\Staging.gdb\DCDB
WARNING 000442: self intersections at 27579 in C:\Temp\DCDB\Staging.gdb\DCDB
WARNING 000442: self intersections at 27600 in C:\Temp\DCDB\Staging.gdb\DCDB
WARNING 000442: self intersections at 27603 in C:\Temp\DCDB\Staging.gdb\DCDB
ERROR 999999: Error executing function.
Failed to execute (CheckGeometry).
Failed at Fri Jun 03 09:47:19 2016 (Elapsed Time: 5 minutes 10 seconds)

Should appending polygon feature classes with already repaired geometry be expected to produce a feature class that can pass the Check Geometry test?

  • DCDB contains a lot of self-intersections due to misclose, do you have them as smaller blocks (by LGA?) It might be worth dividing the data, repairing the geometries and then merging back again... but you said you already have repaired them like this. Can you zoom to one of these supposed self-intersections and see it? – Michael Stimson Jun 3 '16 at 0:00
  • @MichaelMiles-Stimson They started as 88 smaller blocks (approx. by LGA with more blocks in Brisbane) that were repaired (and checked) in step before appending. – PolyGeo Jun 3 '16 at 0:02
  • Are you changing the spatial domain? It could be rounding from shapefiles (double) to GDB (int with offset / divisor) causing very close vertices to overlap. Are there near duplicate vertices in the source data? – Michael Stimson Jun 3 '16 at 0:08
  • @MichaelMiles-Stimson There's no shapefiles in the process. I'm not touching the spatial domain at the moment. When I export object 883 out into its own feature class and check its geometry it reports the same self intersection. I'm going to double-check the geometry of the input LGA that polygon came from now. – PolyGeo Jun 3 '16 at 0:19
6
+100

The Understanding Coordinate Management in the Geodatabase whitepaper is still the gold standard for understanding what's happening behind the scenes.

The key things to remember are:

  1. Esri coordinate references encompass far more than coordinate system
  2. The coordinate reference of a feature class cannot be changed
  3. If you let ArcGIS choose your coordinate reference by just selecting coordinate system, it will choose a resolution that equates to 1/10th of a millimeter

If you are using the right-click New -> Feature Class.. from a folder which is a file or enterprise geodatabase, the first page is the name and geometry type, the second is the coordinate system, and the third page is the Tolerance:

XY Tolerance

Notice the checkbox! If you uncheck the default, then the fourth page allows the XY Resolution to be set:

XY Resolution

Of course, if your feature class is 3D or Measured, then the tolerance and precision pages will also include Z and M values.

The equivalent process in Python works by customizing a SpatialReference then using that in the creation request:

sr = arcpy.SpatialReference(4326) 
sr.setFalseOriginAndUnits(-400.0,-400.0,10000000.0)
arcpy.CreateFeatureclass_management(connPath,tabName,
     'POLYGON',spatial_reference=‌​sr,config_keyword=dbtuneOpt)

The default tolerance when set by units is twice the multiplicative inverse of the scale.

  • Thanks Vince - I used a slight variant of this at gis.stackexchange.com/a/195930/115 and now seem to be getting what I need. I used GDA94 in place of 4326, and had no need for a config_keyword with a file geodatabase. – PolyGeo Jun 3 '16 at 3:14
  • I'm an enterprise geodatabase weenie, so if it applies to both, I'm going to go generic. I think FGDB will take a keyword, but ignores it. – Vince Jun 3 '16 at 3:17
0

There appears to be a flaw in my process because when I look at the first listed self-intersection (OBJECTID = 883) and draw the feature class it came from with the appended feature class there is clearly a case of polygons collapsing.

I will investigate things like the spatial domain suggested by @MichaelMiles-Stimson in his comment to see if I can resolve this.

enter image description here

The properties of the feature class (rwc_balonne; top) and appended feature class (RWC; bottom) look very suspicious:

enter image description here

enter image description here

For more information related to the issue(s) in this Q&A see Controlling XY Resolution on file geodatabase feature class output from Append?

  • 1
    Not "suspicious" as much as "wrong". Tolerances are used to compare vertices between feature classes. Resolution (aka precision) and its inverse, scale, are used to snap values to a grid for storage. In the second FC, the scale is 10000, while in the first, it's 111194877.919, but what's four orders of magnitude between friends? I recommend a uniform {-400,-400} origin and 0.0000001 resolution (1e+07 scale) for WGS84 GCSes, which gives ~1cm precision in angular units. – Vince Jun 3 '16 at 1:13
  • @Vince Is that something I can specify after Create Feature Class and Define Projection, and prior to Append? I'm roaming the help and other sources looking for how to gain control over that/those settings before I append in. I just did an unsuccessful test with arcpy.env.XYTolerance = "0.000000000899322 DecimalDegrees" – PolyGeo Jun 3 '16 at 1:19

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.