[Tilesathome] t at h, my plans/priorities

[Frederik Ramm]

Hi,

 > 1) Tilesets: Uploading a full
> tileset, rather than individual tiles at z>=12 leads to a 1600 fold
> reduction in the amount of metadata and metadata updates. 

This is a very simplistic description based on the assumptions that

(a) we need to store exactly who has uploaded which tile when;
(b) we need this information in a data base rather than in a log file;
(c) people always upload 1365 tiles;
(d) the server is not smart enough to automatically group tiles (i.e. 
add one metadata record for a tile and its sub-tiles if all sub-tiles 
are present).

As soon as any one of these falls, the case for full tileset uploads 
ceases to exist, right?

I know that I'm on the minority side in disputing (a), so I'd like to 
focus on (d). If we make a small change to the way we record metadata, 
we can automatically analyse any upload and say "this is a complete 
upload for level 12 and all sub-tiles up to level 17" (which would be a 
full tileset), but also "this is a complete upload for level 14 and all 
sub-tiles up to level 16" or "for level 6 and all sub-tiles up to level 11".

This would nicely handle your "low-zoom tilesets" without further ado 
(plus give people the freedom to upload low-zoom tilesets beginning at 
level 7 if they so desire).

If clients are modified to upload full tilesets, then this solution will 
give you all the benefits of your suggestion without actually *forcing* 
people to only uplaod full tilesets.

I'm willing to provide the patches required if you think it is worth a 
try. The metadata table might have to be altered though to allow for the 
new "up to level ..." column. Is that acceptable or will it create a lot 
of downtime?

> 2) Lowzoom: Currently the t at h lowzoom tiles look ugly!
> I would love to introduce a special style sheet, which is suitable for lower zoom
> levels. After thinking of hacking on a special z12_lowzoom level and
> stuff, I came to the conclusion that simply introducing a new layer
> (just like maplint), called "lowzoom", would be easiest.

Yes, I think that would work well. However 80n has recently presented is 
OsmXAPI (or whatever it was called) which might open the route to even 
better results at least for the medium levels 7-11...

 > In addition, and independently from above, the
> server could auto-generate low-zoom requests for areas it knows that
> have been changed (it knows this anyway), which would lead to a
> smarter render-only-when-required strategy

This would be very welcome but would have to go along with an extended 
queue mechanism and integration of lowzoom with the existing client (or 
adding queue capabilites to lowzoom.pl).

If we assume that lowzoom rendering will be done by a few people only, 
then it might make sense to include a list of changed tiles with each 
lowzoom request so that the lowzoom renderers which still have a copy of 
many l12 tiles on their disks can download only the changed ones.

> 3) Blank tile lookups are the only data base operation which are
> time-critical (slippymap rendering), on the other hand storing each
> z17 blank tile individually in the database is way too much in terms
> of the number of updates and the sheer amount of blank tiles. I see
> improvements in 2 areas:

I haven't followed the whole blank tile handling but there clearly seems 
to be room for improvement.

> 4) Relief data: I loved that relief overlay somebody provided for a
> while. If license permits, I would love to add this as a selectable
> overlay to informationfreeway.org as I think it really adds value to
> maps.

There are a few issues with that. Firstly, it would have to be an 
"underlay" (i.e. our normal tiles would have to become transparent). 
Secondly, some information on these tiles might be conflicting with what 
we have (I believe that these relief maps do contain lakes, for example, 
and I think I also saw roads on one). But yes, they would be very nice 
to have.

Bye
Frederik