Open
Description
Current state
- Files generated by martin's
mbtiles
tool containagg_tiles_hash
metadata field. The field represent an aggregate hash of all tiles table (z/x/y/data). See docs. - When diffing two mbtiles files -
file A
andfile B
, the generated delta file will includeagg_tiles_hash_after_apply
value - the hash of thefile B
.
Proposal
Current design has a few shortcomings that need to be addressed. The biggest issues is that any mbtiles can be applied to any other mbtiles - which is different than "merge-copying" (simply adding content to the same file from multiple other files, where tiles with the same x/y/z override existing ones.
- Add a new metadata field
agg_tiles_hash_before_apply
(name?) to the delta files -- this corresponds to theagg_tiles_hash
of thefile A
. - Improve logic and default behavior
Creating a diff file between A and B
- Refuse to work if either A or B files contain
agg_tiles_hash_before_apply
oragg_tiles_hash_after_apply
(unless there is a--force
flag) - If either files A or B do not contain
agg_tiles_hash
, compute it (but don't save it?) - Store
agg_tiles_hash
asagg_tiles_hash_before_apply
andagg_tiles_hash_after_apply
values in the delta file
Patch file A with a diff, or apply on copy
- Refuse to work if file A contain
agg_tiles_hash_before_apply
oragg_tiles_hash_after_apply
- Refuse to work if the diff file does NOT contain
agg_tiles_hash
,agg_tiles_hash_before_apply
oragg_tiles_hash_after_apply
- Unless some
--validate
flag is set, acceptagg_tiles_hash
stored in file A as valid. If it does not exist, compute it. - Refuse to work if the stored/computed
agg_tiles_hash
does not matchagg_tiles_hash_before_apply
- After patching file A, validate the file against the
agg_tiles_hash_after_apply
value