2

I am having an issue loading a handful of GeoJSON files that were created from a shapefile export from SQLServer into MongoDB. This polygon will not load in MongoDB because of two duplicate vertices in the perimeter of the polygon. I noticed in our original data (before it was ever imported into SQLServer) the data had two rings; part 0 and part 1. Once the data is in SQLServer, it only has part 0, which is why I think MongoDB can't use this polygon. We are using ogr2ogr to convert the shapefiles to GeoJSON. Anyone happen to have a solution to this issue?

MongoDB Documentation: Polygons with Multiple Rings

For Polygons with multiple rings:

The first described ring must be the exterior ring.
The exterior ring cannot self-intersect.
Any interior ring must be entirely contained by the outer ring.
Interior rings cannot intersect or overlap each other. Interior rings cannot share an edge

View of stacked vertices in SDE

View of one vertex in part 0 from original shapefile before imported into SQLServer

View of one vertex in part 0 from original shapefile before imported into SQLServer

The first image shows the two stacked vertices exported from SQLServer. The next two images show the vertex in part 0 and the second vertex in part 1 of the original shapefile (before it went into SQLServer)

2
  • That's not two parts, it's two rings (exterior + interior) in a single part. Interior rings can touch at a point, just not along a line segment. In what database is the data stored (no data can be "in" ArcSDE, it only passes through ArcSDE connections)? What tool did you use to generate shapefiles? Please edit the question.
    – Vince
    Commented Feb 18, 2015 at 17:50
  • Thanks for helping me clarify. The data is stored in SQLServer and I exported the data from a feature class to a shapefile in ArcMap. Commented Feb 18, 2015 at 18:35

1 Answer 1

1

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

Figure1

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

Figure2

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

Figure3

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):

  1. Request that MongoDB's validation rules be modified to accept polygons with inversions
  2. 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

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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