3D geometries from a CSV file to a DXF no longer works with version 3.8

[namotec]

Expected behavior and actual behavior.

The creation of polynomial 3D geometries from a CSV file to a DXF no longer works with version 3.8.

Version 3.2 worked well in the past. Here, too, there were minor errors with inclined polynomial surfaces. See the example of the circular pipe element.

Perhaps I am using the syntax for the ogr2ogr command incorrectly. I would be grateful for any advice.

Kind regards

Steps to reproduce the problem.

An example can be found in the appendix. The Makefile contains the commands I used.

2024.01.07 output.error - dxf only 2d with polygon .tar.7z.zip

Operating system

chris@ber24:~$ inxi -SMrb

System: Host: ber24 Kernel: 5.10.0-26-amd64 x86_64 bits: 64 Desktop: Cinnamon 5.6.8 Distro: LMDE 5 Elsie Machine: Type: Laptop System: Medion product: P7815 v: 1.0 serial: Mobo: Medion model: P7815 v: 1.0 serial: UEFI: American Megatrends v: 504 date: 09/29/2012 CPU: Info: Quad Core Intel Core i7-3632QM [MT MCP] speed: 2178 MHz min/max: 1200/3200 MHz Graphics: Device-1: Intel 3rd Gen Core processor Graphics driver: i915 v: kernel Device-2: NVIDIA GK107M [GeForce GT 640M] driver: nvidia v: 470.199.02 Display: x11 server: X.Org 1.20.11 driver: loaded: modesetting,nouveau unloaded: fbdev,vesa resolution: 1920x1080~60Hz OpenGL: renderer: Mesa DRI Intel HD Graphics 4000 (IVB GT2) v: 4.2 Mesa 20.3.5 Network: Device-1: Intel Centrino Wireless-N 2230 driver: iwlwifi Device-2: Realtek RTL8111/8168/8411 PCI Express Gigabit Ethernet driver: r8169 Drives: Local Storage: total: 14.26 TiB used: 6.72 TiB (47.1%) Repos: No active apt repos in: /etc/apt/sources.list Active apt repos in: /etc/apt/sources.list.d/official-package-repositories.list 1: deb http://packages.linuxmint.com elsie main upstream import backport #id:linuxmint_main 2: deb https://deb.debian.org/debian bullseye main contrib non-free 3: deb https://deb.debian.org/debian bullseye-updates main contrib non-free 4: deb http://security.debian.org bullseye-security main contrib non-free 5: deb https://deb.debian.org/debian bullseye-backports main contrib non-free Active apt repos in: /etc/apt/sources.list.d/qgis.sources 1: deb deb-src [arch=amd64] https://qgis.org/debian bullseye main Active apt repos in: /etc/apt/sources.list.d/winehq-bullseye.sources 1: deb [arch=amd64 i386] https://dl.winehq.org/wine-builds/debian bullseye main Info: Processes: 323 Uptime: 2d 18h 46m Memory: 7.64 GiB used: 3.47 GiB (45.4%) Shell: Bash inxi: 3.3.01

GDAL version and provenance

GDAL 3.2.2, released 2021/03/05 (nativ) GDAL 3.8.2, released 2023/16/12 installed with conda/micromamba {micromamba create -n gdal gdal pcraster -y -c conda-forge}

[rouault]

CC @atlight

[atlight]

I've done some cursory investigation here, and it seems that in current GDAL versions, you need to specify the parameter as -nlt POLYGONZ, explicitly requesting the inclusion of the Z coordinate. In 3.2, -nlt POLYGON and -nlt POLYGONZ do the same thing.

@rouault: Did this behaviour change in core ogr2ogr at some point between 3.2 and 3.8? I don't see any code changes in the DXF driver that could be responsible. The documentation only mentions changes to the -nlt parameter in versions 2.1 and 3.0.5.

[rouault]

Digging a bit into history, the behavior changed in 3.5.0 per 8ac04214257 which does a bit more than just the commit message . OGRGeometryFactory::forceTo() also takes into account the target dimensionality. So since that setting POLYGON force to a 2D polygon, which seems reasonable to me. Setting -nlt POLYGONZ in newer version is the way to go