Talk:Tiles@home/The blank tile problem

From OpenStreetMap Wiki
Jump to navigation Jump to search

jth (TeLLuS) propsal without database to serv tiles

With this blank tiles with any color is handled and no database needed to serve tiles. Only checking user and password and inserting blank tiles (missing files) need DB to store metadata at zoom 1-12.

  • Checking for info on blank (non existing) tiles at zoom 13-17 say that x,y,z is missing and then go up (-1) zoomlevel and display next existing tile. Or if zoom 12 also is missing, then read this information from the database. If there is no DB-entry then it is water that noone yet have uploaded.
  • In the png-file information is stored about copyright, upload username and client version. Maybe also tile coordinates and inkscape version as deelkar and kleptog suggested.

landslide

RewriteEngine on
RewriteCond  %{REQUEST_URI}  ^/map/tiles/([0-9]|1[012])/([0-9]{1,4})/([0-9]{1,4})\.png$
RewriteCond  /space/%{REQUEST_URI}  !-f
RewriteRule  ^(.*) /space/tiles/water.png  [L]

RewriteCond  %{REQUEST_URI}  ^/map/tiles/([0-9]{1,2})/([0-9]{1,6})/([0-9]{1,6})\.png$
RewriteCond  /space/%{REQUEST_URI}  -f
RewriteCond  /space/%{REQUEST_URI}  !-s
RewriteRule  ^(.*) /space/tiles/land.png  [L]

RewriteMap landslide prg:/usr/local/bin/landslide

RewriteCond  %{REQUEST_URI}  ^/map/tiles/(1[3-8])/([0-9]{1,6})/([0-9]{1,6})\.png$
RewriteCond  /space/%{REQUEST_URI}  !-f
RewriteRule  ^(.*) ${landslide:%{REQUEST_URI}}  [L]
  • Zoomlevel 0-12 no tile is water, 13-18 no tile is check above. Zoomlevel 0-18 empty 0-byte tile is blank land.
  • landslide.c To check for land, water or whatever in zoomlevels 12-18.

It is only called when there is no existing tile at the current location. From given coordinates it go up one (-1) zoomlevel so many times until it find a tile or zoom 12 is reached. If it is an empty 0-byte file then it is land. If the zoomlevel 12 tile is missing it is water. If there is any other tile in the lower zoomlevel it is returned. This means if there should be a blank tile with water in zoomlevel 13-18 there must be a blank watertile in there. The same tile will then show up on all the zoomlevels below(+), down to 18.

  • Also when serving slippymap and transfer fail it can display an connection-transfer-error tile insted of water like it does now. I think that would make sense.
  • Lowzoom tile and captionless layer (zoom 6-11) is updated by the server itself where changes are made and with some intervals.


Distributed tile servers

  • Get tiles from different servers depending on location of tile. Slippymap return the x and y of zoomlevel 5 and request the tiles in this area to the specified server in DNS. Like 3x7.view.openstreetmap.org. Works for me. (Earlier slippymap code)
 function get_osm_url (bounds) {
   var res = this.map.getResolution();
   var x = Math.round ((bounds.left - this.maxExtent.left) / (res * this.tileSize.w));
   var y = Math.round ((this.maxExtent.top - bounds.top) / (res * this.tileSize.h));
   var z = this.map.getZoom();
   var path = z + "/" + x + "/" + y + "." + this.type;
   var url;
   if ( z < 6 ) { url = "http://tah.openstreetmap.org/Tiles/tile.php/"; }
     else { url = "http://" + (x >> (z-5)) + "x" + (y >> (z-5)) + ".view.openstreetmap.org/Tiles/tile.php/";
   }
   if (url instanceof Array) {
       url = this.selectUrl(path, url);
   }
   return url + path;
 }



spaetz propsal for blank tile handling

Lookup blank tiles

Currently the code tries to look up the blank tile info at the requested layer, then go one layer up until it finds blank tile information. This would remain unchanged.

Insertion of blank tiles

  • The code would go up the hierarchy and see if the next higher blankness information is the right type of blankness (land/sea). If yes, it would just make sure that no regular tile file exists and not do anything else. If the higher blankness info is different we are in trouble (then a blank sea tile is in the middle of blank land)

Changing the type of blankness (land/sea)

To be filled in. Basically set the previous blankness typo on all four daughter tiles (if they haven't any blankness entry themself) and set the new blankness info to the tile.

Deletion of a blank tile

  • If a blank tile is deleted (replaced by a non-blank file) we don't delete it's blank entry, we simply insert a regular tile file. This means that blank daughter will still be shown as blank and because the tile file exists that overrides any blank lookup. Those tiles will therefore been shown in the slippy map.

Regular maintenance and Optimization

  • During nights, we could run a "blank tile vacuumer" which goes through the blank tile data base and whenever it finds four neighboring tiles belonging to one parent tile with the same blank tile information, it will set the parent tile to the right type of blankness (even if it contains a regular tile) and delete the "daughter tile info".

So blankness information will "bubble up" the hierarchy when it's efficient to do so.

  • To even optimize things more: From time to time we can then "reverse vacuum" the blank data base, ie. check all (especially the low zoom) blank tile entries, whether they cover any blank tiles at all. If not, we can then delete that blank entry and set it on all daughters that have no file associated instead. Also in cases where only 1 daughter tree has blank tiles we can move the blankness info down the hierarchy a bit....

Summary

This solution has the advantage that it is compatible with our current blank tile database. The crucial maintenance which optimizes data base size can be performed at non-critical times with low priority. But we would still end up with a minimal size blank data base using recursive lookups

Comments

As far as I can recall, similar schemes (mark deleted, then delete properly later) are commonly used inside database systems. MSSQL, I believe, uses this system to clear records that have been deleted.

A product I worked on tried to use MSSQL with a large number of INSERTS and DELETEs. The DB kept running out of disk space, despite having a fairly constant number of rows. It took us some time to work out that we were keeping the database so busy that the vacuuming system never happened.

So long as there are quiet periods, such a scheme should work well.

Silverfish 17:43, 30 July 2007 (BST)