You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Files generated by martin's mbtiles tool contain agg_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 and file B, the generated delta file will include agg_tiles_hash_after_apply value - the hash of the file 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 the agg_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 or agg_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 as agg_tiles_hash_before_apply and agg_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 or agg_tiles_hash_after_apply
Refuse to work if the diff file does NOT contain agg_tiles_hash, agg_tiles_hash_before_apply or agg_tiles_hash_after_apply
Unless some --validate flag is set, accept agg_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 match agg_tiles_hash_before_apply
After patching file A, validate the file against the agg_tiles_hash_after_apply value
The text was updated successfully, but these errors were encountered:
Current state
mbtiles
tool containagg_tiles_hash
metadata field. The field represent an aggregate hash of all tiles table (z/x/y/data). See docs.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.
agg_tiles_hash_before_apply
(name?) to the delta files -- this corresponds to theagg_tiles_hash
of thefile A
.Creating a diff file between A and B
agg_tiles_hash_before_apply
oragg_tiles_hash_after_apply
(unless there is a--force
flag)agg_tiles_hash
, compute it (but don't save it?)agg_tiles_hash
asagg_tiles_hash_before_apply
andagg_tiles_hash_after_apply
values in the delta filePatch file A with a diff, or apply on copy
agg_tiles_hash_before_apply
oragg_tiles_hash_after_apply
agg_tiles_hash
,agg_tiles_hash_before_apply
oragg_tiles_hash_after_apply
--validate
flag is set, acceptagg_tiles_hash
stored in file A as valid. If it does not exist, compute it.agg_tiles_hash
does not matchagg_tiles_hash_before_apply
agg_tiles_hash_after_apply
valueThe text was updated successfully, but these errors were encountered: