[OSM-dev] way 7062297, is this new?

[Matt Amos]

On Thu, Oct 9, 2008 at 2:31 PM, Stefan de Konink <stefan at konink.de> wrote:
> If 0.6 is not supporting it, it should not be possible to enter the data
> today. (imho)

lets do a 0.5.5 release with this fix in. hmm, we should include
referential integrity as well, since that can cause similar types of
problems... and make API calls atomic ... and have changesets for
reversion.

oh, hang on, that *is* 0.6 ;-)

we're working on it and it'll be ready as soon as its ready. if you'd
like to help then that would be fantastic.

> Can I conclude that regression testing is something that should be
> implemented for any editor? Or do you place the blame yourself at the
> API that allows this, while any other editor will drop this?

actually, you can't assume that the edits were done using potlatch -
it may have been some small, homebrew editor which caused the problem
and didn't correctly set created_by. after all, created_by is like
browser user agents; impossible to enforce.

imho, the most likely place to look for the error is the
amf_controller (which, being neither potlatch, nor API, occupies some
weird limbo), as there have been problems with race conditions there
before, which 0.6 will fix.

> I think we should fix this issues where there is so added value of
> duplication soon. I'm happy to do it manually using one of my parsers,
> does anyone has serious objections against it?

here is a complete list of all (35) elements with duplicate tag keys
in the most recent planet:

node/26550449
node/26550451
node/27419813
node/53399519
node/53399526
node/53399529
way/4328988
way/4940234
way/5356387
way/6208313
way/7062297
way/10431777
way/10639405
way/12302584
way/12700083
way/13349899
way/14350531
way/14357532
way/14364162
way/15235135
way/17488691
way/21980477
way/22062136
way/23462995
way/24957291
way/25914984
way/26052148
way/26443819
way/26509730
way/26784196
way/27226165
way/27411706
way/27565355
way/27568976
way/27583724

you'll notice that "JMEditor", whatever that is, is responsible for
the node errors. and all the way errors are duplicates, so there is
never a conflict in reducing them. if you'd like to fix these then
that would be great.

cheers,

matt