0

System: Win 7, OSgeo4W package 64 bit (current to 3/12/17), GDAL 2.2.3

I have been provided with a polygon layer in ESRI FileGDB format (created in ArcMap v10.3 at least, maybe 10.4 or 10.4.1). The polygons in the layer have been digitised using a mix of straight line segments and bezier curves / true arcs, which I've verified in ArcMap by looking at the geometry in edit mode.

GDAL > 2.2.0 should be able to read and export CURVE-type geometries correctly (e.g. to GPKG, which can support those geometry types) but I can't get the export to work; e.g.

# OGR_SKIP just forces use of OpenFileGDB driver, but the
# same thing happens with either:

ogr2ogr --config OGR_SKIP FileGDB -f GPKG C:/DATA/output.gpkg C:/DATA/input.gdb LAYERNAME

still converts all the curves to a million tiny straight line segments. The output file size balloons to ~300MB (from an 8MB source file), making the data almost impossible to use. Even plotting is difficult, forget any further geometric ops. Trying to force the issue with -nlt CURVEPOLYGON has had no effect. Opening the layer in QGIS 2.18.14 produces the same results, as does import to R with sf::st_read (these two rely on GDAL 2.2.3 and 2.2.0 respectively to access GDBs).

ogrinfo reports the geometry type for the layer as Multi Polygon, as does QGIS - and even Arc itself reports them as 'Polygon' in its own Layer Properties interface, but I don't think the Feature Class definition distinguishes between different polygon types.

Is this a GDAL bug (eg driver mis-detecting geom type) or an Arc bug (eg some kind of failure to metadata properly)?

The gdb in question is at https://github.com/obrl-soil/bits-n-pieces/tree/master/curvepolys

Improve this question
1
  • 2
    I suggest to post your question also to gdal-dev mailing list.
    – user30184
    Commented Dec 4, 2017 at 8:03

1 Answer 1

Reset to default
0

The GDAL developer explains in https://lists.osgeo.org/pipermail/gdal-dev/2017-December/047841.html that Bezier curves can't be expressed as the OGC curve types because they support only arc type of curves. Therefore Bezier curves are split into straight segments.

The logic that GDAL used was to insert 100 interim vertices into lines which were modeled with Bezier curves. That was unreasonably high number and therefore the file size blasted for you. GDAL has now an enhanced logic since changeset https://trac.osgeo.org/gdal/changeset/40941.

I made a before-after test with your sample data by using command

ogr2ogr -f gpkg mapping.gpkg mapping.gdb -nlt multisurface

The difference in the file size of GeoPackage file is huge

before: 283 959 296 bytes
after:    9 080 832 bytes
Improve this answer
5
  • Thanks, I'm aware since I cross-posted per your advice. Was actually holding off on posting an answer until I'd had a chance to test it myself and compare with the within-ESRI method of export, which is to use tool Feature Class to Feature Class, with XY resolution and XY tolerance set to largish numbers. In my case, I used 0.1m and 10m, and got a file of ~3MB. Its pretty close to identical until one zooms in past 1:50. Even's solution is still better I think - no need to experiment with the XY settings to find ones that suit a particular file, it'll just work.
    – obrl_soil
    Commented Dec 5, 2017 at 10:42
  • If you are on Windows you can try already with builds with revision number >=40941 from gisinternals.com/development.php. Some MSVC builds are ready at the moment, some still building.
    – user30184
    Commented Dec 5, 2017 at 10:49
  • Yeah its in OSGeo4W now too, as of some time in the last four hours or so.
    – obrl_soil
    Commented Dec 5, 2017 at 10:54
  • If you would rather write your own answer I can delete mine.
    – user30184
    Commented Dec 5, 2017 at 11:05
  • 1
    Nah, with your slight rephrasing of the reply email I finally twigged that Bezier curves and simpler arcs are Not The Same. I'd assumed the former were just compound versions of the latter, which isn't really the case. Turns out that Beziers can only be approximated with circular arcs, and the computation involved looks like it could be slow. Some interesting reading here - pomax.github.io/bezierinfo/#arcapproximation
    – obrl_soil
    Commented Dec 5, 2017 at 11:24

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.