[OSM-dev] Various OSM troubles

Andy Robinson Andy_J_Robinson at blueyonder.co.uk
Tue Jan 9 10:27:42 GMT 2007


Dave wrote:
>Sent: 09 January 2007 9:55 AM
>To: Joerg Ostertag (OSM Munich/Germany)
>Cc: dev at openstreetmap.org
>Subject: Re: [OSM-dev] Various OSM troubles
>
>Joerg Ostertag (OSM Munich/Germany) wrote:
>> Currently I don't think the bandwidth for downloading is the problem, but
>the
>> sql-query takes all the resources. So doing a diff probably only doubles
>the
>> needed db-resources.
>>
>>
>>> Imagine I keep my osm data locally. If JOSM starts, it loads that data
>>> file and then asks the server to deliver *only* the data that has
>>> changed since the last sync. This at least would save a lot of
>>> bandwidth, wouldn't it? This even is valid for the future as the user
>>> base grows.
>>>
>>
>> This was something imi already suggested some times. He suggested writing
>a
>> local caching OSM-Server which starts with the current planet.osm and
>then
>> only get the updates. If the central OSM-Database is fast enough this
>> probably would really speed up things on the local machine. But we have
>to be
>> even more carefull with handling editing conflicts.
>>
>If bandwidth isn't really a problem, and we're having DB query time
>issues, couldn't we just set up some MySQL replication magic and have
>the API ruby code split data requests between the master and slaves?
>
>Of course this implies we have more server hardware to spare... I don't
>know what the current hardware situation is; typing Servers on the wiki
>gives lots of nice pictures of people loading racks full of them though
>-- but no hard data unfortunately. And comments on this list suggest
>resources are very limited.
>

A good place to see everything in one place is via the munin page:
http://www.openstreetmap.org/munin/

Cheers

Andy



>
>
>_______________________________________________
>dev mailing list
>dev at openstreetmap.org
>http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev






More information about the dev mailing list