id summary reporter owner description type status priority milestone component version severity resolution keywords cc 6917 ogr2ogr creates and writes malformed multipolygon in FileGDB bespin warmerdam "ogr2ogr takes valid multipolygon wkt from any source and writes out malformed multipart geometry when using the FileGDB driver. It moves the 2nd exterior ring into the 1st exterior ring as an interior ring. It does this regardless of the source wkt ring orientation. For example, Notice the movement of the () on the second feature part. Source MULTIPOLYGON (((12 0, 17 0, 17 5, 12 5, 12 0)), ((12 6, 17 6, 17 11, 12 11, 12 6))) is written out as MULTIPOLYGON (((12 0,12 5,17 5,17 0,12 0),(12 6,17 6,17 11,12 11,12 6))) I tested this in the following gdal/filegdb sdk versions. All on various versions of windows * 1.11.4/1.30.143 (http://www.lfd.uci.edu/~gohlke/pythonlibs/) * 2.1.3-2/1.4.0.183 (osgeo4w older) * 2.2.0-3/1.5.0.248 (osgeo4w current) Command : {{{ ogr2ogr -f ""FileGDB"" c:\temp\fgdbtest.gdb c:\temp\ring_test.json -nln ring_test_from_json_01 -nlt POLYGON -append }}} A similar test writing out to shp will yield correct results. {{{ ogr2ogr -f ""ESRI Shapefile"" c:\temp\ring_test_shp_from_json_01.shp c:\temp\ring_test.json -nln ring_test_from_json_01 -nlt POLYGON }}} use ogrinfo -al to compare the difference. Also, I am unable to recreate this using QGIS ""Save As"" or through python-ogr bindings by manually writing out a feature. It appears to be limited to ogr2ogr + the FileGDB writer. Attached is the geojson used in the examples. 3 of the 5 features are multipolygons, each with two exterior rings. All 3 have different ring orientation in the json but all will exhibit the same export behavior. " defect closed normal Utilities unspecified normal wontfix ogr2ogr, FileGDB, MULTIPOLYGON