Replies: 1 comment
-
That would be designing a different format than PMTiles - files are 1-dimensionally organized, and PMTiles chooses to use that 1 dimension to store the ZXY spatial pyramid from 0... etc.
Since a PMTiles archive is a simple flat file, and the ordering of data is consistent as long as it is clustered, there are many existing systems to deal with deduplication within files, for example:
etc... |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
This is more of an idea than a feature request:
What if pmtiles were capable of dealing with another dimension? So not only x/y/z(oom) but an additional version/time/date index.
Basemaps
The use case could be slight changes in a basemap over time - e.g. for merging differential updates from OSM for the basemap so that users can retrieve the version of a specific day/week/month.
Different releases
Or if you have a POI dataset that changes every year (like official addresses) and you need to keep all the releases.
Yes, you could already hack it somehow by having a baseline dataset for year 0 and then adding a tag/date for every new feature. But the client would still need to retrieve all the data and then filter.
Alternatively you could create multiple pmtiles files but then you'd duplicate all data that remains consistent over time. One of the key strengths of pmtiles is efficient deduplication, so I think this feature might make for a great addition in the spirit of pmtiles.
Even more dimensions
Of course, adding even more dimensions would allow for more nested stuff (like different branches of the same data and so on) but in the end - from my understanding of range requests - they can only work 1D (retrieving bytes X to Y), so reducing more dimensions to a single dimension comes with a great of loss of locality, to a point where it probably becomes pointless.
Maybe a little similar to #386
Beta Was this translation helpful? Give feedback.
All reactions