[Imports] Sorting changes

[Ian Dees]

On Thu, Oct 15, 2009 at 2:18 PM, andrzej zaborowski <balrogg at gmail.com>wrote:

> 2009/10/15 Ian Dees <ian.dees at gmail.com>:
> > On Thu, Oct 15, 2009 at 2:02 PM, andrzej zaborowski <balrogg at gmail.com>
> > wrote:
> >>
> >> Hi,
> >> the other day I talked to Richard Weait on irc about upload utilities
> >> and we thought it would be nice for big uploads, which need to be
> >> split anyway, to be split "logically", so that the changes appear in a
> >> similar order to how a human editor would draw them.  This little
> >> script doesn't exactly achieve this but does the trick for me:
> >> http://www.openstreetmap.pl/balrog/bulkupload/smarter-sort.py
> >>
> >> A number of times I had a situation where my upload script first
> >> uploaded all the payload of new nodes, and then before I finished
> >> uploading ways, a human editor saw unused, untagged nodes and started
> >> deleting them causing conflicts, so now I run this script before
> >> splitting changesets.
> >
> > What converter/upload script are you using that creates node payloads
> before
> > uploading the ways? I would say that you should be fixing your upload
> and/or
> > convert script before you worry about sorting changes...
>
> I use a couple of simple python scripts, creations are sorted nodes
> first, then ways, then relations, modifications are left alone and
> deletions in relation-way-node order.  What other ordering can you use
> to make (almost) sure the api doesn't barf at your changeset?
>

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.

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/imports/attachments/20091015/0048b2d5/attachment.html>