From OpenStreetMap Wiki
Jump to navigation Jump to search
This page describes a historic artifact in the history of OpenStreetMap. It does not reflect the current situation, but instead documents the historical concepts, issues, or ideas.
Tiles@home (short: T@H or tah) was a distributed program to render osmarender maps. This page documents software problems for historical interest.
Reason for being historic
The project was a bit out-dated. Developers lost interest, and the host, the Swiss Federal Institute of Technology in Zurich, was no longer happy about the bandwidth usage.
Captured time

Rendering Large Areas

The forest in the following picture, spanning (a part of) four tilesets, is not rendered, because it does not lie within the area of any of the tilesets. The problem only exists for areas which don't have a node inside all the tiles they should render in.

When downloading a bounding box, tiles@home does request a little more from the server than strictly needed, but that "little" more is insufficient in this cases.

Possible solution 1: Break up forest in smaller areas. Drawback: Changes in data required to aid rendering; editors do not necessarily show tile grid; tile grid may also change in future.

Possible solution 2: Pre-Process downloaded OSM file to complete any incomplete ways that make up areas. Drawbacks: (a) slow, (b) does not work if the whole area boundary is outside of the tile being rendered.

Since API 0.5 ways are always returned complete.

Non-Issues with Bezier vs Non-Bezier curve hinted tiles

With the implementation of Barry Crabtree's lines2curves beziercurve hinting of svg files, in the Tiles@Home client (Bangkok revision), people has risen the issue of the option to disable bezier curve hinting in the client, stating that if one client renders with beziercurve hinting enabled, and another renders without, it will look awfull on the map, since tiles won't match up correctly "due to problems at tiles boundaries".

This option was implemented in SVN revision 2200 of the T@H client (Bangkok version), since it turned out that AMD64 architecture PC's running the Gentoo linux distribution has some underlaying problems in the distributions mathematical library routines. These problems haven't been discovered in other AMD64 specific distro's such as Ubuntu or Debian. In order for these people to still use the Bangkok client, the config file option NoBezier=0/1 was implemented, with the default set to 0 thereby enabling Beziercurve hinting.

Contrary to popular belief, using a mixture of clients who have beziercurve and non-beziercurve hinting, will NOT do that, nor induce illness in the user, bring down the 7 plagues on us, or end the world as we know it.

To prove my point here is several examples, where the left tile is Beziercurvehinted, and the right tile isn't:

A) Low density tiles example

Erroneous AMD64/Gentoo rendered tile - Example of wrong render by a Gentoo AMD64 PC.

Level 12 tileset used : 2184,1285 and 2185,1285

Level 12 tiles - Level12 zoom Level 13 tiles - Level13 zoom Level 14 tiles - Level14 zoom Level 15 tiles - Level15 zoom Level 16 tiles - Level16 zoom

B) High density tiles example

Level 12 tileset used : 2045,1359 and 2046,1359

Level 12 tiles - Level12 zoom Level 13 tiles - Level13 zoom Level 14 tiles - Level14 zoom Level 15 tiles - Level15 zoom Level 17 tiles - Level16 zoom Level 17 tiles - Level17 zoom

Dutch 15:40, 4 March 2007 (UTC)


As of revision 5086 rendering tile 2331 1185 (Helsinki) takes around 37 minutes on a 2.2 GHz AMD Athlon with 4 GB of RAM. These 37 minutes seem to break down into

  • 9 minutes for xmlstarlet
  • 22 minutes for inkscape
  • 3 minutes for pngcrush
  • 2 minutes for others

Instructions to reproduce these numbers are available at http://lindi.iki.fi/lindi/tiles-at-home-performance.txt (if somebody has time to move these to wiki, please go ahead).