[OSM-dev] Fail to get OsmChange for some changesets

[Andy Allan]

On Wed, Oct 6, 2010 at 5:59 PM, Manchun Yao <manchuny at microsoft.com> wrote:
> Hi Andy,
>
> If all change sets were created and operated  strictly based on API 0.6, would the scenario you described (two change sets affecting different objects in non-sequential orders) ever happen?  Is the optimistic locking mechanism meant to avoid such things?  The problem might exist in the database because of historical reasons though.

Yes, it's perfectly possible. Individual changes to the data can occur
without the changeset being closed. This is completely by design,
although many people are confused into thinking that changesets are
atomic or delayed until they are closed or similar. They aren't, and
that's deliberate. As for how likely it is to happen without someone
trying to do it deliberately? I can't answer that.

> I indeed want to build the history of all the changes so that I can find the map at some time (for example, Jan. 1, 2008) before.  The full-planet dump files at (http://planet.openstreetmap.org/full-experimental) contain historical info. However, the file is a bit too big for my computer.  I was trying to test whether I can build the history from ground up for a small area by getting the individual change sets one by one. Looks like there are some issues because some "changes" were made before API 0.6 and I have problem to access them using 0.6 API calls.

You could do it by collecting all the data that those changesets refer
to, and then "replay" all the data changes in the order the individual
changes occurred (not in the order that the changesets  were either
opened or closed, which I've explained isn't necessarily the correct
order).

The wider point is that the history dumps are, almost entirely,
currently unusable for most people. If anyone has any suggestions for
solving this problem, or wants to try making a toolchain to process
the history dumps into history extracts, that would be great. There
was discussion previously on adapting osmosis to handle history dumps,
but I don't know if that resulted in any code.

> Do you have any suggestions about how to get these problematic change sets?  Maybe someone with a database populated with the full-planet dump can get these change sets for me (145015, 4318130, 4318132, 4318136).

Perhaps this is supported by one of the read-only api services? I'm
not sure if any of them (XAPI, ROMA, OWL etc) have access to enough
history though.

Cheers,
Andy