[OSM-dev] Osmosis Plans
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