Please note that compatibility for 0.x releases (software or repositories) isn't guaranteed. Kart is evolving quickly and things will change. However, we aim to provide the means to upgrade existing repositories between 0.x versions and to 1.0.
When adding new entries to the changelog, please include issue/PR numbers wherever possible.
- Changed format of feature IDs in GeoJSON output to be more informative and consistent. #135
- Added support for
--output
option tokart conflicts
. #135 - Bugfix: Better error message on using
kart conflicts -ogeojson
formeta-item
conflicts. #515 - Removed the older
upgrade-to-tidy
andupgrade-to-kart
features which were only relevant to Sno (predecessor of Kart). [[#585](koordinates#585]] - Added support for
--decorate
and--no-decorate
inkart log
. [[#586](koordinates#586]]
- Improve performance when creating a working copy in a spatially filtered repository (this was previously slower than in a non-filtered repository; now it is much faster) #561
- Added Sphinx documentation, built from the
docs
directory. #220
Support for spatial filters - the spatial filter can be updated during an init
, clone
or checkout
by supplying the option --spatial-filter=CRS;GEOMETRY
where CRS is a string such as EPSG:4326
and GEOMETRY is a polygon or multigon specified using WKT or hex-encoded WKB. When a spatial filter is set, the working copy will only contain features that intersect the spatial filter, and changes that happened outside the working copy are not shown to the user unless specifically required. Starting with Kart 0.11.0, only the features that are inside the specified spatial filter are downloaded during a clone. Spatial filter docs | #456
- Expanded
--output-format
/-o
to accept format specifiers; e.g.-o json:compact
.kart log
now accepts text formatstrings, e.g.-o text:%H
#544 - Deprecated
--json-style
in favour of-o json:{style}
- diff: Added
--add-feature-count-estimate=<accuracy>
tojson-lines
diffs. This lazily inserts an estimate of the total number of features into the output stream. #543 - Bugfix: fixed errors with Postgres working copies when one or more datasets have no CRS defined. #529
- Bugfix: better error message when
kart import
fails due to multiple XML metadata files for a single dataset, which Kart does not support #547 - When there are two pieces of XML metadata for a single dataset, but one is simply a
GDALMultiDomainMetadata
wrapping the other, the wrapped version is ignored. #547 - Bugfix: fixed a bug preventing
checkout -b NEW_BRANCH HEAD^
and similar commands from working - Bugfix: fixed a bug where
kart merge
would fail in a shallow clone, in certain circumstances. #555
- More advanced filters for
log
,diff
andcommit
: All of these now work:- Wildcard (
*
) filters for dataset names, e.g.kart diff -- *parcel*:meta:schema.json
will show only schema changes for all datasets withparcel
in their names.*
by itself matches all datasets. #532 - You can now output the history of individual features:
kart log -- <dataset-name>:feature:<feature-primary-key>
. #496
- Wildcard (
kart clone
now strips.git
off the end of automatically-generated repo paths, if--bare
is not specified. #540- Simpler developer builds using CMake, see the contributing notes.
- Bugfix: fixed certificate verification errors when cloning HTTPS repositories on some Linux distributions. #541
- Bugfix: fixed the error when merging a commit where every feature in a dataset is deleted. #506
- Bugfix: Don't allow
--replace-ids
to be specified during an import where the primary key is changing. #521
log
: Fixed some regressions in 0.10.6 involving argument parsing:- Auto-incrementing PK sequences now work in PostGIS working copies for table names containing the
.
character. #468
- Information about the current spatial filter is now shown in
status
. #456 - Added a specification for allowed characters & path components in dataset names - see Valid Dataset Names.
- New
kart data rm
command to simply delete datasets and commit the result #490 - Fix for #491 - make Kart more robust to manual edits to the GPKG working copy that don't leave the metadata exactly as Kart would leave it (such as by leaving unneeded table rows in
gpkg_contents
) - Added minimal patches:
kart create-patch
now supports--patch-type minimal
, which creates a much-smaller patch; relying on the patch recipient having the HEAD commit in their repository #482kart apply
now applies both types of patch.
kart log
now accepts a--
marker to signal that all remaining arguments are dataset names. #498import
from a Postgres or MSSQL source will no longer prepend the database schema name to the imported dataset path.- Bugfix: Diffing between an old commit and the current working copy no longer fails when datasets have been deleted in the intervening commits.
- Bugfix: Existing auto-incrementing integer PK sequences are now overwritten properly in GPKG working copies. #468
- Fixed regressions in
diff -o geojson
since Kart 0.10.1 #487 - Removed
kart show -o geojson
#487 - Fix for #478
merge --dry-run
raises error - Fix for #483
diff
error with Z/M geometries
- Added basic support for spatial filters - the spatial filter can be updated during an
init
,clone
orcheckout
by supplying the option--spatial-filter=CRS;GEOMETRY
where CRS is a string such asEPSG:4326
and GEOMETRY is a polygon or multigon specified using WKT or hex-encoded WKB. When a spatial filter is set, the working copy will only contain features that intersect the spatial filter, and changes that happened outside the working copy are not shown to the user unless specifically required. #456
- Auto-incrementing integer PKs: When the working copy is written, Kart now sets up a sequence which supplies the next unassigned PK value and sets it as the default value for the PK column. This helps the user find the next unassigned PK, which can be non-obvious in particular when a spatial filter has been applied and not all features are present in the working copy. #468
- Bugfix: Set GDAL and PROJ environment variables on startup, which fixes an issue where Kart may or may not work properly depending on whether GDAL and PROJ are appropriately configured in the user's environment
- Bugfix:
kart restore
now simply discards all working copy changes, as it is intended to - previously it would complain if there were "structural" schema differences between the working copy and HEAD. - Bugfix: MySQL working copy now works without a timezone database - previously it required that at least
UTC
was defined in such a database. - Feature-count estimates are now more accurate and generally also faster #467
kart log
now supports output in JSON-lines format, so that large logs can be streamed before being entirely generated.
- Added support for the geometry
POINT EMPTY
in SQL Server working copy. - Bugfix: fixed the error when writing diff output to a file. #453
- Bugfix: when checking out a dataset that has an integer primary key as a GPKG working copy, Kart should continue to use the actual primary key instead of overriding it, even if the primary key column isn't the first column. #455
Fixed kart upgrade
so that it preserves more complicated (or yet-to-be-released) features of V2 repos as they are upgraded to V3. #448
Specifically:
generated-pks.json
metadata, extra metadata found in datasets that have an automatically generated primary key and which are maintained by repeatedly importing from a primary-key-less datasource- attachments (which are not yet fully supported by Kart) - arbitrary files kept alongside datasets, such as license or readme files.
kart show
now supports all the same options askart diff
. Bothkart diff
andkart show
now both support output in JSON-lines format, so that large diffs can be processed as the diff is generated.- Bugfix: diffs containing a mixture of primary key types can now be shown (necessary in the case where the primary key type has changed).
- Some performance improvements - less startup overhead.
Kart v0.10.0 introduces a new repository structure, which is the default, dubbed 'Datasets V3'. Datasets V2 continues to be supported, but all newly created repos are V3 going forward.
- Entire repositories can be upgraded from V2 to V3 using
kart upgrade EXISTING_REPO NEW_REPO
. - Anything which works in a V2 repo should work in a V3 repo and vice versa.
- V3 repos are more performant for large datasets - compared to V2 repos where size-on-disk climbs quickly once dataset size exceeds 16 million features.
- The working copy can now be a MySQL database (previously only GPKG, PostGIS and SQL Server working copies were supported). The commands
init
,clone
andcreate-workingcopy
now all accept working copy paths in the formmysql://HOST/DBNAME
#399- Read the documentation at docs/MYSQL_WC.md
- Import of tables using
kart import
is now supported from any type of database that Kart also supports writing to as a working copy - namely, GPKG, PostGIS, SQL Server and MySQL. - Support for rapidly calculating or estimating feature-counts - see below.
- Change to
kart data ls
JSON output, now includes whether repo is Kart or Sno branded. - Importing from a datasource now samples the first geometry to check the number of dimensions - in case the datasource actually has 3 or 4 dimensions but this fact is not stored in the column metadata (which is not necessarily required by all source types). #337
- Bugfix: Creating a working copy while switching branch now creates a working copy with the post-switch branch checked out, not the pre-switch branch.
- Bugfix: GPKG spatial indexes are now created and deleted properly regardless of the case (upper-case or lower-case) of the table name and geometry column.
- A few bugfixes involving accurately roundtripping boolean and blob types through different working copy types.
- Bugfix: 3D and 4D geometries are now properly roundtripped through SQL Server working copy.
- Fix help text for discarding changes to refer to
kart restore
instead ofkart reset
, askart restore
is now the simplest way to discard changes. #426 import
: PostGIS internal views/tables are no longer listed by--list
or imported by--all-tables
, and can't be imported by name either. #439upgrade
no longer adds amain
ormaster
branch to upgraded repos.
Kart now includes ways to calculate or estimate feature counts for diffs. This encompasses the following changes:
diff
now accepts--only-feature-count=<ACCURACY>
, which produces a feature count for the diff.log
now accepts--with-feature-count=<ACCURACY>
which adds a feature count to each commit when used with-o json
.- All calculated feature counts are stored in a SQLite database in the repo's
.kart
directory. - Feature counts for commit diffs can be populated in bulk with the new
build-annotations
command
- First and foremost, the name — we're now called Kart!
- Various local config and structure which was named after
sno
is now named afterkart
- for instance, a Kart repo's objects are now hidden inside a.kart
folder. Sno repos with the older names will continue to be supported going forward. To modify a repo in place to use thekart
based names instead of thesno
ones, usekart upgrade-to-kart PATH
. import
&init
are often much faster now because they do imports in parallel subprocesses. Use--num-processes
to control this behaviour. #408status -o json
now shows which branch you are on, even if that branch doesn't yet have any commits yet.
- Internally, Sno now stores XML metadata in an XML file, instead of nested inside a JSON file. This is part of a longer term plan to make it easier to attach metadata or other files to a repository in a straight-forward way, without having to understand JSON internals. Unfortunately, diffing commits where the XML metadata has been written by Sno 0.8.0 won't work in Sno 0.7.1 or earlier - it will fail with
binascii.Error
- Backwards compatibility with Datasets V1 ends at Sno 0.8.0 - all Sno commands except
sno upgrade
will no longer work in a V1 repository. Since Datasets V2 has been the default since Sno 0.5.0, most users will be unaffected. Remaining V1 repositories can be upgraded to V2 usingsno upgrade EXISTING_REPO NEW_REPO
, and the ability to upgrade from V1 to V2 continues to be supported indefinitely. #342 sno init
now sets the head branch tomain
by default, instead ofmaster
. To override this, add--initial-branch=master
reset
now behaves more likegit reset
- specifically,sno reset COMMIT
stays on the same branch but sets the branch tip to beCOMMIT
. #60import
now accepts a--replace-ids
argument for much faster importing of small changesets from large sources. #378
- The working copy can now be a SQL Server database (previously only GPKG and PostGIS working copies were supported). The commands
init
,clone
andcreate-workingcopy
now all accept working copy paths in the formmssql://HOST/DBNAME/DBSCHEMA
#362- Currently requires that the ODBC driver for SQL Server is installed.
- Read the documentation at docs/SQL_SERVER_WC.md
- Support for detecting features which have changed slightly during a re-import from a data source without a primary key, and reimporting them with the same primary key as last time so they show as edits as opposed to inserts. #212
- Optimised GPKG working copies for better performance for large datasets.
- Bugfix - fixed issues roundtripping certain type metadata in the PostGIS working copy: specifically geometry types with 3 or more dimensions (Z/M values) and numeric types with scale.
- Bugfix - if a database schema already exists, Sno shouldn't try to create it, and it shouldn't matter if Sno lacks permission to do so #391
- Internal dependency change - Sno no longer depends on apsw, instead it depends on SQLAlchemy.
init
now accepts a--initial-branch
optionclone
now accepts a--filter
option (advanced users only)show -o json
now includes the commit hash in the outputimport
from Postgres now uses a server-side cursor, which means sno uses less memory- Improved log formatting at higher verbosity levels
sno -vvv
will log SQL queries to the console for debugging
- Any command which outputs JSON would fail in 0.7.0 when run in a terminal unless a JSON style other than
--pretty
was explicitly specified, due to a change in the pygments library which Sno's JSON syntax-highlighting code failed to accomodate. This is fixed in the 0.7.1 release. #335
- Support for importing data without a primary key. Since the Sno model requires that every feature has a primary key, primary keys are assigned during import. #212
- Support for checking out a dataset with a string primary key (or other non-integer primary key) as a GPKG working copy. #307
- Improved error recovery: Sno commands now write to the working copy within a single transaction, which is rolled back if the command fails. #281
- Dependency upgrades (GDAL; Git; Pygit2; Libgit2; Spatialite; GEOS) #327
- Bugfixes:
sno meta set
didn't allow updates toschema.json
- Fixed a potential
KeyError
inSchema._try_align
- Fixed a potential
unexpected NoneType
inWorkingCopy.is_dirty
- Imports now preserve fixed-precision numeric types in most situations.
- Imports now preserve length of text/string fields.
- Imported fields of type
numeric
now stored internally as strings, as required by datasets V2 spec. #325
- Newly created Sno repositories no longer have git internals visible in the main folder - they are hidden away in a '.sno' folder. #147
- The working copy can now be a PostgreSQL / PostGIS database (previously only GPKG working copies were supported). The commands
init
,clone
andcreate-workingcopy
now all accept working copy paths in the formpostgresql://HOST/DBNAME/DBSCHEMA
#267- Read the documentation at docs/POSTGIS_WC.md
- Patches that create or delete datasets are now supported in Datasets V2 #239
apply
andimport
no longer create empty commits unless you specify--allow-empty
#243, #245apply
can now apply patches to branches other thanHEAD
#294apply
,commit
andmerge
commands now optimise repositories after committing, to avoid poor repo performance. #250commit
now checks that the diff to be committed matches the schema, and rejects diffs that do not - this is possible in working copy formats that have relatively lax type enforcement, ie GPKG #300- Added GPKG support for Sno types that GPKG doesn't support - they are approximated as strings. #304
schema.json
no longer stores attributes that are null - a missing attribute has the same meaning as that attribute being present and null. #304data ls
now accepts an optional ref argumentmeta get
now accepts a--ref=REF
optionclone
now accepts a--branch
option to clone a specific branch.switch BRANCH
now switches to a newly created local branch that tracksBRANCH
, ifBRANCH
is a remote branch and not a local branch #259gc
command added (delegates togit gc
)- Bugfix - don't drop the user-supplied authority from the supplied CRS and generate a new unrelated one. #278
- Bugfix - generated CRS numbers are now within the user range: 200000 to 209199 #296
Sno v0.5 introduces a new repo layout, which is the default, dubbed 'Datasets V2'
Existing commands are backward compatible with V1 datasets, however some new functionality is only supported in repositories upgraded to the new layout.
- Entire repositories can be upgraded from V1 to V2 using
sno upgrade EXISTING_REPO NEW_REPO
. - V2 should support everything V1 supports
- All new repositories use the new layout by default. To opt out, use the
--repo-version=1
flag forsno init
- A future release will drop support for v1 repositories
- Most schema changes now work
- this includes column adds, drops, renames and reordering.
- Notably, changing the primary key field of a dataset are not yet supported.
- Meta changes are now supported (title, description and XML metadata for each dataset)
import
now has a--replace-existing
flag to replace existing dataset(s).
- String primary keys and tables without primary keys are not yet supported. #212
- Changing the primary key column is not yet supported. #238
- Patches which create or delete datasets are not supported. #239
- Schema changes might not be correctly interpreted if too many changes are made at once (eg adding a new column with the same name as a deleted column - sno may incorrectly assume it is the same column).
- It is safest to commit schema changes to any existing columns, then commit schema changes adding any new columns, then commit any feature changes.
- New structure to
sno diff
output:- Text output: Features are now labelled as
<dataset>:feature:<primary_key>
, consistent with meta items that are labelled as<dataset>:meta:<meta_item_name>
- JSON output also uses "feature" and "meta" as keys for the different types of changes, instead of "featureChanges" and "metaChanges".
- Text output: Features are now labelled as
sno show -o json
header key changed tosno.show/v1
, which is not an applyable patch. Usesno create-patch
to create a patch.sno upgrade
now only takes two arguments:sno upgrade EXISTING_REPO NEW_REPO
. No other arguments are required or accepted, exactly how to upgrade the repository is detected automatically.
- Added
sno create-patch <refish>
- creates a JSON patch file, which can be applied usingsno apply
#210 - Added
sno data ls
- shows a list of datasets in the sno repository #203 sno help [command]
is a synonym forsno [subcommand] --help
#221sno clone
now support shallow clones (--depth N
) to avoid cloning a repo's entire history #174sno log
now supports JSON output with--output-format json
#170sno meta get
now prints text items as text (not encoded as JSON) #211sno meta get
without arguments now outputs multiple datasets #217sno diff
andsno show
now accept a--crs
parameter to reproject output #213- Streaming diffs: less time until first change is shown when diffing large changes. #156
- Working copies are now created automatically. #192
- Commands which are misspelled now suggest the correct spelling #199
- Bugfix: operations that should immediately fail due to dirty working copy no longer partially succeed. #181
- Bugfix: some column datatype conversion issues during import and checkout.
- Linux: Add openssh client dependency into rpm & deb packages. #121
- Windows: Fix missing PROJ data files in packages. #235
- packaging: Fix issue with broken git component paths in packages on macOS and Linux (#143)
- packaging: Exclude dev dependency in macOS package
- Added a
sno meta get
command for viewing dataset metadata (#136) merge
,commit
,init
,import
commands can now take commit messages as files with[email protected]
. This replaces thesno commit -F
option (#138)import
: Added--table-info
option to set dataset metadata, when it can't be autodetected from the source database (#139)pull
,push
,fetch
,clone
commands now show progress - disabled with--quiet
(#144)import
now works while on an empty branch (#149)
- Basic conflict resolution:
- Major improvements to
sno import
andsno init --import
: - Added
sno show
: shows a commit. With-o json
generates a patch (#48) - Added
sno apply
to apply the patches generated bysno show -o json
(#61)
- add a changelog (here!)
sno import
enhancements (in addition to major changes above):- GPKG database paths no longer need
GPKG:
prefix - now takes table names as separate arguments
- Added
--primary-key=FIELD
to override primary key field name - Added
--message
to customize the commit message --list
no longer requires a repository
- GPKG database paths no longer need
sno init --import
enhancements:- imports are much faster (#55)
- now imports all tables from database, doesn't allow table to be specified
- Many JSON output improvements:
- JSON output is specified with
-o json
instead of--json
(#98) - Added syntax highlighting to JSON output when viewed in a terminal (#54)
sno diff
JSON output layout has changed - features are now flat objects instead of GeoJSON objects. This is much more compact (#71)- Added JSON output option for most commands
- Added
--json-style
option to several commands to control JSON formatting (#70)
- JSON output is specified with
sno diff
:sno commit
:- can now commit some subset of the changes by supplying filter args, ie
[dataset[:pk]]
(#69)
- can now commit some subset of the changes by supplying filter args, ie
- removed
import-gpkg
command; useimport
instead (#85) - Error messages now go to stderr instead of stdout (#57)
- Error conditions now use exit codes to indicate different types of errors (#46)
- Sno is now available on Windows 🎉 (Windows 8.1+ / Server 2016+ (64-bit))
- Updates to continuous integration — installers/archives are now built and tested with every commit for every platform.
- For macOS users, a homebrew "tap" is now available:
brew cask install koordinates/sno/sno
- Several bug fixes
- License: sno is now publicly available under the GPL open source license.
- Sno now has a website at sno.earth
- Standalone builds and packaging for Linux and macOS. Windows won't be far behind
- Refactoring to support alternative database working copies
- Dependency upgrades (GDAL; Git; Pygit2; Proj; Libgit2; Sqlite; and others)
- Several bug fixes
If you were running a preview release, remove it before installing the new release:
$ brew uninstall sno
$ brew untap koordinates/sno
We have an initial preview available of our Sno repository hosting. This allows you & your team to push and pull Sno repositories. Please contact [email protected] with your Github username and we can get you set up. There is no cost for this service.
Repositories created with Sno v0.2 are compatible with v0.3. For assistance upgrading any v0.1 repositories, please read our upgrade guide.
- First and foremost, the name — we're now called Sno!
- A new repository structure/layout, which has better performance and a smaller on-disk size
- Data imports are now orders of magnitude faster
- Support for multiple datasets in a single Sno repository
- Support for non-spatial datasets
- Increased test coverage including end-to-end tests
- Improved macOS Homebrew packaging with CI testing.
- Prototype support for spatial-indexing and a sno query command for spatial lookups.
- Diffs across branches/commits, and a GeoJSON diff format.
- Numerous bug fixes