[Tilesathome] t at h/osmarender being phased out (at least from my side)

Sebastian Spaeth Sebastian at SSpaeth.de
Tue Feb 8 15:49:06 GMT 2011


Hi there,

you might have noticed that tiles at home was pretty quiet from my side
although the server is nicely humming along all the time. During the
last 6 month we had 416 user accounts uploading data (possibly using many
more boxes). 65GB of tiles were uploaded just yesterday.

I have to admit that I pretty much lost my motivation to continue
improving the server and the client code. deelkar has been saying that
he would keep the client going but is not likely to implement the next
cool feature either. Also the underlying osmarender implementation in
perl is kind of maintainerless.

I believe t at h has achieved a great deal of things. It is a great proof
of concept for implementing alternative renderers. And using XSLT
transformations to create .svg files out of .osm files. How cool is
that! All credits for that geekie hack go to Etienne (80n) who created
the original xslt templates that made osmarender. We were the first to
provide current maps when someone edited the data. And we were the first
system to have data validation layers.

It is also a great concept of a distributed renderer, which helped to
keep the world's maps up to date when mapnik could only be run on weekly
or even older snapshots. Furthermore, being separate from the OSMF
foundation infrastructure, we were an independent provider of map tiles
without usage restrictions to this day. No one could shut us off and we
were not limited by policies decided on by someone else.  

t at h has spawned a great deal of innovations surrounding the renderer
system. Due to our need of downloading huge amounts of data we triggered
the development of several read-only API servers that were able to
satisfy our needs. osm diffs every minute helped to keep the RO mirror
system up to date without burdening the API much. Custom layers helped
to identify data errors (maplint). Lots of great stuff there.

However, in its current form it passed its zenith. Developments such as
wikimedia's toolserver, mapcss clients, mapnik realtime updates, and 3rd
party improvements such as cloudmaps custom style editor achieved much
of what osmarender/t at h set out to do (at least in *my* vision)

There are also disadvantages, some of which could be fixed easily,
and some which are inherent in the current architecture:

- Being distributed we require huge amounts of data being transferred
  over the network. Each render client requested a new z12 tile
  full of data for each update.

- By proactively rendering the world on each change rather than
  rendering on demand, we uploaded lots of data much of which was never
  viewed. Generally, the server upload bandwidth is approximately equal
  to the server download bandwidth, so we were quite wasteful there.

- Mapnik has gotten so efficient that a single powerful box is able to
  keep the world up to date, while we were keeping lots of computers
  busy. During the last 6 months, we had 416 user accounts uploading
  data, and 65GB of data has been uploaded just yesterday.

- The osma client in perl is pretty much in abandoned state, and other
  clients seem to become more advanced as time goes by. It would easily
  be possible to switch the current tilesGen.pl client out for a
  different one, but no one seems to be interested in doing that
  development. And no one has volunteered during the previous years
  either.

- Using inkscape to render the tiles is obviously not optimal for the
  size of the tiles that we are rendering. We are still witnessing hangs
  and freezes. At least to corruption of the inkscape user config files
  seems to have been solved by now :-).  Admittedly, we probably force
  inkscape to perform feats it has not been designed to do.

- Similarly the stylesheets: I consider the openness in tweaking style
  sheets one of the killer features of the current system. Anyone with
  an OSM svn account can change the t at h style and improve it. However,
  there seemed little interest in really developing this
  further. Besides the tireless petschge whom I would like to thank for
  his efforts, and user "Mueck" who recently seems to have done stuff,
  not many people seem interested in tweaking and improving things.
  So easily modifyable style sheets don't seem to be needed by the
  community, at least not in the osmarender form :).

WHAT IS GOING TO HAPPEN

I will keep the server running as is, but I will not be making great
improvements to it. Deelkar is going to keep the tilesGen client running
but willnot be making great improvements to it. So these are the
possibilities:

- We keep things running as is until something (likely the server or our
  RO mirror network) breaks.

- Someone volunteers to take over client development (either the
  existing one or a replacement in whatever language you prefer). The
  server is pretty client agnostic, all it does is dish out requests and
  take back tileset files, so that could be done by whatever app.

- Some one volunteers to take over server development. This would likely
  involve getting a new server, as I will not be allowed to hand out
  access to the current one, unfortunately.

It has been a wild and fun ride over the years for me. I'd like the thank
Oliver White for conceiving t at h in the first place, petschge and deelkar
for everything they have done on the client side, server side and
otherwise. Frederik Ramm for helping with code (the perl implementation
of osma), advise and moral support. Bobkare for helping out with the
rendering code, and xslt stuff. Of course all those bug reporters and
testers helped a lot, you know who you are (yes, Alfons, for example
you!)
And last but not least, all those tireless renderers that keep
the world up to date. Keep them running!

Let me know what you think and how we should be proceeding. If you
volunteer to take over something or want to be involved in an effort to
reorganize things speak up.

spaetz
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://lists.openstreetmap.org/pipermail/tilesathome/attachments/20110208/9ccfd15b/attachment.pgp>


More information about the Tilesathome mailing list