[Feature request] Allow updating COVTiles file with updated tiles

[HarelM]

This is still an initial thought, but here goes anyway.
When thinking about this, in terms of a replacement to the mbtiles file one of the things to think about is how to update the file.
Both on the server and also in the client.
Here are the relevant scenarios:

1. I'm downloading this file for offline usage and would like to update some tiles that changed from the time this was built - I would probably need to know what the date was a tile changed and I'll need to be able to update specific tiles - when doing so for a mbtiles file the file gets bigger and bigger (probably a sqlite bug, but still).
2. I have a file that is on the server, serving tiles and I would like to update it incrementally instead of building it from scratch every time.

So, thing to consider:

1. A last modified date for a tile
2. Make sure that when updating the file multiple times, the file size doesn't get too big - i.e. the file size should be roughly change by the diff in the tile size, or at least linearly so that if I build the file from scratch the sizes of both files is not dramatically different.

[nyurik]

@HarelM I agree that incremental updates may be useful, but I am not certain those should be part of the tile format itself (i.e. should be part of the the tile format discussion). MVT is highly versatile and convenient because it is limited in scope to just the tile itself, not the metadata about it.

For example, an MVT tile does not store its location index (zoom/x/y) - because otherwise tiles with identical content (e.g. water or empty land) would not be identical, and each would have to be stored. Same should be true for regeneration and other metadata - identical tiles won't be regenerated at the same time. This type of information can easily be stored as part of the container (mbtiles / com-tiles / pmtiles), but not part of the COVTiles itself.

P.S. In other words - I think this comment should probably go into the com-tiles repository. My understanding is that's where the container format is being discussed.

[HarelM]

I don't disagree, I was under the impression that COVTiles is the next generation of COMTiles.
Feel free to move this discussion to the other repo.

[nyurik]

I think COMTiles is basically a packaging format that can store any tiles (raster/mvt/nextgen/...). The COVTiles on the other hand is a replacement for MVT itself, not for its packaging. COVTiles can be stored in any packaging like COMTiles/PMTiles/MBTiles/....

Maybe it may make sense to rename COVTiles to reduce confusion? Someone at the last conference proposed "Libre Tiles" or MLTiles (*.mlt) 😄

[HarelM]

The mapbox equivalent if I understood you correctly is the following:
https://github.com/mapbox/vector-tile-spec
It talks about a single tile - which might not be obvious in this repo...
I don't have a problem with the names "COVTile" or COVT or CVT (Cloud vector tile) as log as it is clear that this repo is talking about the spec/implementation of a single tile.
In any case, thanks for the extra info.

[mactrem]

Yes, we should definitely change the name to avoid confusion.
"Libre Tiles" sounds good :)