[OSM-dev] Oh dear - planet has duplicate id's

[Dan Moore]

i hope some of this is useful, thanks for breaking it down:

> (a) the planet generation is wrong: there really isn't a duplicate id, it's just that the plant dump 
> for some reason repeated a couple of segments. So, do the offending segments also exist as
> duplicates in the database?

i checked this (perhaps a little casually): http://trac.openstreetmap.org/browser/utils/planet.osm/planet.rb?rev=1541 - if that is the script, i don't see this being the problem - the lack of uniqueness constraint strongly indicates this is a reflection of the database. (even if this isn't the dump script, it probably isn't dissimilar).

>(b) did some tool provide the offending ids like that, and if so why did the server accept them?
> Which tool, and who needs to fix it?

    <tag k="created_by" v="almien_coastlines" />

this is, perhaps, an indication - or at least the purpose of the tag as i understand it - though this tag doesn't reflect creation vs modification(s) well, so may be misleading.

> (c) Or is the server logioc wrong, perhaps encountering an exisiting id is supposed to treat it as
> an update to the segment when in fact it was handled incorrectly as an insert. That would be a 
> major bug if so, threatening the whole integrity of the data.

again, at a probabilistic level, i think you'd see very major and obvious corruption if this were the general case - this might be a specific edge-case logical path though.

> (d) or maybe there is a timing problem whereby two clients trying to add segments at the same
> time get allocated the same id. Again, major integrity problem.

dunno: maybe?  i'm a little bit nervous of the (perhaps pragmatic) fracturing of server code into api and potlatch sides, there's some (perhaps small) chance that has a part in this.

> Finding the root cause of the problem seems like the most important activity IMO.

aye, well, i'd agree it's important - i think there's a lot more integrity problems than just this, though, it's part of the scheme/plan/model/constraints - sooner or later we're going to have to make decent progress on this side of things.

> David

cheers, dan.


_______________________________________________
dev mailing list
dev at openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev





       
____________________________________________________________________________________
Yahoo! oneSearch: Finally, mobile search 
that gives answers, not web links. 
http://mobile.yahoo.com/mobileweb/onesearch?refer=1ONXIC