Kart – Distributed version-control for geospatial and tabular data

Instead of creating a working tree of text or the binary of shapefile, it creates a working tree with the geometry features. You can kart diff and commit features, not text or binary. You can then export those features from kart into a database or working file where you can commit or checkout from.

It looks to be equivalent to Esri's 'branch versioning' on their proprietary ArcGIS Enterprise product, but can also deal with flat files as well as geospatial databases (PostGIS), which while not strictly required becomes really useful when dealing with edits, and conflict management, across multiple editors in large enterprise organisations, such as those that deal with state or country-wide mapping of topographic features.

If it integrated with QGIS/ArcGIS to show visual differences, and allow a user to easily reconcile differences between conflicting features (based on topological rules), I'd definitely be interested though it doesn't seem like it at a glance.

@fyrn_ Re: the work you did with 'multiplayer map editing', is there anything public you could show? I'm interested in how you solved this challenge.

I copy-pasted the front page into ChatGPT and told it to "Explain some usecases", and it's pretty useful.

   A city planning department tracks changes to zoning boundaries over time.
   Staff can:
      See who changed what, when, and why.
      Roll back or compare versions.
      Create branches for "proposed" zoning plans without touching main data.
   Citizens can access a cloned version of planning data.
   Changes or suggestions (e.g., new bike paths) can be proposed via pull requests.
   Keeps public and internal data separate but linkable.

or

  Farm fields are polygons; each year’s crop type is stored as tabular data.
  Each season gets committed with metadata and satellite imagery.

and many others

Check the docs. From my cursory glance it seems to be git but diffs are combinations of changed features instead of lines and characters.

I did some interesting things with folders full of GeoJSON files. It seemed fortunate enough that GeoJSON is a well supported lowest-common denominator for a lot of tools (esp. web tools) and if a thing didn't take GeoJSON there was some simple middle tool (usually a quick Python script). Pretty-printed GeoJSON gives you okay-ish diffs and if you go to an extreme like single feature per GeoJSON file (like I said, folder full of GeoJSON) and have other tools (often Python scripts) to reconstruct/deconstruct layers from all the separate files, you get things like commits/PRs where you know at a glance exactly which features changed (from the file list).

Certainly a lot more work than this new project, but as the old saying goes I suppose you should never underestimate the database power of a folder full of files.