Unless you used an 8.0 build of ArcGIS Desktop, the shapefile is probably properly constructed, which means that the root problem may be with the target database not properly handling an inversion.
In figure 1, the shape is represented two rings:
Ring1: A, B, C, D, E, F, A
Ring2: G, H, I, C, G
When ArcGIS inserts the original shape through the ArcSDE SgShape API, the geometry is validated. This process flips the right-hand rule of shapefiles to left-hand rule, and when an inversion is found, the inversion is folded into the parent ring (Figure 2):
Ring1: A, F, E, D, C, I, H, G, C, B, A
When the shape is exported to shapefile, the order is again flipped (Figure 3):
Ring1: A, B, C, G, H, I, C, D, E, F, A
Looking at an od
dump of the shapefile, we see this is how it is written:
C:\Temp>od -t x1 gse.shp
0000000 00 00 27 0a 00 00 00 00 00 00 00 00 00 00 00 00 | 100-byte Header
0000020 00 00 00 00 00 00 00 00 00 00 00 a6 e8 03 00 00
0000040 05 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0000060 00 00 00 00 00 00 00 00 00 00 20 40 00 00 00 00
0000100 00 00 20 40 00 00 00 00 00 00 00 00 00 00 00 00
0000120 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0000140 00 00 00 00
---0140 00 00 00 01 | Recno (1)
---0140 00 00 00 70 | Length (112 shorts)
---0140 05 00 00 00 | Shape type (poly)
0000160 00 00 00 00 00 00 00 00 | LLx (0.0)
---0160 00 00 00 00 00 00 00 00 | LLy (0.0)
0000200 00 00 00 00 00 00 20 40 | URx (8.0)
---0200 00 00 00 00 00 00 20 40 | URy (8.0)
0000220 01 00 00 00 | NumParts (1)
---0220 0b 00 00 00 | NumPoints (11)
---0220 00 00 00 00 | Ring1 start (0)
---0220 00 00 00 00 | PtAx,y (0.0,8.0)
0000240 00 00 00 00 00 00 00 00 00 00 20 40
---0240 00 00 00 00 | PtBx,y (6.0,8.0)
0000260 00 00 18 40 00 00 00 00 00 00 20 40
---0260 00 00 00 00 | PtCx,y (6.0,6.0)
0000300 00 00 18 40 00 00 00 00 00 00 18 40
---0300 00 00 00 00 | PtGx,y (4.0,6.0)
0000320 00 00 10 40 00 00 00 00 00 00 18 40
---0320 00 00 00 00 | PtHx,y (4.0,4.0)
0000340 00 00 10 40 00 00 00 00 00 00 10 40
---0340 00 00 00 00 | PtIx,y (6.0,4.0)
0000360 00 00 18 40 00 00 00 00 00 00 10 40
---0360 00 00 00 00 | PtCx,y (6.0,6.0)
0000400 00 00 18 40 00 00 00 00 00 00 18 40
---0400 00 00 00 00 | PtDx,y (8.0,6.0)
0000420 00 00 20 40 00 00 00 00 00 00 18 40
---0420 00 00 00 00 | PtEx,y (8.0,0.0)
0000440 00 00 20 40 00 00 00 00 00 00 00 00
---0440 00 00 00 00 | PtFx,y (0.0,0.0)
0000460 00 00 00 00 00 00 00 00 00 00 00 00
---0460 00 00 00 00 | PtAx,y (0.0,8.0)
0000500 00 00 00 00 00 00 00 00 00 00 20 40
So if the shapefile is correct, then the problem lies elsewhere.
It seems you have two choices (not mutually exclusive):
- Request that MongoDB's validation rules be modified to accept polygons with inversions
- Rewrite the shapefiles to be non-compliant, and hope that OGR will write the degenerate shape to GeoJSON in a layout that MongoDB will accept