Nick Allen <nick.allen...@gmail.com> writes: > Sorry, most of the technical stuff referred to is above my head, but I > may be able to help with an explanation of why the technical people > put a loop in. > > At one point, when the age limit for a tile was reached, and the > programme was started, it immediately deleted the old tile(s) before > it tried to download the new. No issue most of the time, but if for > instance you downloaded tiles before going on a holiday so you could > use viking whilst away but without internet, you could find after a > week or so that all of your map tiles had deleted!
That's a good point. So I think there needs to be two rules: if a tile is a wanted, and it's old enough (create data at the server) to be unfresh (30 days or at least 7, to be polite), fetch new, and **if successfull** replace if a tile has not been **read** (or written) in some long lifetime, then remove, and perhaps only if the tile cache is using too much space. This lifetime should be more like 6m. perhaps have something that prunes the cache to no more than X MB, deleting the least-recently read/downloaded. Separately, it would be cool to have a way to bring the OSM data and render tiles on one's notebook. For slow request rates (1 client) and a smallish area, this should be doable resource wise and the big hurdle is having packaging set up to make it easy.
pgpjw6FKGy8Ix.pgp
Description: PGP signature
------------------------------------------------------------------------------ Infragistics Professional Build stunning WinForms apps today! Reboot your WinForms applications with our WinForms controls. Build a bridge from your legacy apps to the future. http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk
_______________________________________________ Viking-devel mailing list Viking-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/viking-devel Viking home page: http://viking.sf.net/
