On Wed, Oct 22, 2008 at 2:50 AM, 80n <[EMAIL PROTECTED]> wrote: > On Tue, Oct 21, 2008 at 12:39 PM, Brett Henderson <[EMAIL PROTECTED]>wrote: > >> Hi All, >> >> >> > > Changesets are not atomic transactions, so I don't see any point in trying > to identify and work with closed changesets. There's no rollback for a > changeset and incomplete changesets don't break anything. > > As I understand it the changeset bbox is derived data so I don't see any > need for osmosis to provide it. The consumer can derive it, the same way as > the main server does, if it needs it. > > I'd be quite happy with option 2, but without any bbox info. > > If you really want to provide bbox info then you'd probably need to provide > a feed of changeset changes. Each time the bbox is extended by the main > server you'd need to supply a changeset update with the new bbox values. > This is doable, but seems a bit pointless really. >
Okay, thanks for the feedback. I'll have to proceed with Option 1 initially to get something working. Option 2 will require the planet dump to include changesets which will need some more time to get included. If the planet dump doesn't include changesets the diff files may refer to non-existent changesets if the diff was created prior to the changeset being created. So I'll get Option 1 working with fairly useless changesets, then look at how to modify the planet dump to include changeset details, then how to update osmosis to use Option 2 with an enhanced osmChange file format. Brett
_______________________________________________ dev mailing list [email protected] http://lists.openstreetmap.org/listinfo/dev
