Opened 7 years ago
Closed 7 years ago
#6917 closed defect (wontfix)
ogr2ogr creates and writes malformed multipolygon in FileGDB
Reported by: | bespin | Owned by: | warmerdam |
---|---|---|---|
Priority: | normal | Milestone: | |
Component: | Utilities | Version: | unspecified |
Severity: | normal | Keywords: | ogr2ogr, FileGDB, MULTIPOLYGON |
Cc: |
Description (last modified by )
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.
Attachments (1)
Change History (7)
by , 7 years ago
Attachment: | ring_test.json added |
---|
comment:1 by , 7 years ago
Description: | modified (diff) |
---|
comment:2 by , 7 years ago
comment:3 by , 7 years ago
Ok, I see the problem. My data source is mixed type. I use -sql so I'm forced to provide a -NLT TYPE. When writing shps I use -NLT POLYGON -NLT PROMOTE_TO_MULTI. I just copied the same logic to FGDB not remembering that FGDB can only have one type. For FGDB I should just use -NLT MULTIPOLYGON and drop the PROMOTE_TO_MULTI.
Thanks Even, I appreciate the work you do on this stuff. I use ogr2ogr with MSSQL and both FGDB drivers daily.
comment:5 by , 7 years ago
Closing this ticket.
I've documented the probably unexepcted behaviour of -nlt POLYGON
comment:6 by , 7 years ago
Resolution: | → wontfix |
---|---|
Status: | new → closed |
The reason is that you use the -nlt POLYGON flag that will force the multipolygon into a somehow invalid POLYGON. If you drop -nlt POLYGON or use -nlt MULTIPOLYGON, it will work fine.