Details
-
Suggestion
-
Resolution: Unresolved
-
P3: Somewhat important
-
None
-
5.10
-
None
Description
QGeoFileTileCache has several limitations.
One way to solve them all is to use a SQLite DB instead of the filesystem to keep cached tiles.
Things to consider:
- there should be one table per map id with the tiles. And then possibly one table per mapId with meta data, most importantly total number of tiles in the table, total size of tiles in the table
- there should also be one table per plugin, that should act as a settings storage.
This because we must prevent that, if application A sets some limits, and B some other limits, smaller limits override larger limits.
In general it should be discouraged to use the same cache from different apps, but since it's not forbidden, limits should always be the largest between what is stored in the cache settings, and what is set by the app. And then the settings should be updated.
- When an app sets unitary and another sets bytesize, there should be a failsafe way to convert the one into the other and make coexistence of two apps using different schemes possible. Easiest would be to define a fairly large "average tile size" and convert unitary into byteSize at runtime
- this cache should also only preload the sizes, the number of tiles, and the table names, and do the necessary calculation to initialize the limits. No tilespec should be hashed, and for every tile request, the DB should be queried directly.
- tile insertion should be transactional, together with updating the size and tile number counters
- since we have a "memory cache" it would be practical to add an "O_DIRECT" option to access the DB. How feasible this is (and in a cross platform way) is a different question
++
Attachments
Issue Links
- relates to
-
QTBUG-59665 Speed-up of the osm Plugin
- Reported