This object is in archive! 

Vector map tile cache status

joeloc shared this question 8 years ago
Answered

Whats the status of vector map tile caching these days? Disabled completely? Maybe it might be worth looking into again, perhaps a few things changed in Android regarding IO efficiency.


Reason for asking: My RMAPs render multiple times (2x... 3x... even 4x...) faster than mapsforge tiles, even when repeatedly scrolling/zooming the same area. I would assume that with proper caching, re-rendering mapsforge should be just as fast as RMAP. Or am I missing something?


In case the cache is just commented out in the source code (reading the old topics suggests this), could you maybe enabled it again and do a few checks? Maybe we can get a 500% rendering speed increase with zero work :)

Replies (2)

photo
1

Menion should include the option to disable thousands of unwanted clickable POIs - i'm sure vector maps will be faster again...

photo
1

yes, its good idea

photo
1

As you probably read in this topic: http://help.locusmap.eu/topic/persistent_caching_of_vector_map_tiles , caching of tiles is disabled.


Main problems why not to cache:

1) same as in case of WMS maps - too many options. Text sizes, styles, custom selection in styles in OAM styles etc. All these completely change map tile

2) too many IO operations - I'm not expect and have no knowledge about longevity of SD cards, based on IO operations


Vector maps won't be even as fast as some pre-rendered maps. All SQLite, RMap and similar are loaded directly, but vector maps needs to have lazy-loading system so there will always be an delay.


Visible points from attached map database has very low effect on speed of vector maps. Requests on points are quite fast and number of visible points at once is below 1.000, which cause no serious problems to Locus. Major limitation as I know is complexity of map theme and speed of memory from which maps are load.


So I'm sorry, but caching is not planned. I plan to force Petr to invest some time to optimization of data in file itself, which I believe, will have major impact in speed of rendering.

photo
1

Thanks for the answer. Not happy with it, but that's the way it is :-). Offline maps (and cached online maps) really aren't just "a little" faster. They're orders of magnitude faster and I hate losing that potential. It's probably also a major difference in battery usage. Testing this on a high-end phone, I suppose slower phones will make the speed penalty even worse.


As for your points 1) and 2), I cant see much difference in caching online map tiles vs caching vector map tiles. Of course the vector cache invalidates when you change the rendering style. That could easily be handled by encoding style options into the tile name with a simple hash function. It's not that one changes styles every minute though. Scrolling and zooming on the other hand does happen every minute and rendering the same data over and over again just seems like an awful waste of battery and time.


Worrying about sdcard health is a non-issue imho. But if you worry too much, the cache could be turned off by default and/or limited to internal memory and/or limited to zooms <=16.


Still looking forward to data optimizing by Petr... but no offence... the possible gains will come nowhere close to simply blitting a cached tile.

photo
1

Hi,


I was thinking about it and I've completely forget on one major problem with caching - reason why is caching disabled at all - auto-loading. Auto-loading is quite lazy .. it render one map and later check if there is another map in case, few map tiles is completely blank. Then all map tiles needs to be pre-rendered again with all loaded maps at all. So in such cases, it is not possible to simply use it.


Anyway answer here may be the same - cases when you browse at border of two maps are lot less frequent then common browsing in inner are of a map.


As I see in code now, caching of vector map tiles is enabled in case of disabled! auto-loading and only for zooms 0 - 10 on big screens and 0 - 12 on a small screens.


So should be an option to have "disabled auto-zoom" as required condition for caching of map tiles? If so, I may keep this feature as is and only extend range of zoom levels. Which is an option I may think about.

photo
1

I really tried to understand your first paragraph... but couldnt :-).


Anyway, I disabled vector-map-autoload and there does indeed seem to be caching now for zooms <= 10. The speed difference is amazing, at least 200%. Too bad I almost never use such low zooms.


I dislike "hard limits" like "only when zoom < X or screendpi < Y". A more sensible approach is to MEASURE the time you need for rendering vs the time you need for displaying cached tiles. Average that for a few dozen tiles for each zoom level and then you have the perfect "setting" for when caching makes sense and when it does not. This will automatically work perfectly for every single device on this planet, no matter how fast the graphics card, no matter how fast the memory, no matter how fast the storage, no matter how efficient your rendering code, no matter how detailed your map data. It will simply work... and users arent bothered with more options and conditions and god-knows-what-other-caveats that not even the programmer seems to have remembered :-).

Replies have been locked on this page!