[OSM-dev] Osmosis Plans

Robert (Jamie) Munro rjmunro at arjam.net
Tue Sep 25 14:42:38 BST 2007

Hash: SHA1

Brett Henderson wrote:
> It can be used for a number of things due to the different ways tasks 
> can be plugged together but here are a number of potential use cases:
> 5. Changeset derivation from database.
> 6. Changeset application to offline mysql database.

AFAICS, these two are the most needed, and should be put into action
ASAP. We should run 5 every hour, and make the changesets available for
download, until the next planet dump occurs. We do need a way to make
the planet dumps consistent with the start of the changesets.

> 5. This is the most useful part of osmosis, but I'm not hearing a lot of 
> interest in this at the moment.  I'd love to see an end use of osm data 
> hook into this capability (eg. tiles at home or mapnik) but I'm not sure if 
> this is seen as useful.  Obviously the TIGER data needs to be cleaned up 
> but a real use of this capability would provide reasons for doing so.
> 6. Dependent on 5, and can be used for several things.  A. It allows a 
> db to be updated to the current state much quicker than a new import.  
> B. It can be used to mark data as changed (eg. automate map re-render 
> requests).

> I'm keen to hear people's thoughts.  I'm not sure what I should focus 
> on.  I believe the replication features would be useful to help the 
> project scale to a much larger size.

Absolutely work on replication. We shuold set up a read only MySQL
username on the main database, and get Osmosis running as often as
possible using it (hourly would be OK, every 10 minutes would be
better). Perhaps these changesets could be merged every hour or six
hours into a single changeset, and then applied to the downloadable
planet file. So every hour we have a new planet file, and we have
changesets for every 10 minutes since the last planet file.

If this makes too much load on the DB server, then other things should
be reduced to compensate - all T at H requests could go to zappy (which
would be able to be only 10 minutes out of date), for example.

The next thing is to allow the changesets to be applied to the PostGIS
database used by Mapnik. It would be great if that could be updated as
frequently as it is capable of being rendered.

Robert (Jamie) Munro
Version: GnuPG v1.4.6 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org


More information about the dev mailing list