Wrong OGR2OGR conversion

[vitali@…]

Wrong conversion to shapefile.

OGR2OGR utility converts vector data into shapefile in a wrong way. Here is a description of the problem.

I have a shapefile, for example with a polygon and two holes (see attached figure.jpg​, holes are numbered as hole 1 and hole 2).

Ordering is CW for exterior and CCW for interiors, see the shpdump for initial file:

Shapefile Type: Polygon   # of Shapes: 1

File Bounds: (       0.000,       0.000,0,0)
         to  (       5.000,       5.000,0,0)

Shape:0 (Polygon)  nVertices=15, nParts=3
  Bounds:(       0.000,       0.000, 0, 0)
      to (       5.000,       5.000, 0, 0)
     (       0.000,       0.000, 0, 0) Ring 
     (       0.000,       5.000, 0, 0)  
     (       5.000,       5.000, 0, 0)  
     (       5.000,       0.000, 0, 0)  
     (       0.000,       0.000, 0, 0)  
   + (       3.000,       2.000, 0, 0) Ring 
     (       2.000,       2.000, 0, 0)  
     (       2.000,       1.000, 0, 0)  
     (       3.000,       1.000, 0, 0)  
     (       3.000,       2.000, 0, 0)  
   + (       3.000,       2.000, 0, 0) Ring 
     (       4.000,       2.000, 0, 0)  
     (       4.000,       3.000, 0, 0)  
     (       3.000,       3.000, 0, 0)  
     (       3.000,       2.000, 0, 0)  

Now lets convert this file from SHP to SHP (Initially I got that bug after converting from TAB to SHP, but it doesn’t matter, bug is present when converting from SHP to SHP).

After convertation shpdump gives the next result:

Shapefile Type: Polygon   # of Shapes: 1

File Bounds: (       0.000,       0.000,0,0)
         to  (       5.000,       5.000,0,0)

Shape:0 (Polygon)  nVertices=15, nParts=3
  Bounds:(       0.000,       0.000, 0, 0)
      to (       5.000,       5.000, 0, 0)
     (       0.000,       0.000, 0, 0) Ring 
     (       0.000,       5.000, 0, 0)  
     (       5.000,       5.000, 0, 0)  
     (       5.000,       0.000, 0, 0)  
     (       0.000,       0.000, 0, 0)  
   + (       3.000,       2.000, 0, 0) Ring 
     (       2.000,       2.000, 0, 0)  
     (       2.000,       1.000, 0, 0)  
     (       3.000,       1.000, 0, 0)  
     (       3.000,       2.000, 0, 0)  
   + (       3.000,       2.000, 0, 0) Ring 
     (       3.000,       3.000, 0, 0)  
     (       4.000,       3.000, 0, 0)  
     (       4.000,       2.000, 0, 0)  
     (       3.000,       2.000, 0, 0)  

As you see the hole 2 becomes a usual polygon because of CW coordinate sequence ordering after conversion, but in initial file it was a hole with CCW ordering!!!

So, my deduction is the bug appears during OGR2OGR conversion when in initial data two holes touch each other in one polygon or multipolygon....

This wrong behaviour is quite critical for java shapefile library for example. It considers this wrong ring as a polygon in multipolygon, not as a hole in polygon.

See the test_data.zip package attached:

• touched_holes.shp – initial valid file
• touched_holes_OGR.shp - after OGR2OGR conversion with wrong geometries

---

Vitali Diatchkov Oy Arbonaut LTD Finland

[warmerdam]

Mateusz,

There is quite a block of code in the the Shapefile OGR driver for analysing the rings in a shapefile polygon to determine which are inner or outer rings. I think this logic is failing in the quoted situation.

I think we have lost the external url in the bugzilla to trac conversion, but you can dig it out of the bugzilla database which should still be online.

[Mateusz Łoskot]

I suppose this issue may be related to the Ticket #1217 in some way.

[Mateusz Łoskot]

I contacted Vitali directly asking for files that he mentioned in the report but are missing.

[Mateusz Łoskot]

Package with test data

[Mateusz Łoskot]

Picture presenting polygon with holes