[OSM-dev] Osmosis Plans

Brett Henderson brett at bretth.com
Tue Sep 25 10:04:11 BST 2007

Martijn van Oosterhout wrote:
> 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.
That's certainly my preference.  We lose way history anyway so there 
doesn't seem much point keeping node history.
>> 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,
As for the holdup, perhaps it's just me not asking for it to be done.  I 
guess that's what I'm trying to figure out.

If 0.5 is a logical time to start using it then that makes sense, I just 
want to make sure I'm not putting effort into something that has no value.


More information about the dev mailing list