On 03/24/2014 03:01 AM, Robert Norris wrote:
> Location on Windows: Include Windows 8.1 (I think it follows the Win7
> layout) and 'C:\UsersPath\UserName' is better as %UserProfile%
> (indeed see http://en.wikipedia.org/wiki/Home_directory for other
> OSs)
Thanks, updated.
> There are many other applications that could use such a shared cache
> layout (they must have there own schemes ATM, even if they at least
> use the standard Z/X/Y.ext structure somewhere. Immediately can I
> think of Marble, Navit, GPS Prune and libchamplain which would all
> benefit from using this scheme. I would be good to contact as many
> interested parties as possible.
I'll try.
> Should there be way to say never cache the tiles? e.g. size=-1
Agree, added.
> May be specify what is 'short' for the directory name, e.g. up to 20
> characters.
No opinion here, but I could see how it could be helpful for defining ID
sizes.
Added.
> I have 9.0Gb in my viking-maps cache. If you've been using any such
> map program for a few years you may have got quite a lot of data.
> Transforming between old and new layouts *must be seamless*. Hence I
> won't be applying your patch, but thank you for it - indeed for a
> new user as yourself - it will be easier to keep that cache layout.
Honestly, I migrated mine.
I had roughly 2gb of data. I invoked "rename" and mv with an arithmetic
expression a couple of times.
As I wrote in the bug report, my inclination would be to provide a
script to interested users, but I definitely see how on Windows and Mac
this is not a "nice" the way to go.
> I don't really understand the structure behind Viking's original
> cache layout. I guess the omission of the file extension was just
> because the original author didn't think to add it! The top level dir
> names all seem to end in z0, I believe was in place for UTM
> positioning where z is a zone, as there are repeating UTM zones
> across the earth with Northings & Eastings within them. However I
> think UTM things get translated into Mercator Lat/Longs so the zone
> part is superfluous anyway.
I see, I was wondering that myself.
> I'm at least glad you're thinking of simple .ini files rather than
> .json files that becoming all the rage by some people ;)
I'm not fond of the "ini" extension, since I would *not* advocate a real
INI parser, but just a simple k=v text file, without comments even.
I wasn't sure about using ".conf" or not, though.
The idea of using the "tile.ext.ini" (.ini appended as opposed to a
[tile.ini]) comes also for simplicity when generating filenames.
> Separately, could you explain how you think will do pruning in JOSM
> in more detail? It can be quite complicated: e.g. How often and when
> it occurs, how will it find out the size of the cache (and how long
> that will take), does it delete highest zoom, lowest zoom or by
> 'however the files are on disk' first? Do you worry about creating
> new files if the size is already reached? How any feedback to the
> user will work, if it is required at all? If you do switch to a cache
> new layout - are you going to auto delete the old layout?
You would be surprised to know that the second reason JOSM becomes
slower is that it *doesn't* do any pruning. There's an option to prune
the cache, but AFAIK it's broken.
I think that maybe this is the reason of using /tmp/ on linux?
But anyway.
Cache pruning is complex, and there's no unique way to do it, so this is
the reason a deliberately specify how to perform it.
In JOSM, I would perform pruning only on program exit. This is due to
the fact that assessing the cache size requires a full tree traversal,
and will not be fast enough for interactive work.
Josm has a list of rects that it keeps for "downloaded" areas, and I was
planning to do something very simple at first:
- get cache size / file list
- sort by size/mtime/zoom respectively
- while cache size > limit:
- pick first tile in the sorted list that's not visible and remove it
- if cache has not shrunk, disable visibility check
- if cache has not shrunk, break
Of course, this is very crude, it doesn't take into account how often
areas a "looked at" at all, which would actually be much better.
This is where those "metadata" files come in handy. JOSM already stores
the ETag (for servers that don't support if-modified-since). Though I
don't believe there are any... this is actually a perfect place to store
the tile "hit counts" to perform usage-based pruning.
------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/13534_NeoTech
_______________________________________________
Viking-devel mailing list
Viking-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/viking-devel
Viking home page: http://viking.sf.net/
