The tiles@home system has been shut down, that is, not just the service for receiving updates from tiles@home clients, but also the tile server. The layer often known as "osmarender" is no longer available (The rendering software osmarender is still around of course).

The reason for this was explained in an email. 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.

OpenLayers.Layers.OSM.osmarender is also no more

After this tileserver was shut down we have removed the class 'OpenLayers.Layers.OSM.osmarender'. This means any OpenLayers map deployed with a reference to this class, just broke with an error something like:

TypeError: 'undefined' is not a constructor (evaluating 'new OpenLayers.Layer.OSM.Osmarender("Osmarender")')

Web developers can fix this by removing reference to this class. E.g. swap in OpenLayers.Layer.OSM.Mapnik instead. Many sites just reference osmarender as an alternative layer anyway.

Note that this class is only available anyway if you are using a file called OpenStreetMap.js from our servers like this:

General Description

Tiles@home (short: T@H or tah) is a distributed program to render osmarender maps. The osmarender, maplint and captionless layers are created in this way. The Mapnik layer is rendered with other computers separately in a different way.

How the system works

T@H has a server software, Tahngo (generation 2), running at the Tiles@home website, which get requests to render tiles from updated mapdata. There are many people who run the client software on their computers that ask what map-tile to render and contribute their results back to the server.

Viewing the maps

The following pages then get their osmarenderer (tiles@home) tiles from the server above.

Details

Data comes from different sources into the OpenStreetMap database. When the data for some location changes, this location is added to a request queue on the T@H server. Users may also request manually that an area should be re-rendered. Every T@H client has a connection to this server, asking for tiles that it should render. Jobs are defined by a tile at zoom level 12. Clients take these jobs, render the corresponding level 12 to 17 tiles and upload a bunch of PNG images to the server. They are then used to draw the slippy map.
Lower zoom levels < 12 are stitched together by the server based on the uploaded zoom 12 (captionless) tiles.

The t@h tahngo server (generation 2) is written in django (python framework).

Requesting a re-render

Tiles on the t@h server are automatically re-requested for rendering from the changed tiles api call, so most changes should be visible without manual requests after about 2 to 4 hours. Some tiles might still need to be requested manually because of errors.

You can do this on http://www.informationfreeway.org in zoom-level 12 by pressing r to request a rerender and i to request information about rendering status, who rendered it, size and other things.

There is a priority system to ensure that manually requested tiles will be rendered before automatic requests. Depending on the job queue length and the complexity of your tile this can take 5 minutes to several hours. You will not be notified when your tile has been rendered.

Making too many "manual" requests at once (i.e. by not requesting manually, but, say, a script) automatically deprioritizes your requests until your part of the queue has emptied somewhat. Your requests will still get rendered, but not at the priority you might wish to see.

How the client works

Rendering for zoom levels 12 through 17

OSM data for the area of that level 12 tile is downloaded once, from the API, as an XML data structure

Recursive function is used to generate a SVG graphics at zoom levels 12, 13, 14, 15, 16 and 17 (which is done by osmarender)

For each zoom level, a large single PNG is generated, which is sliced into several smaller PNG tiles.

A separate process zips each tileset and then uploads it to the tile layer on the t@h server

Rendering for zoom levels 6 through 11

This description refers to the lowzoom that is generated on the client and server.

When a z12 tileset is generated, an additional captionless tile is generated for zoom level 12. This is used as the base layer for generating zoom levels 0 through 11.

There are three steps to this process:

A set of transparent tiles is generated and uploaded from clients containing just captions (town and city names, etc) using a similar method to that used for zoom levels 12 through 17. This is called the caption layer. If there is nothing uploaded a complete transparent tile will be returned.

A set of captionless tiles is generated using a tile-stitching method on the server. The captionless zoom 12 tiles are used as a base for this step. This is called the captionless layer.

Finally the tile layer is created by compositing the caption layer over the captionless layer on the server.

Right now, you can issue a request for the "caption" layer at min_z=6, this would cause the server to hand that request out to a tah client. The problem is that regular tah clients are not configured to actually be able to create the caption layer and that they wouldn't create a tileset from z6 - z11.

Rendering for zoom levels 0 through 5

The tile layer is generated using a stitching method from the zoom level 6 tiles. This is currently done manually on the server.

How you can help

Run the client

You may run the client program, which renders some maps and uploads them to our server. There is some kind of interactive mode, but most likely, you will run this in a completely automated mode.

Your OSM account username and password is used for uploading the rendered images.

You can install Tiles@home on your computer, following this tiles@home/Install Guide. @Non-techies: Be warned, it might be difficult to get it running; but do not fear to try, it might be just as easy.

You can download a complete virtual machine, where everything is installed for you. Then, you may run this virtual computer on your windows, linux or mac PC, but you will need VirtualBox for this. It's running in the background, so you can still do your normal work. See Virtual Tiles@Home.

There is a kickstart file for setting up a virtual machine with Fedora 9 (x86_64) for tiles@home rendering, largely automated. Instructions are here.

A "bare-bones" AMI (Amazon Machine Image) for Amazon's Elastic Compute Cloud (EC2) is in development, last updated 2009-07-19. It's a Fedora environment with all necessary software pre-installed. Launch an instance of "ami-cb39d8a2", log in as root via SSH, and you will find instructions (also see "Running the program" in the install guide above). If you have questions or issues, contact Larry Gilbert.

A project attempting to make Tiles@Home available through the rPath Application Platform has been abandoned due to technical snafus and a lack of general help from the rPath community. If interested in taking it over, contact Larry Gilbert.

Admins

For infrastructure t@h depend upon
Tiles@home/Admins
Needs update, who have access, who do what, depend on OSM API data from www

Add documentation

Adding documentation for unexplained pieces in configuration files and general documentation on how to do certain things are welcome. Might be low priority but it is also difficult to write high quality documentation. tiles@home/Extra documentation