Meta tiles

From OpenStreetMap Wiki
Jump to: navigation, search
Available languages — Meta tiles
Afrikaans Alemannisch aragonés asturianu azərbaycanca Bahasa Indonesia Bahasa Melayu Bân-lâm-gú Basa Jawa Baso Minangkabau bosanski brezhoneg català čeština dansk Deutsch eesti English español Esperanto estremeñu euskara français Frysk Gaeilge Gàidhlig galego Hausa hrvatski Igbo interlingua Interlingue isiXhosa isiZulu íslenska italiano Kiswahili Kreyòl ayisyen kréyòl gwadloupéyen Kurdî latviešu Lëtzebuergesch lietuvių magyar Malagasy Malti Nederlands Nedersaksies norsk bokmål norsk nynorsk occitan Oromoo oʻzbekcha/ўзбекча Plattdüütsch polski português português do Brasil română shqip slovenčina slovenščina Soomaaliga suomi svenska Tiếng Việt Türkçe Vahcuengh vèneto Wolof Yorùbá Zazaki српски / srpski беларуская български қазақша македонски монгол русский тоҷикӣ українська Ελληνικά Հայերեն ქართული नेपाली मराठी हिन्दी অসমীয়া বাংলা ਪੰਜਾਬੀ ગુજરાતી ଓଡ଼ିଆ தமிழ் తెలుగు ಕನ್ನಡ മലയാളം සිංහල ไทย မြန်မာဘာသာ ລາວ ភាសាខ្មែរ ⵜⴰⵎⴰⵣⵉⵖⵜ አማርኛ 한국어 日本語 中文(简体)‎ 吴语 粵語 中文(繁體)‎ ייִדיש עברית اردو العربية پښتو سنڌي فارسی ދިވެހިބަސް

A meta tile is a concept used by various tile rendering, caching and storage systems. Tiles eventually make their way to the web browser as quite small images (typically as 256x256 pixel) covering quite a small area of map. Instead of dealing with such small images internally, we deal with a larger area of map, a "meta tile".

On OpenStreetMap tile servers we use mod_tile (also used by quite a few third party tile servers). mod_tile typically counts a meta tile as a square area of 8x8 normal tiles (64 normal tiles) so covering a square area of map which is 2048x2048 pixels. tirex follows the same scheme, but they can be configured differently, and other systems such as geowebcache use different approaches.

There are three reasons why dealing with meta tiles may be better than the normal tiles:

  • Rendering efficiency - Requesting a larger area for rendering (2048x2048 pixels) is more efficient. Assuming the user who triggered it to render, is going to want to view more than one normal sized tile, it would be inefficient to start up the Mapnik rendering engine, fetch the required data and do a render for each little 256x256 tile. But also bearing in mind that a re-render may be triggered by a cache expiry on a busy area of the map where many users will be seeing the results anyway, we might as well be re-rendering quite large chunks of map. This increased efficiency comes at a cost of a higher response time when a tile needs to be rendered on-demand.
  • Label placement simplifications - Requesting a larger area of the map allows rendering systems to make some simplifying assumptions. In particular when positioning labels along a long road, they place them once per meta-tile, somewhere within the meta-tile. Requesting a render of little 256x256 patches of map individually, would make label placement much more complicated and any mismatches would cause an ugly truncated effect.
  • Storage and transfer efficiency - Storing millions of tiles on a file system, and transferring them over networks, starts to be quite inefficient or impossible. Worldwide coverage with a straightforward directory full of 256x256 PNG files is unlikely to work on any normal filesystem. See tile disk usage. Meta tiles dramatically alleviate this problem. For example an 8x8 meta-tile means storing 64 times fewer files (although you still might have rather a lot of files if you store meta-tiles worldwide rather than rendering on the fly). mod_tile actually stores meta-tile files in its cache, not as a 2048x2048 pixel image, but as a set of 64 256x256 pixel images, ready to serve, but concatenated into a single file. The detaching and serving of these files is all handled internally by mod_tile.
    A different solution to this problem is the MBTiles format for storing many files in a single SQLite DB file.