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

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

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)

ring_test.json (1.3 KB ) - added by bespin 7 years ago.

Download all attachments as: .zip

Change History (7)

by bespin, 7 years ago

Attachment: ring_test.json added

comment:1 by bespin, 7 years ago

Description: modified (diff)

comment:2 by Even Rouault, 7 years ago

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.

comment:3 by bespin, 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:4 by Even Rouault, 7 years ago

In 39404:

Doc: add words of caution when using -nlt POLYGON / forceToPolygon() from multipolygons (refs #6917)

comment:5 by Even Rouault, 7 years ago

Closing this ticket.

I've documented the probably unexepcted behaviour of -nlt POLYGON

comment:6 by Even Rouault, 7 years ago

Resolution: wontfix
Status: newclosed
Note: See TracTickets for help on using tickets.