Proposal for a H2GIS Spatial Database Driver (via GraalVM native image)

[pierromond]

Feature description

Hi,

I am a developer and maintainer of NoiseModelling, an open-source tool for noise mapping that relies on H2GIS (a spatial extension of the H2 Database Engine) -> https://h2gis.org/

Currently, there is no direct way to open H2GIS databases in GDAL/QGIS without exporting data. I have developed a working prototype of a native GDAL/OGR driver for H2GIS, and I would like to submit it for review and potential integration.

I developed this driver with (very) significant assistance from AI tools to bridge the gap between my Java knowledge and the specificities of the GDAL C++ API. While the driver is functional and passes my local tests (loading layers in QGIS, running queries), I am aware that the C++ code quality, memory management, and adherence to GDAL style guidelines might need significant improvement ! I'm sorry, but since this plugin is very useful in my work, I decided to go ahead with it.

Code Repository
You can find the source code here:
[https://github.com/pierromond/H2GIS_gdalplugin](https://github.com/pierromond/H2GIS_gdalplugin)

What works:
Reading/Writing Vector layers.
Spatial filtering.

I am looking for:
Feedback on whether this "GraalVM bridge" architecture is acceptable for the GDAL ecosystem.
Help or guidance to clean up the C++ implementation to meet project standards.
Eventually, integration into the codebase if deemed valuable.

Thank you for your time and for this amazing library :)

Looking forward to your feedback!

Additional context

The Implementation Approach
Since H2GIS is pure Java and GDAL is C++, I used the new GraalVM Native Image to compile the H2GIS library into a shared library -> https://github.com/orbisgis/h2gis . The GDAL driver (C++) acts as a wrapper that talks to this native library via C-API entry points.

This architecture allows
Direct read/write access to H2GIS .mv.db files.
No JVM startup lag (thanks to native compilation).

[jratike80]

H2GIS itself is using GPL 3 license. GraalVM is using GFTC, and the community edition GPL 2 https://www.graalvm.org/faq/
Does your driver re-use any of the licensed H2GIS or GraalVM code, or could the driver be licensed as MIT?

[pierromond]

Thanks for this message! You're probably right. I think that due to a license incompatibility (MIT vs. GPL), the libh2gis.so backend cannot be integrated into standard GDAL distributions. Users may need to download the native H2GIS library separately and place it in their library path. Perhaps this is already done with other drivers?

As for the GraalVM runtime, I don't think it poses a problem because it only interacts as a compiler for the H2GIS library.

Please correct me if I am wrong !

[ebocher]

Hi @jratike80 ,

H2GIS is licenced under LGPL3 (https://github.com/orbisgis/h2gis/blob/master/LICENSE)

It would be consistent for the H2GIS GDAL driver to follow the same licence. There will therefore be no compatibility issues.

[rouault]

Regarding licencing, if that was to be included in the OSGeo/GDAL repository, files included in OSGeo/GDAL would have to be MIT licensed as per project policy. To my knowledge, there is no incompatibility between MIT and any open source (or closed source) license. The combined work of GDAL + H2GIS would be bound by the LGPL but that's another topic, and we already have such situations where GDAL + some of its optional dependencies is under something "stronger" than pure MIT (this is typically the case for a build of GDAL with GEOS, since GEOS is LGPLv2+ licensed).

Given I suspect that H2GIS isn't packaged in commonly used distribution systems (correct me if I'm wrong), it is not obvious to me that it would be more beneficial to users for the GDAL H2GIS driver to be integrated into the main GDAL repository, if users have first to go through the job of building H2GIS from source.

Do you have a sense of many end users would use such a GDAL H2GIS driver? This is something to have in mind to put in perspective the added maintenance costs for the GDAL project of having this added driver (assuming that you the proponents of this driver would take active part to its maintenance) versus the benefit for the overall GDAL community. Cf https://gdal.org/en/stable/development/rfc/rfc85_policy_code_additions.html