[OSM-dev] Slippy map's future

[Raphael Jacquot]

James R Glasgow wrote:

> Lars Aronsson wrote:
>> This Saturday, Nick Whitelegg wrote:
>>
>>   
>>> We really need OSM to be as amenable to mashups as Google is 
>>> now,
>>>     
>>
>> This sounds nice, but you forget that Google has immense hardware 
>> and manpower resources behind its services.  This doesn't scale 
>> for us.  However, there is a way out:
>>
>>   
>>> * The slippy map should be based off planet, to maximise performance.
>>>     
>>
>> If we can make an easy to follow recipe for setting up a slippy 
>> map server and loading it with the latest weekly planet.osm dump, 
>> anybody can set up a server, tweak the software, and create their 
>> own experimental services.  The amount of traffic they draw will 
>> be independent of OSM's central hardware resources.
>>
>>

> One solution to this problem would be to set up a system of mirrors,
> volunteers mirroring a central server running the same software and data
> kept in sync with something like rsync. When someone made a map request
> the openstreetmap.com server could return a location redirect to the
> requesting party with the address of the requested page on a
> geographically close mirror. This should lessen the load on the main server.

(fixed the ugly top posting & html)

what you are proposing is in fact what google does. they have tons of
servers and thus can use that in a huge load balancing scheme.
I would add one further to that, we need the thing to work differently.
IMHO, we need to generate new tiles in a background process, and only
serve up pre-computed images, just like google does.
this amounts to optimize for speed vs optimizing for space. but
considering the price of 320GB drives these days (about 100€), I think
it would be a better way.

Google maps works by having the javascript code request the images of
the tiles (instead of a script that could timeout). they're using their
google file system to store the things, which we don't have available.
we can however use a filesystem allowing deep directory structures (one
level per zoom level)