[Imports] Sorting changes

andrzej zaborowski balrogg at gmail.com
Thu Oct 15 20:48:37 BST 2009

2009/10/15 Ian Dees <ian.dees at gmail.com>:
> On Thu, Oct 15, 2009 at 2:18 PM, andrzej zaborowski <balrogg at gmail.com>
> Are you uploading one node at a time with the PUT API calls or are you using
> the osmChange diff upload? If you use the diff upload, the entire thing will
> show up on the map at the same time.

So say I have a 60k element changeset, a single diff upload only
allows you 50k so you have to split it anyway (furthermore I notice
that diffs of around 500 - 1k elements get processed the quickest,
above that the delay between upload and merging into the database
seems to grow exponentially -- and with it the risk that your
connection dies while you're waiting for the API response, and when
that happens, you basically have to start the whole upload again --
because the API will commit the changes anyway, but you won't receive
the diffResult so you can't map your negative IDs to the new IDs).

I forgot to mention that beside my python scripts I'm using JOSM as
part of the toolchain.  Converting data is easy, merging it with
existing OSM data using JOSM is where the real work starts, and at the
output of JOSM you get a mix of features with different action= tags
or no action tag, so after you convert it to .osc, this is where you
would want to use the script I linked.

> Which brings up a good point -- why is it that data from changesets that are
> not closed show up on the API at all? If someone is in the middle of PUTting
> 1000s of nodes, followed by 100s of ways and relations, none of that data
> should show up until they explicitly call the changeset/close API call.

Only the PUT calls are guaranteed to be atomic, if it was not for
that, I believe (although I have not written the api) that it would be
extremely difficult to implement the whole api.


More information about the Imports mailing list