OpenFileGDB driver: polygon topology error

[gjsa73]

Expected behavior and actual behavior.

Opening roads_clip GDB layer
layer1.zip
in ArCGIS produces the correct topology with a network of roads/tracks displayed 10m wide:

Large areas in between roads/tracks are falsely identified and rendered in QGIS3 as features:

Note: FileGDB driver also results in the same topological error in QGIS3.

Steps to reproduce the problem.

Unzip layer1.zip and drag-and-drop "roads_clip Drawing.gdb" folder into QGIS3 map canvas (or open using the traditional method: Add layer -> Add Vector layer -> Directory/OpenFileGDB).

Operating system

Windows 10 Enterprise 64-Bit

GDAL version and provenance

2.4.0 (QGIS 3.7 Master).

[rouault]

Which software produced this dataset ? The polygon rings are not oriented according to the normal convention of outer rings = clockwise, innter ring = counter-clockwise

[gjsa73]

Manifold 9 produced the dataset. Is there a reason why ArcGIS can still resolve the layer correctly?

…

On Mon., 18 Mar. 2019, 10:43 am Even Rouault, ***@***.***> wrote: Which software produced this dataset ? The polygon rings are not oriented according to the normal convention of outer rings = clockwise, innter ring = counter-clockwise — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#1369 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AU-dNgpx7a9UxMWvpgY8d2uANjjyKHtqks5vXtMjgaJpZM4b4tSz> .

[rouault]

Is there a reason why ArcGIS cash still resolve the layer correctly?

Probably they use a less optimized way of reconstructing multipolygons than what we do in GDAL by default, or they have a different drawing algorithm. Anyway you can workaround the issue by setting OGR_ORGANIZE_POLYGONS=DEFAULT as environment variable. I've also a fix for that particular situation that doesn't require it in the works. Can the dataset to this issue be considered as freely usable and included in the GDAL autotest suite ?

[gjsa73]

Anyway you can workaround the issue by setting OGR_ORGANIZE_POLYGONS=DEFAULT as environment variable

Tried this and the problem remains. So I then did a Check Validity in QGIS3 on the layer and the only issue identified (besides self-intersections), was 'Nested shells'.

Running Fix geometries on the layer removed the 'Nested shells' because the error is no longer present on the fixed layer and the polygons are formed correctly.

So I'm now unsure if this is definitely or wholly related to the ring orientation as you suggested.

[rouault]

Regarding QGIS, I guess this might be due to it overriding this config option to ONLY_CCW in https://github.com/qgis/QGIS/blame/7757ffc5dd232b1be240984734e44282f390588a/src/providers/ogr/qgsogrprovider.cpp#L4265 . I don't think this is appropriate for QGIS to set that, at least without testing first if the configuration option is set. I'm going to create an issue about that

[rouault]

QGIS issue raised as https://issues.qgis.org/issues/21609