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

[Manchun Yao]

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. 

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.  

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).  

Thanks
Manchun
-----Original Message-----
From: Andy Allan [mailto:gravitystorm at gmail.com] 
Sent: Tuesday, October 05, 2010 3:50 AM
To: Manchun Yao
Cc: dev at openstreetmap.org
Subject: Re: [OSM-dev] Fail to get OsmChange for some changesets

On Tue, Oct 5, 2010 at 12:49 AM, Manchun Yao <manchuny at microsoft.com> wrote:
> I am learning how the change set works in OSM.  I assume that if I can 
> apply the change sets of a particular area one by one then I can 
> obtain the current osm map of that area. Is this a valid assumption?

Not really. Changesets don't affect the database in one go, so you can have two changesets affecting different objects in non-sequential orders. For example

Changeset 1: Node 10v1 Node 11v2
Changeset 2: Node 10v2 Node 11v1

You can see there's no order of applying these changesets that will leave your database with both nodes on v2. This is very rare in practice, but it might trip you up at some point.

> I picked the Boulder, Colorado area since the number of changes there, 
> roughly 350,  is about right.   During the tests, I noticed that I 
> could not obtain the OsmChange of the following changes: 145015, 
> 4318130, 4318132, 4318136.

You're going to have to explain further what you're doing, but it doesn't sound like you are editing the data, so making repeated requests to the editing API isn't the best way. Are you trying to build a history of all the changes for the area? Or are you trying to end up with the current state of the map?

Cheers,
Andy