Add support for [geo]parquet

[robbfitzsimmons]

Came across the project on Hacker News and really excited at the potential here - thank you and congrats!

Geoparquet is a core part of our tech stack, and seems like a natural file type for the project. I did a quick search of the repo and don't see it referenced in the codebase or branches. (Apologies if I missed something.)

Have you all discussed geoparquet support, and/or any help you need to evaluate that for inclusion?

[hamishcampbell]

Hi Robb,

Thanks for the comment. We have discussed GeoParquet a little. There are a few ways Kart could work with GeoParquet data.

Imports into Kart repos: Kart includes GDAL, and since GDAL has GeoParquet drivers, it should be relatively straight forward to import from GeoParquet files as well.

Exports from Kart repos: we also have 'exports' to data formats in the roadmap, and exporting to GeoParquet makes a lot of sense. This would allow users to easily extract snapshots of data into formats that are not otherwise supported as working copies.

Working copies: The column-oriented nature of the format means it might not be a great fit for "working copy" data. Kart repositories are stored in a row-oriented fashion and we anticipate that operations like checking out new versions or applying updates during merges could be slow vs other formats. Altough we're not working on it, we'd still love to see someone implement it and see how it shakes out.

[rcoup]

Working copies: ... operations like checking out new versions or applying updates during merges could be slow

To expand on this: Parquet is essentially a write-once format; so any data update (like pulling/switching to a different revision) requires recreating the entire Parquet file. Compared to a database where we can update only the differences between revisions.