Tiles@home/Problems
- About
- 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
- 2008-04-01
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
- Example of wrong render by a Gentoo AMD64 PC.
Level 12 tileset used : 2184,1285 and 2185,1285
- Level12 zoom
- Level13 zoom
- Level14 zoom
- Level15 zoom
- Level16 zoom
B) High density tiles example
Level 12 tileset used : 2045,1359 and 2046,1359
- Level12 zoom
- Level13 zoom
- Level14 zoom
- Level15 zoom
- Level16 zoom
- Level17 zoom
Dutch 15:40, 4 March 2007 (UTC)
Performance
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).