Martin Raifer

should be resolved now

yeah, I just tried it with adiff 2230746 (which corresponds to the time between `2016-12-09T10:01:00Z` and `2016-12-09T10:02:00Z`). Here's the results in chronological order: * the api_mmd instance (canonical url http://dev.overpass-api.de/api_mmd/augmented_diff?id=2230746)...

Looking at the actual (OSM) minutely-diffs, it seems like not all of the updates for each minute is contained in the same diff: [220430](http://planet.openstreetmap.org/replication/minute/002/220/430.osc.gz) contains data until [`2016-12-09T10:02:02Z`](http://planet.openstreetmap.org/replication/minute/002/220/430.state.txt), but the...

> I think most timestamps are assigned by ruby, not by the database [Here](https://lists.openstreetmap.org/pipermail/dev/2016-August/029426.html) @lonvia mentioned that object timestamps should be set by the db

> Indeed very tricky question... The only real solution I can currently think of would be for Overpass to store an additional meta field for each object version, namely the...

> `txnActive` is not empty […] Oh, cool. Nice idea! I didn't know about those fields.

> Transaction length in minutes / transaction number: Looking at those ids, it seems like they are all from the late 2012 period (somewhat shortly after the redaction period). These...

>> AFAIK, hourly/dialy diffs are just concatenated minutely diffs. So, the open transactions for a hourly diff would be the same as for the last minutely diff it was made...

In http://www.openstreetmap.org/user/geohacker/diary/40846, it sounds like @geohacker found a workaround for this issue: > A changeset being closed doesn't mean that all features that changed have been committed to the OSM...

~~I heard that for some tools it is necessary to sort elements in such a way that relations come first, then ways and then nodes. Basically like the current id-sorting,...