[OSM-dev] Osmosis Plans

Martijn van Oosterhout kleptog at gmail.com
Tue Sep 25 09:45:38 BST 2007


On 9/25/07, Brett Henderson <brett at bretth.com> wrote:
> 2. Again, Jon Burgess has written an excellent C implementation of a
> planet difference generator that is somewhat faster than osmosis (mainly
> due to osmosis parsing data into full objects incurring a large date
> parsing overhead and writing data back into string format).  Again,
> osmosis is not necessary here.

To be honest, the fact that you do normal parsing is *good*. I think
the time I wasted due to regex parsing producing the wrong answers is
probably more than the time saved by such an implementation. As the
saying goes: I can give the wrong answer in no time at all.

The planetdiff is a bit of a special case, but as you say, there are
many use for the data that have not yet been forseen.

> 4. The snapshot task is not as fast as dumping current tables but it has
> a number of advantages.  It can be used as a starting point for db
> changeset derivation (therefore only has to be done once), can be used
> to obtain a snapshot for any point in OSM history, and it avoids all
> referential integrity problems with the current planet creation
> process.  However it is useless at the moment due to the old TIGER data
> in the history tables.

Personally I think the history tables should be restarted at the 0.5
transition. The new code base is way better than the old one and now
is a good time to start with a clean slate.

> 7. There are other scripts in the repository that already do polygon
> extraction.  Not sure if osmosis is seen as useful here.

Again, the fact that it does proper parsing is more important to me.
If I ever do something like the AND thing again, I'm absolutly going
to use osmosis, because I'll know it's not relying on obscure
assumptions about the format of the data.

> 9. This is something I hoped osmosis would facilitate but it is
> dependent on regular changeset derivation being established.  It seems
> to be that there are a myriad of uses for osm data that don't fit well
> into the existing schema (eg. routing, mapnik rendering, etc).  If
> osmosis can provided a regular feed into these alternative schemas then
> it should allow them to provide services based on access to current data.

I'm looking forward to this, I don't know what the hold up is, but
even if it can only produce *approxiate* results due to bad data in
the DB, it's still a million times better than what we have now. I'm
sure people won't mind resynchronising with the planet dump every once
in a while. (Just as an example, for the detecting of changed tiles in
t at h a 99% complete diff will be as good as a 100% one).

Have a nice day,
-- 
Martijn van Oosterhout <kleptog at gmail.com> http://svana.org/kleptog/




More information about the dev mailing list