On Wed, Jan 28, 2009 at 11:51 AM, Brett Henderson <br...@bretth.com> wrote:
> Frederik Ramm wrote: > > Will the planet dump and/or diffs be extended so that they contain all > > changesets too, or what should be the preferred mode of operation for a > > third-party application that wants to track changesets? The only way I > > can currently think of would be looking at diffs to find out which > > changeset IDs were active and then download them individually. Have I > > overlooked something? > > > Replication of changesets is on my undocumented long term TODO list for > osmosis (I should add it to trac) but I don't know when I'll be able to > do it. I had some discussions with Shaun and Matt a while back on how > this might be done efficiently. Identifying changesets for replication > is a bit tricky and would probably involve two passes, first pass would > identify all changesets created in a time interval, and the second pass > would identify all changesets modified (ie. have entities referring to > them) in a time interval. Once identified they could be read and > included in a changeset file just like any other entity. > Perhaps you only need to worry about exporting the changeset headers. The members of a changeset can be derived from the elements themselves. <node id='456' changeset='123'> provides enough information in the current diff files to be able to create a table of all changeset members. The only thing missing is the changeset header. > > The reason they're more difficult than other entities is twofold. > 1. They don't have a history table so modifications are much harder to > detect. > 2. The bounding box information attached to each cannot be computed by > osmosis in a "streamy" fashion which means they have to be re-replicated > if they change. > > The two stages of changeset identification cause other problems such as > being able to retrieve changesets after identification in an efficient > manner (ie. not one by one), and potentially having to store identifiers > in memory which is problematic at least theoretically if long interval > changesets are being extracted (not likely to be an issue for the > current daily changesets). > > Bit of a brain dump there but they're some of the reasons I'm holding > off until I have a decent amount of time to invest in it. > > However, if replicating into a database osmosis will "invent" > changesets. It will create one changeset per user per changeset > interval which will approximate the real thing. It won't help if you > need the real changeset id though. > > Brett > > > _______________________________________________ > dev mailing list > dev@openstreetmap.org > http://lists.openstreetmap.org/listinfo/dev >
_______________________________________________ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
