[OSM-dev] Questions/Ideas/Plans on OSM Infrastructure
eimann at etherkiller.de
Thu Sep 17 13:45:58 BST 2009
Kai Krueger schrieb:
> On 22/07/28164 20:59, Dominik Bay wrote:
>> Hi all,
>> I'm coming up with a topic for discussion on how to save and
>> serve OSM data for Slippy Maps, Mobile Devices and handling
> I am not entirely sure what you are trying to achieve with this topic
> and who you are targeting with it (Osm sysadmin? potential donors? The
> community and what they want from OSM, or are you planning on donating
> Hardware your self?), but I will try and comment on some of the points
> about the rendering.
Mainly OSM Admins/Developers on planned features, resolving bottlenecks
and in the end donating/setting up additional infrastructure for it.
>> 2. Why do we need it?
>> Due to growing Software based on OpenStreetMap and OpenRouteService
>> we need a more-realtimish behaviour of our data, to serve mobile
>> Users with actual tiles and a fast route calculation.
> Not sure what your definition of "more-realtimish" is, but I would say
> our rendering is already approaching "near realtime" At least the main
> mapnik layer should currently only have a lag of about 5 to 10 minutes
> behind the main OSM database. During load spikes it could be more,
> although with the new render server put in place a week or two ago, we
> haven't really seen any times when the rendering couldn't keep up.
> Furthermore, with the new replication mechanism of diffs, that is
> starting to be tried out, this lag may get reduced even further to about
> a minute. There is a potential that it feels less realtimish to users
> though due to client side caching. Tile expiry for proxy servers is set
> to something between 3 and 6 hours currently, so if you have visited the
> map before the edits, your browser may still cache the old tiles for
> that duration. The tiles at home layer I think also aims to achieve
> rendering turn-around times of 10s of minutes to couple of hours, so
> isn't that much behind mapnik either.
Ok, that's something I wasn't aware of. Thanks for pointing out :)
>> We also need to get tiles *fast* to our users, this is why they are
>> called *Slippy* Maps ;-)
>> (They are fast at the moment, thanks for your work on mod_tile, I'm
> Yes, the current server can quite happily sustain the full 100Mbs link
> that we currently have available which was demonstrated again the other
> day during the load spike caused by the TV program Quarks and Co.
That's good, so the Backend is already being able to serve many Users ...
> The response time of a single tile should be anywhere between 50ms if
> the tile is currently cached and you have a good connection to where OSM
> is hosted to about 3 seconds, if it tries to render the tile on the fly
> but is too complex to do so and times out to return a slightly older
> cached tile. Which is pretty fast as well.
... but still depends on a low latency to the User who is requesting
tiles. Therefore I am aiming to atleast get that on the same level
anywhere, which does not count in Latency generated by slow links,
packetloss etc. We can't do anything about this problems.
> So at the moment the problem with tile serving, if any, is a question of
> hosting and the increasing bandwidth requirements OSM has. During
> typical daytime tile serving uses about 50 - 60 Mbs sustained with night
> time dropping to 10Mbs. (Tiles at home and cycle map not included)
Which is not much traffic yet but involves a single point of failure.
If this box dies, no tiles are served. Do you have any ideas of traffic
distribution to US/EU/ASPAC? Serving US out of EU wouldn't be that
efficient (to keep the ~50msec as a standard), so it would be nice to
start with some proxies in the US.
>> 3. A short description of what can be done
>> We can make use of things like Anycast and Geo-aware Caching.
>> This means a user connects to a Tile-Proxy which is near his
>> ISP (routing-wise) and holds all tiles which are relevant for
>> the users location (Europe for example) plus the Tiles which
>> are requested often (big Cities).
> Yes, that could theoretically be done, and there have been two
> successful tests in the past with using Wikimedia proxyies. So software
> wise this could presumably be done. Software is not everything though
> and for this to work, you also need the proxy caches and the hosting. So
> again, the issue here as far as I can see it, is hosting. But I am sure,
> if ISPs or datacenters are willing to donate free, reliable hosting with
> 100Mbs - 1000Mbs network links, we could scale up our current tile
> serving quite well. But for the moment, we are limited to the resource
> we currently have.
I'm working on it ;-)
More is coming in the next (two) week(s) I think, so I can give you more
details on specific things.
>> To get a better understanding of the next lines, feel free to open this
>> -> Rendering
>> The goal is to get nearly-realtime rendering of all map-types and the
>> option to easily do customized rendering for supporting events,
>> Wikpedia, etc.
>> This also enables us to support rendering of 3D Layers with very low
> As I said above, we basically already have near-realtime rendering of
> the standard mapnik layer. Providing customizabile tiles of maps, I
> don't think, should be the core focus of the OpenStreetMap project
> itself. For that I think companies and projects like Cloudmade,
> Geofabrik, or Tiledrawer.com are much better suited which have sprung up
> around the OSM dataset. In my opinion OSM should provide, with respect
> to rendering tiles, a sufficiently high quality map so that the general
> public is attracted to OpenStreetMap which then hopefully lowers the
> barrier of entry to start editing and improving the data. But that goes
> into the political question of what OSM stands for and what it wants to
I agree on that, I was just an Idea to present an additional usecase of
> But why exactly are you putting specs together? Are you planning on
> hosting your own rendering infrastructure or donating hardware to OSM?
Yep I'm currently collecting on things which already have been done, and
what we can improve.
To not just putting a text together I'm also working on getting the
ressources in place to kick off with some stuff end of 2009.
Thanks for your explanations. :)
More information about the dev