FileGDB driver corrupting geometries when converting with ogr2ogr / Lack of MULTIPATCH support for shapefile export

[hugol]

When converting a GDB layer containing triangles (2.5D geometries) to a shapefile, some geometries get corrupted, ie some triangles contain >4 points and sometimes inner rings.

The file use is there (sorry it's big, I don't have access to ArcGIS now to isolate the issue): ​https://www.dropbox.com/s/ykow18oute35byv/25ez1.gdb.zip?dl=0

and the layer is “terreinVlak_3D_LOD0”

If I do: ogr2ogr v1112 25ez1.gdb/ terreinVlak_3D_LOD0

then, as can be seen in that screenshot (this is only one example, that file contains 608 invalid triangles), the geometry with TOP10_ID="107838021" has corrupted triangles (these are multi but if you explode them you get triangles with inner rings)

If I export the same GDB with ArcGIS, I do not get these: ​https://dl.dropboxusercontent.com/s/esq5ylinlztg087/2015-03-24%20at%2017.32.png?dl=0

I have GDAL v1.11.2 under Mac OS X from KyngChaos.

[Jukka Rahkonen]

I can't reproduce with Windows 7 and GDAL-dev.

I converted the test db into OpenJUMP format

ogr2ogr -f jml test.jml 25ez1.gdb terreinVlak_3D_LOD0

Opened data in OpenJUMP, selected features with TOP10_ID="107838021", found 3. Exploded multipolygons, got 430 simple polygons. Analysed the exploded layer and the result is that all polygons have 4 vertices.

I do not know if my method is correct, though.

[Even Rouault]

I don't reproduce any invalid geometries directly on the GDB itself, i.e. the output of the following only shows 3 MULTIPOLYGONs made of 4 point POLYGONs. Could you check it too :

ogrinfo 25ez1.gdb.zip terreinVlak_3D_LOD0 -where "TOP10_ID='107838021'" -geom=summary

Once converted into shapefile, a few inner rings appear. This is due to reconstruction to valid single feature geometry done in the shapefile reader. Likely due to the data itself. When displayed in QGIS, there are 4 holes in the triangle set.

If converted to GML instead, no topology work is done, so the MULTIPOLYGONs made of 4 point POLYGONs remain unchanged and look OK in QGIS. Could you attach the output of the following?:

ogr2ogr -f GML out.gml terreinVlak_3D_LOD0 -where "TOP10_ID='107838021'"

The export done with ArcGIS (to shapefile?) would also be interesting.

[hugol]

Indeed, I too get only polygons with 4 points with ogrinfo. (thanks for showing me features of ogrinfo that I didn't know about btw)

And the output to GML is indeed valid: ​https://www.dropbox.com/s/jwq9rbntpox96a6/out.gml?dl=0 If I use OGR to convert this to a SHP then you get invalid geometries (I guess that was expected, wasn't it?)

The output from ArcGIS is there: ​https://www.dropbox.com/s/2jxodxqoeoigo4x/fromarcgis.zip?dl=0 I don't remember how I did it, I guess I just clicked File/Export or something like that.

[Even Rouault]

OK, I understand. The shape exported by ArcGIS contains MultiPatch geometries made of OuterRing objects, similarly to what is found in the FileGDB.

OGR has no representation for such a geometry, so when reading the FileGDB it just builds a MultiPolygon made of each ring(triangles in practice). When writing the shape, this will be written as a SHPT_POLYGONZ When reading the shape, the default algorithm will reconstruct a Single Feature compliant geometry from the set of rings by analyzing their topological relationships (since inner/outer rings in shapefiles can be in somewhat random orders, depending on the writer application). But this is meant for 2D/2D5, and here I suspect that some of the faces are overlapping once projected onto the plan, hence holes when.

A potential solution would be to have a creation option in the shapefile driver to write a SHPT_MULTIPATCH instead of a SHPT_POLYGON/SHPT_POLYGONZ

In the meantime, use other formats like GML / Spatialite /GPKG when converting from FileGDB, since they will not attempt to do the topological analysis like it is done in the shapefile driver.

[hugol]

Many thanks for this, yes indeed in that dataset the terrain is not per se 2.5D but has vertical triangles (potentially).

I believe that writing to SHPT_MULTIPATCH would indeed be the best solution (I would have expected OGR to do this by default), but writing to GML or spatiallite in the meantime is fine.

Cheers!

[Jukka Rahkonen]

While waiting for the fix (or gathering funding for getting some more speed into it) there is a workaround. You can convert data first into OpenJUMP JML with ogr2ogr, open file with OpenJUMP and save into shapefile. File is correct and opens in QGIS.

It seems that at least old Geotools versions can not open shapefiles of type 31 (multipatch) so creating such when it comes possible may lead to problems with interoperability. That does not matter if you know to whom you are delivering data.

[Even Rouault]

I think OpenJUMP doesn't try to be clever when writing a multipolygon and preserve the winding order of the original shape, which makes things "work" here...

So here's an emulation of that behaviour that fixes the problem with the input dataset of that ticket:

trunk r28775 "Shape: add SHAPE_REWIND_ON_WRITE configuration option that can be set to NO to disable correction of ring winding order on write. Usefull when dealing with MultiPolygon that are MultiPatch objects in fact (#5888)"

ogr2ogr out_norewind.shp 25ez1.gdb.zip terreinVlak_3D_LOD0 -where "TOP10_ID='107838021'" -overwrite --config SHAPE_REWIND_ON_WRITE NO

[Jukka Rahkonen]

What I did was to write JML out from the geodatabase with ogr2ogr. After reading the JML into OpenJUMP I used the QA tool which has a check for polygon orientation and no errors were found. To be sure I exploded the multipolygon into parts and still no errors. To be sure that this test works I created a multipolygon with one clockwise and one counter-clockwise shell and the test does report the multipolygon as faulty. Further on, I saved this faulty geometry into JML and read it back. Writing-reading does not change geometry and it is still faulty.

Conclusion: OpenJUMP does not seem to sanitize geometries when it is reading them from shp or JML. Ogr2ogr seems to write all polygons parts of this MultiPatch into a multipolygon in JML format with right ring orientation because they appear right in OpenJUMP. Perhaps the holes in shp written by ogr2ogr are something specific to shp driver.

[Even Rouault]

Conclusion: OpenJUMP does not seem to sanitize geometries when it is reading them from shp or JML. Ogr2ogr seems to write all polygons parts of this MultiPatch into a multipolygon in JML format with right ring orientation because they appear right in OpenJUMP.

The OpenFileGDB driver will take the rings of a multipatch as they are described in the .gdb without doing any change of winding order, and the OGR JML writer will not do any further change. So basically what you get in the JML is the "raw" MultiPatch represented as a MultiPolygon.

Perhaps the holes in shp written by ogr2ogr are something specific to shp driver.

Yes, the shapefile writer will do its best to write SHP_MULTIPOLYGON conformant with the shapefile specification and will analyze which rings are inner rings vs outer rings. Which does not work very well with a 3D Patch... Hence the SHAPE_REWIND_ON_WRITE=NO config option as a hack to disable this, and behave similarly to other drivers.

[Even Rouault]

In 37643:

OpenFileGDB: improve detection of some form of TINs from MULTIPATCH, and for MultiPatch layers, try to select a better geometry type for those layers (refs #5888)

[Even Rouault]

This ticket has been automatically closed because Trac is no longer used for GDAL bug tracking, since the project has migrated to GitHub. If you believe this ticket is still valid, you may file it to ​https://github.com/OSGeo/gdal/issues if it is not already reported there.