hi,<div><br></div><div>oh no! I hope I will hit the Top100 before everything breaks up! ;)</div><div><br></div><div>Despite the personal things and disadvantages, do you (and all other readers) see any</div><div>reasons for t@h to be alive? I mean, is the effort worth to be done by possible "volunteers".</div>
<div>if not, then nobody will miss t@h and all are good to go to other projects.</div><div>which leads me to the question: what server specs would be needed? how many time should</div><div>be spent to "keep the thing running", etc.?</div>
<div><br></div><div>would love to hear any thoughts!</div><div><br></div><div>ben</div><div><br><div class="gmail_quote">On Tue, Feb 8, 2011 at 4:49 PM, Sebastian Spaeth <span dir="ltr"><<a href="mailto:Sebastian@sspaeth.de">Sebastian@sspaeth.de</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Hi there,<br>
<br>
you might have noticed that tiles@home was pretty quiet from my side<br>
although the server is nicely humming along all the time. During the<br>
last 6 month we had 416 user accounts uploading data (possibly using many<br>
more boxes). 65GB of tiles were uploaded just yesterday.<br>
<br>
I have to admit that I pretty much lost my motivation to continue<br>
improving the server and the client code. deelkar has been saying that<br>
he would keep the client going but is not likely to implement the next<br>
cool feature either. Also the underlying osmarender implementation in<br>
perl is kind of maintainerless.<br>
<br>
I believe t@h has achieved a great deal of things. It is a great proof<br>
of concept for implementing alternative renderers. And using XSLT<br>
transformations to create .svg files out of .osm files. How cool is<br>
that! All credits for that geekie hack go to Etienne (80n) who created<br>
the original xslt templates that made osmarender. We were the first to<br>
provide current maps when someone edited the data. And we were the first<br>
system to have data validation layers.<br>
<br>
It is also a great concept of a distributed renderer, which helped to<br>
keep the world's maps up to date when mapnik could only be run on weekly<br>
or even older snapshots. Furthermore, being separate from the OSMF<br>
foundation infrastructure, we were an independent provider of map tiles<br>
without usage restrictions to this day. No one could shut us off and we<br>
were not limited by policies decided on by someone else.<br>
<br>
t@h has spawned a great deal of innovations surrounding the renderer<br>
system. Due to our need of downloading huge amounts of data we triggered<br>
the development of several read-only API servers that were able to<br>
satisfy our needs. osm diffs every minute helped to keep the RO mirror<br>
system up to date without burdening the API much. Custom layers helped<br>
to identify data errors (maplint). Lots of great stuff there.<br>
<br>
However, in its current form it passed its zenith. Developments such as<br>
wikimedia's toolserver, mapcss clients, mapnik realtime updates, and 3rd<br>
party improvements such as cloudmaps custom style editor achieved much<br>
of what osmarender/t@h set out to do (at least in *my* vision)<br>
<br>
There are also disadvantages, some of which could be fixed easily,<br>
and some which are inherent in the current architecture:<br>
<br>
- Being distributed we require huge amounts of data being transferred<br>
over the network. Each render client requested a new z12 tile<br>
full of data for each update.<br>
<br>
- By proactively rendering the world on each change rather than<br>
rendering on demand, we uploaded lots of data much of which was never<br>
viewed. Generally, the server upload bandwidth is approximately equal<br>
to the server download bandwidth, so we were quite wasteful there.<br>
<br>
- Mapnik has gotten so efficient that a single powerful box is able to<br>
keep the world up to date, while we were keeping lots of computers<br>
busy. During the last 6 months, we had 416 user accounts uploading<br>
data, and 65GB of data has been uploaded just yesterday.<br>
<br>
- The osma client in perl is pretty much in abandoned state, and other<br>
clients seem to become more advanced as time goes by. It would easily<br>
be possible to switch the current tilesGen.pl client out for a<br>
different one, but no one seems to be interested in doing that<br>
development. And no one has volunteered during the previous years<br>
either.<br>
<br>
- Using inkscape to render the tiles is obviously not optimal for the<br>
size of the tiles that we are rendering. We are still witnessing hangs<br>
and freezes. At least to corruption of the inkscape user config files<br>
seems to have been solved by now :-). Admittedly, we probably force<br>
inkscape to perform feats it has not been designed to do.<br>
<br>
- Similarly the stylesheets: I consider the openness in tweaking style<br>
sheets one of the killer features of the current system. Anyone with<br>
an OSM svn account can change the t@h style and improve it. However,<br>
there seemed little interest in really developing this<br>
further. Besides the tireless petschge whom I would like to thank for<br>
his efforts, and user "Mueck" who recently seems to have done stuff,<br>
not many people seem interested in tweaking and improving things.<br>
So easily modifyable style sheets don't seem to be needed by the<br>
community, at least not in the osmarender form :).<br>
<br>
WHAT IS GOING TO HAPPEN<br>
<br>
I will keep the server running as is, but I will not be making great<br>
improvements to it. Deelkar is going to keep the tilesGen client running<br>
but willnot be making great improvements to it. So these are the<br>
possibilities:<br>
<br>
- We keep things running as is until something (likely the server or our<br>
RO mirror network) breaks.<br>
<br>
- Someone volunteers to take over client development (either the<br>
existing one or a replacement in whatever language you prefer). The<br>
server is pretty client agnostic, all it does is dish out requests and<br>
take back tileset files, so that could be done by whatever app.<br>
<br>
- Some one volunteers to take over server development. This would likely<br>
involve getting a new server, as I will not be allowed to hand out<br>
access to the current one, unfortunately.<br>
<br>
It has been a wild and fun ride over the years for me. I'd like the thank<br>
Oliver White for conceiving t@h in the first place, petschge and deelkar<br>
for everything they have done on the client side, server side and<br>
otherwise. Frederik Ramm for helping with code (the perl implementation<br>
of osma), advise and moral support. Bobkare for helping out with the<br>
rendering code, and xslt stuff. Of course all those bug reporters and<br>
testers helped a lot, you know who you are (yes, Alfons, for example<br>
you!)<br>
And last but not least, all those tireless renderers that keep<br>
the world up to date. Keep them running!<br>
<br>
Let me know what you think and how we should be proceeding. If you<br>
volunteer to take over something or want to be involved in an effort to<br>
reorganize things speak up.<br>
<br>
spaetz<br>
<br>_______________________________________________<br>
Tilesathome mailing list<br>
<a href="mailto:Tilesathome@openstreetmap.org">Tilesathome@openstreetmap.org</a><br>
<a href="http://lists.openstreetmap.org/listinfo/tilesathome" target="_blank">http://lists.openstreetmap.org/listinfo/tilesathome</a><br>
<br></blockquote></div><br></div>