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?

Improve this question
4
  • 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? Commented Jun 3, 2016 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. Commented Jun 3, 2016 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? Commented Jun 3, 2016 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. Commented Jun 3, 2016 at 0:19

2 Answers 2

Reset to default
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.

Improve this answer
2
  • 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. Commented Jun 3, 2016 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. Commented Jun 3, 2016 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?

Improve this answer
2
  • 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. Commented Jun 3, 2016 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" Commented Jun 3, 2016 at 1:19

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.