Re: [Viking-devel] Proposed Minor Features

[Greg Troxel]

Robert Norris rw_nor...@hotmail.com writes:

 A deeper question is how maps.xml extension file is distributed, since
 Viking doesn't directly control this, although the data/maps.xml is
 designed to be installed into /usr/share/viking or whatever the path
 is.

I don't follow doesn't directly control this.  It seems that it's in
the release tarball, and the straightforward install installs it.  So
when a new maps.xml is in a release, and people update, they'll have the
new default config.  That seems obviously sensible.

 Note the Window's install doesn't do anything about it.

So that's broken :-)  But I don't think the windows' installer not doing
the right thing should matter much in what happens.

 ATM The maps.xml file could change rapidly but it probably won't be
 picked up by users until the next formal Viking release.

True, but that would be true of a list that was in the source code.  If
there's an urgent change, then a release could be made.

 I think anything added into data/maps.xml file should have 
 explicit permission.

Agreed; that sounds like a safe and polite policy.


pgpL2Q5ba0ni6.pgp
Description: PGP signature
--
___
Viking-devel mailing list
Viking-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/viking-devel
Viking home page: http://viking.sf.net/

Re: [Viking-devel] A shared tile cache

[Greg Troxel]

Yuri D'Elia wav...@thregr.org writes:

 I'd like any of the developers to read this draft about a common shared
 cache that I'd like to implement in JOSM:

 https://josm.openstreetmap.de/wiki/SharedTileCache

Generally this seems sensible.  A few comments:

There should be a way to configure the max size used by the cache, or
maybe the min free space in the fs, or both.

There's an OSM, but really this isn't about OSM.  It's about TMS.
Bing isn't about OSM (even though they graciously let us edit based on
it).

So I'd use TMS rather than osm/tiles.

I think zoom/x/y is good.  I really don't like the way viking does it
now, which I can never easily remember.

A conversion program to read an old cache and move it to the new format
would be nice.  But for me not a big deal

A big issue is caching lifetime, in terms of when to recheck the server
vs just accessing without checking.  Your description of minimum tile
age seems to be this, but really the question is:

  what's the parameter that says if the difference between now and the
  time this tile was last verified to be valid is  X, then just use it.

  what is the mod date on the tile file?
- Origin server's generation timestamp (I like this)?
- When Fetched the first?
- When validated?

  when a tile is old enough to check, and the origin server says it's
  unmodified, how is this recorded?  Is there a second file?  In the
  .ini for the tile?  sqlite?


Your point about storing view count (and last view time) is a good one.
Probably LRU pruning would be good, maybe in a background process.


I don't mean to sound negative - my comments are pretty minor.


pgpNnXTwZMMo1.pgp
Description: PGP signature
--
___
Viking-devel mailing list
Viking-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/viking-devel
Viking home page: http://viking.sf.net/