[OSM-dev] t at h, my plans/priorities

[spaetz]

I had a couple of days to think about my t at h improvement plans and will outline these here (sorry for crossposting, but user visible changes might be of interest for some), details can be discussed on the tilesathome mailing list.

They can be summarized as:
1) Tileset uploads 2) Lowzoom improvements 3) blank tile storage (4 relief overlay)

1) leads to changes in t at h client interface and server storage, 2) will require t at h client cooperation and will lead to user visible prettyness improvements and 3) will be a purely server internal change.

Just a (not so) brief summary of all three areas:
---------------------------------------
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. So we should forbid single tile uploads at these zoom levels as quickly as possible. In addition we might want to introduce low-zoom tilesets (zoom level 6-11), rather than individual low-zoom images, working in the same way as high-zoom tilesets, leading to less metadata (changes).

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. It would apply the lowzoom style sheets and just create level 12 tiles (or even better, it would directly create z11 tiles, can the API handle this by now?). These tiles could then simply be used for stitching low zoom tiles together. The changes required would be rather small and easy, actually.
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, rather than the dumb "have-a-few-people-just-crunch-through-all-tiles-all-the-time" approach. (Levels 0-5 could even created by the server itself from time to time)

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: a) currently we have a tiles_blank table which stores blankness information together with who uploaded that informatino last. It is constantly being updated even if no new blank tiles have been identified. This has 2 undesired effects: the size of blankness metadata makes that table very big, and is mostly unneeded now anyway as we have the metadata for full tilesets at >=z12 anyway. So my plan would be to drop the metadata part, and just store the "x,y,z,layer,blanktype" information in that table. This would make that table be read-only mosty and enable us to actually use cached results as it would remain the same for more than a few seconds. Metadata could be stored in the tiles_meta table even for blank tiles at z<11 as reading/writing t that table is never time critical.
The second issue is, that we blindly insert blankness information even if a recursive lookup (up the zoom levels) would lead to the same blankness information already. So there is some optimizing to be done here.

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.

Comments, opinion, discussion welcome on the tiles at h mailing list.
spaetz
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 186 bytes
Desc: not available
URL: <http://lists.openstreetmap.org/pipermail/dev/attachments/20070805/77672ac9/attachment.pgp>