|Discontinued - Tiles@home is no more|
Tiles@home is no more
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 university of 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:
This is a file which defines several custom OpenLayers.Layer.OSM subclasses, to provide convenient access to OpenStreetMap tile layers.
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.
- In the main http://www.openstreetmap.org Slippy Map, press the + icon in the top-right corner and select "Osmarender" to see the tiles.
- Map browser, a slippy map browser. Includes the ability to request tiles for rendering through the static map browser which doesn't use the slippy map.
- Map browser, a non-slippy map browser. Includes the ability to manually request tiles for rendering.
- InformationFreeway A full-screen slippy map, also from the dev tile server. Includes the ability to manually request tiles for rendering. Also allows permalinks to the tiles@home layer.
- For a overview, see OpenStreetMap component overview.
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.
- To let your software request updates, see Tiles@home/APIs
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.
- OSM@home Different version of this program, for rendering city images
- Slippy map tilenames, and tiles@home/Zoom levels
More statistics are available, see the website for details
- Request queue list and Request queue graphs
- Server stats
- Contributions list from users running tiles@home client.
- Contributions more detail any analysis here.
How the client works
If a client gets a tile request:
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.
- For Windows, there's an automatic Installer. Tips for installing it manually can be found on the same page.
- 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.
Serving tile images
We need one or more dedicated servers, demand is growing.
Help develop the client program, the website, or associated tools
- tiles@home/ColorPallete About color reduction in the client
- 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.
- There is a new Tiles@home/Server install guide, for people trying to run and develop the server software.
- tiles@home/RFC Discuss the development process, or suggest changes
- Tiles@home/Usability Report for any problems you have with the t@h systems
- tiles@home/Dev/Appearance Discuss the graphical choices and rendering rules
- Tiles@home/Problems Problems rendering large areas
- Tiles@home/The blank tile problem Storing of blank tiles
For infrastructure t@h depend upon Tiles@home/Admins Needs update, who have access, who do what, depend on OSM API data from www
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