After my rather pessimistic post last time, I want to say that I'm basically optimistic about the progress in OSM rendering efforts in general and tiles@home in special.

There are, however, fundamental differences between centralised map rendering and distributed map rendering. Some are obvious, others less so.

… See full entry

There are some problems with the t@h approach to rendering maps, but there are two that might develop to the point where they become show-stoppers:
(from my point of view)

A) The server is too slow.
B) The clients can't handle certain tiles.

Yes, the server is too slow. It cannot handle enough clients to keep the world up to date soon, let alone retroactively re-render everything that need to be rendered when a layer gets added to the portfolio of things we want to show.
For almost all year the server has not shown a similar improvement in speed to everything else OSM.

Also since several city-tiles are getting very complex, there are fewer and fewer clients that can infact render those tiles. Next to nobody has a PC with 12+ GB of RAM laying around. The problem being that if we start precutting the tiles into more manageable chunks the osm to svg transformation becomes prohibitively slow. There should be a more effective way of keeping svg complexity down when rendering high-zoom subtiles of densely mapped city areas, other than mucking around with the osm data.

literally. I mapped some powerlines around the Farge coal plant, connecting existing ways, and correcting a few lines that went between the wrong towers.

Yesterday Sebastian Spaeth (spaetz), Christopher Schmidt (crschmidt) and I set up the new server that will host the tiles@home project to relieve the dev server.

It's a nice machine with lots of fast storage, so currently we're seeing a speedup of at least factor 2. The actual speed increase is difficult to see, because the currently running clients do not manage to keep the queue to any significant length, so if you have a tiles@home upload account, update your client to the newest revision and start rendering!

There are some small issues still, like there is no fall-through to the old dev tiles yet, but nothing that would hinder normal rendering, and we're working on those so they should disappear soon.

as Steve Coast would say:
Have fun :)

Some of you might know that I'm one of the core developers of the tiles@home rendering client, and sometimes work on easy parts of the serverside code.

Currently I'm more in "firefighting" mode than anything else, only to be stopped by lack of free time and the slowness of the dev server, which runs the serverside stuff.

What I like to see would include a tah.openstreetmap.org server, separate from dev, not a vhost, with it's own disks, and tuned a bit better to meet the requirements of the project. (i.e. lots of fast hdd space, lots of bandwidth, maybe a bit more RAM than dev currently has), but since OSM is a very "if you want something done do it yourself" sort of run project this will take a while, since I don't have the resources in time and money to go to london and set said machine up, apart from the fact that I can't even get into the server room probably, so my only hope is that the publicity and popularity of tiles@home in the OSM project grows to a point where the admins that do have physical access to the servers and the people with the money see a necessity to give it its own server.

Current problems that I'd like to fix, but that are too complex for my time I can dedicate to them:
- use new rasterizer. Inkscape sucks.
- implement better client-server communication to handle error situations
- improve detection and handling of errors in client, especially systemic errors like broken external software
- ...