[WIP] Add new OGR driver for OpenDRIVE (XODR)

[michikommader]

What does this PR do?

This adds a read-only vector driver for the road description format OpenDRIVE. OpenDRIVE is an open industry standard in the automotive domain of driving simulation, maintained by ASAM e.V. It is increasingly intersecting with the public and GIS domains which raises the need for better interoperability with open-source spatial tools.

• This XODR driver is developed by German Aerospace Center (DLR) and licenced under MIT.
• This XODR driver implementation uses libOpenDRIVE which is licenced under Apache 2.0.
• This XODR driver is supposed to be used as plug-in.

I am am open to a fruitful discussion in order to make OpenDRIVE directly usable through GDAL. The context for this development has been introduced on FOSSGIS conference 2024: OpenDRIVE-HD-Karten mittels GDAL ins GIS bringen. Additional talks are planned for Geospatial World Forum and FOSS4G Europe 2024.

What are related issues/pull requests?

Tasklist

• [x] Make sure newly added files are correctly formatted (cf pre-commit configuration)
• [x] Add test case(s)
• [x] Add documentation
• [x] ~~Updated Python API documentation (swig/include/python/docs/)~~ I see no necessity there for adding a new driver
• [x] Clarify handling of custom docker/ubuntu-small/DockerfileXODR with GDAL maintainers: Which file location is better suited for future maintenance – the driver's source code directory or a separate repository?
• [ ] Review
• [ ] Adjust for comments
• [ ] All CI builds and checks have passed

Environment

Provide environment details, if relevant:

• OS: tested with Ubuntu 22.04, Windows 10
• Compiler: GCC on Linux, GCC 13.1.0 x86_64 (MCF threads) MinGW-w64 MSVCRT on Windows

[rouault]

Is the some packaging of libopendrive in Debian, conda-forge, etc ?

[rouault]

@michikommader Do you plan any further work on this any time soon ? I'm asking as I'm trying to keep the list of opened PRs low, and if something is not going to progress for some time, it is better to close the PR, and re-open it later when work restart

[michikommader]

@michikommader Do you plan any further work on this any time soon ?

Apologies for my inactivity. Yes, we already went through some of your valuable remarks internally but did not review and push changes yet. I plan to supply all the missing information in the first week of May.

[michikommader]

Is the some packaging of libopendrive in Debian, conda-forge, etc ?

Not yet. I myself am not maintainer of libOpenDRIVE and would rather see packaging responsibility on the maintainer side. We can separately discuss if our institute could take over this task. Also, ASAM e. V. as standardisation organisation behind OpenDRIVE could have an interest in that.

[michikommader]

Do you know how your driver (and libopendrive) is robust to corrupted / hostile datasets? At the very minimum, I'd like to see a test with a "random file" that has xodr extension, but isn't valid XODR file.

libOpenDRIVE forwards XML data loading directly to pugixml. According to pugixml's exception guarantees "most pugixml functions have a no-throw exception guarantee". For handling parsing errors the xml_parse_result would have to be inspected for its xml_parse_status. But, from GDAL driver side we do not have access to that. Unfortunately, libOpenDRIVE itself only uses simple printf() statements to report possible problems.

At least, libOpenDRIVE gives access to the parsed pugi::xml_document. Checking for the availability of "expected OpenDRIVE XML nodes" would allow basic validation if the parsing was successful. But, I don't see this as a very practicable way. If the dataset was corrupted "somewhere in the middle", pugixml would still have successfully parsed all previous content and made this accessible to the caller. For our use case of ensuring robustness in GDAL, I see this as a major deficit. The best solution would be to extend libOpenDRIVE to allow at least access to pugixml's xml_parse_status with which we could implement a somewhat meaningful error handling. I sent a pull request to the maintainer.

[michikommader]

I'll focus on satisfying cppcheck_2004 next days.

[coveralls]

coverage: 69.225% (+0.02%) from 69.21% when pulling 4280011fd4c35e39dd73c8737b235efda0daff18 on DLR-TS:libopendrive-pr into da83066ec9a8ddafc366153eb786d65cecce8c46 on OSGeo:master.

[rouault]

I have to set it to 16.1.0-1 in order to successfully build the Ubuntu 24.04 Docker image.

yes, you've well done. The version has to be bumped regularly

[rouault]

@michikommader Do you mind rebasing on top of latest master? I've cherry-picked the change for ARROW_VERSION. And you'll have to do a few changes in your CMakeLists.txt file as well as the ogrxdrdrivercore.h due to the changes of https://github.com/OSGeo/gdal/pull/10068 that has just been merged. See https://github.com/OSGeo/gdal/pull/10068/commits/1cd120fcb7313ee417152bb1006c6c467d00caff as an example of the changes you'll have to do: adding NO_SHARED_SYMBOL_WITH_CORE, using #define FOO PLUGIN_SYMBOL_NAME(FOO) and removing CPL_DLL.

[rouault]

@michikommader Anything left on your side before merging this PR ? It looks good to me (the CI failures are unrelated)

[michikommader]

@michikommader Anything left on your side before merging this PR ? It looks good to me (the CI failures are unrelated)

I will today commit a small simplification regarding your last suggestions with MakeValid().

[michikommader]

@michikommader Anything left on your side before merging this PR ? It looks good to me (the CI failures are unrelated)

From my side, there is nothing more to add. The driver is well usable in practical applications.

As next steps, I will look into providing ready-to-use binary releases of the libOpenDRIVE dependency. If development of libOpenDRIVE progresses with new features, this XODR driver might require adjustments. I would prepare theses as pull requests in a similar manner here.

Thank you for your patience and guidance for making this driver part of GDAL!

[rouault]

I've refreshed the master Docker images, so "ghcr.io/osgeo/gdal:ubuntu-full-latest" and "ghcr.io/osgeo/gdal:alpine-normal-latest" contain the driver

[dbaston]

Should a FindOpenDrive.cmake file be added to avoid the following output in the cmake configure step?

CMake Warning at cmake/helpers/CheckDependentLibraries.cmake:149 (find_package):
  By not providing "FindOpenDrive.cmake" in CMAKE_MODULE_PATH this project
  has asked CMake to find a package configuration file provided by
  "OpenDrive", but CMake did not find one.

  Could not find a package configuration file provided by "OpenDrive" with
  any of the following names:

    OpenDriveConfig.cmake
    opendrive-config.cmake

  Add the installation prefix of "OpenDrive" to CMAKE_PREFIX_PATH or set
  "OpenDrive_DIR" to a directory containing one of the above files.  If
  "OpenDrive" provides a separate development package or SDK, be sure it has
  been installed.
Call Stack (most recent call first):
  cmake/helpers/CheckDependentLibraries.cmake:807 (gdal_check_package)
  gdal.cmake:261 (include)
  CMakeLists.txt:240 (include)

https://github.com/OSGeo/gdal/actions/runs/9569105782/job/26380878179#step:13:361

[rouault]

Should a FindOpenDrive.cmake file be added to avoid the following output in the cmake configure step?

we want to avoid creating new Find cmake files when possible. Here it is not necessary as opendrive comes with CMake config files. Hence https://github.com/OSGeo/gdal/pull/10391 should fix it