Experimental GDAL/OGR plugin drivers for Kart repositories. These are mostly to provide a proof of concept for discussion and to support future feature development in Kart.
They are implemented using the OGR Python Drivers mechanism in GDAL which is fairly rough & inefficient. It also means the drivers are read-only.
These plugins require GDAL v3.8.0 or newer. The contrib/gdal/README.md file contains usage information.
CLI (contrib/gdal/cli/)
This plugin calls Kart CLI commands to find and expose features/layers, and diffs between revisions. Since Kart uses GDAL this approach provides a safe and relatively clean process boundary. It's similar to how VSCode, Github Desktop, and other IDEs interact with Git — and how it's used server-side for many operations at the likes of Github & Gitlab. As long as the interprocess communication is efficient using this approach could be a relatively smooth path to implement a fully-featured C++ GDAL/OGR driver in the future.
In-process (contrib/gdal/in_process/)
The in-process plugin uses Kart internal/private Python APIs to find and expose features/layers. Since Kart uses GDAL and GDAL is calling Kart, you can only use the GDAL library, tools, and associated drivers bundled with Kart.
Experimental GDAL/OGR plugin drivers for Kart repositories. These are mostly to provide a proof of concept for discussion and to support future feature development in Kart.
They are implemented using the OGR Python Drivers mechanism in GDAL which is fairly rough & inefficient. It also means the drivers are read-only.
These plugins require GDAL v3.8.0 or newer. The
contrib/gdal/README.mdfile contains usage information.CLI (
contrib/gdal/cli/)This plugin calls Kart CLI commands to find and expose features/layers, and diffs between revisions. Since Kart uses GDAL this approach provides a safe and relatively clean process boundary. It's similar to how VSCode, Github Desktop, and other IDEs interact with Git — and how it's used server-side for many operations at the likes of Github & Gitlab. As long as the interprocess communication is efficient using this approach could be a relatively smooth path to implement a fully-featured C++ GDAL/OGR driver in the future.
In-process (
contrib/gdal/in_process/)The in-process plugin uses Kart internal/private Python APIs to find and expose features/layers. Since Kart uses GDAL and GDAL is calling Kart, you can only use the GDAL library, tools, and associated drivers bundled with Kart.
Checklist: