Tracking bug for `kart export` command (vector / table)

[olsen232]

kart import lets you take a non-Kart dataset and import it to Kart. There's no opposite command that takes a Kart dataset and exports it as some non-kart dataset type.

(Except that, if you really need to, you can use the working-copy creation functionality to export a dataset, or, use ogr2ogr on the contents of your working copy, or use ogr2ogr plus the experimental OGR driver in checked into contrib/.

This is the tracking bug for adding a kart export command. It will use GDAL OGR drivers internally and so will immediately support export to most anything that OGR supports, and it will feel familiar for anyone used to using ogr2ogr.

A downside to this approach is that we might have a bit more OGR behaviour / bugs than we want, until and unless we special case them or work around them. For example:

• Connection strings for postgres / MSSQL drivers will have to be in the format that OGR expects, not the format that Kart expects.
• OGR's type system doesn't have NUMERIC as a separate type from INTEGER / FLOAT, so handling of these types tends to be a bit inconsistent - this is one reason that kart import mostly doesn't use OGR any more.

(This issue is just for vector + tabular datasets - kart export for raster or point cloud datasets will need a separate command to be written. Using the working copy contents + gdal_translate or pdal translate works okay for exporting those formats in the meantime)

[olsen232]

Implemented in the following PRs:

988

990

991

[olsen232]

Mostly done except I should update the docs at https://docs.kartproject.org/en/latest/pages/command_reference.html

Possible future enhancements:

• export for raster and point clouds
• export lots of things at once eg kart export --all-tables
• prevent the user (or at least warn them against) exporting data into the working copy that kart is already maintaining