consecutive identical nodes in way #1296
Comments
|
Duplicate of #1249. |
|
Whoops, sorry, indeed I read too fast. |
|
The bug is easily reproducible for at least one method of creating such data: see http://api06.dev.openstreetmap.org/browse/way/4295031661 Start drawing an area, double back on one node, like this: http://api06.dev.openstreetmap.org/browse/way/4295031665 A further way of reproducing the issue is to merge two overlapping ways and remove the last common node. |
|
Thanks @simonpoole. The first scenario you mentioned should be fixed (you can test on http://www.openstreetmap.us/iD/master/). Can you elaborate on "merge two overlapping ways and remove the last common node"? Do you mean:
That would be a special case of the first scenario. |
|
The root cause is the same (deleting a node between two identical ones), the only difference is the route to creating the same situation (without using the area drawing function). |
|
Thank you. |
|
Problem persists. |
ghost
assigned
|
This changeset is going to be the easier one to try to debug, as it's fairly small and hasn't been reverted. It contains new versions of this landuse=retail with duplicate nodes here and here, and Leon Creek Greenway with duplicate node here. |
|
Here the way diffs: |
|
Here's a visual thanks to the JOSM Reverter plugin: Colored is old version, gray is new version. The nodes with arrows were moved/duplicated, the circled nodes were deleted. |
|
I would really like to know what mrplumbersa did in that edit session. I tried a number of things and couldn't get any duplicate nodes. I suspected connecting via dragging a vertex onto another vertex, but there's a bug in 1.0.0 that prevents dragging a vertex that's shared by two ways onto another vertex, which limits the possible drag operations that could have been done with the nodes in question. |
|
A lot more broken ways are created since iD 1.1.1 has been deployed. way 232404554 v1 2013-08-05T06:19:00Z 17223343 iD 1.0.1 maa83 way 232574451 v1 2013-08-06T19:31:05Z 17245869 iD 1.0.1 Maarfuchs way 192382267 v5 2013-08-07T17:19:11Z 17256593 iD 172898b Xavier fung way 232722947 v1 2013-08-08T02:27:04Z 17261465 iD 1.0.1 jejoenje way 121310621 v3 2013-08-09T08:45:12Z 17276070 iD 1.0.1 vaggelas way 233036806 v1 2013-08-10T18:54:59Z 17294905 iD 1.1.1 witek1936 way 233179730 v1 2013-08-11T21:40:48Z 17309713 iD 1.1.1 gvil |
|
Same with iD 1.1.2. way 233423327 v1 2013-08-13T19:11:04Z 17335674 iD 1.1.2 Gallamine |
|
@mapjedi Do you have any idea how to reproduce this? I've looked at several of the examples you posted, and tried to figure out what sequence of edits can generate consecutive duplicates, without luck. |
|
Unfortunately, no. I only see the results (tracked at https://toolserver.org/~mapjedi/blame.txt). I can only suggest to directly ask the corresponding users, preferably those who are more than "hit and run mappers" or those who have managed to break ways on several distinct days. In the case of JOSM this has helped in isolating a few bugs (not all yet). I guess that ways which got broken in version >1 are in general more promising to look at if you want to figure out what might have been done.
|
|
I've found an edit sequence that consistently creates duplicate nodes in a way:
|
Previously, adding a midpoint to an invalidly doubled-back segment (aba) resulted in a self-intersection with an invalid consecutive node (accba). Now a self-intersection is still produced, but with only one c node (acba). Refs #1296
|
Fantastic, thanks so much. That was easy to fix. |
|
I'm not sure that that was the only case, but I'm going to hope that it was and close the issue. @mapjedi, thanks for keeping an eye on this and please reopen the issue if you see it occurring with future versions of iD (1.1.7 or later). |
|
Seems to still be happening with turning circles (or something the user is doing). Here are a couple of examples: http://www.openstreetmap.org/browse/way/17369643/history changesets (from this week): http://www.openstreetmap.org/browse/changeset/17861130 (Edit: I missed the 1.1.7 or later in the previous comment, those examples are with 1.1.6...) |
|
This seems to be still present in 1.2.0: https://toolserver.org/~mapjedi/blame.txt :( |
|
Issue #1956 was my duplicate of this issue. I'll look for a pattern when fixing some of these new duplicate nodes. The duplicate nodes that I corrected before iD was released looked to be Potlatch 2 generated. I don't know if the Potlatch maintainers had a resolution that you could search for. The only duplicates that I saw from Josm looked to be bad data relating to imports in Europe mostly. |
|
@drkludge Regarding Potlatch: the issue has been known for a long time. It was reported some four years ago; recently the trac ticket https://trac.openstreetmap.org/ticket/2501 got closed as "wontfix". However, it appears that the problem was fixed to some degree, probably by accident, in early October of 2012, as P2's creation rate dropped steeply within one day. In earlier years, both Potlatches used to create several dozen broken ways per day, the same order of magnitude as iD does now, while the contribution by P1/P2 is now almost negligible (though the single-node ways also reported in the old ticket are still created in abundance). |
|
@mapjedi I had no knowledge of these prior issues I was just providing information about what I had observed. I can concur that the Potlatch problem was accidentally fixed. There were no more new duplicate nodes after I finished my round of corrections in July. Josm may have caused problems but I did not know that either. My steps may be cumbersome but they help me remember processes for reference later. That's also why it is under my personal page and not elsewhere in the wiki. The other reason that I wrote the page is that I had no knowledge that the validation had this option. There's so much to learn. Finally, this bot phobia thing in the community is just daffy. If there are known problems with editors creating duplicate nodes and marked as "wontfix", why on earth are volunteer's valuable time wasted fixing a known problem that a bot can safely fix? My manual review and correction of these issues added no value to the process! I just "wontfix" these problems again with a known solution in place. |
|
something more on-topic: I had a chat with a user who managed to create a substantial amount of duplicate-identical-node-ways (about 1 out of 5 of his ways were affected, but only in a few of his changesets). He told me that he didn't do anything special: He used the area tool to draw buildings and then used the rectification tool. He also didn't see any ui glitches. He's using Firefox 25 on Windows 8. So, I guess we are not searching a fancy usage pattern to cause this bug. But what could it be? 😕 |
|
Here is a changeset that really baffles me: http://www.openstreetmap.org/browse/changeset/18696474 – The user only moved a postbox on a building outline (and changed one tag of a nearby poi which I think is unrelated) and still managed to get the postbox-node duplicated in the building. |
|
I have been seeing a similar situation with duplicate ways. It looks like for both situations I am noticing, the user is adding a tag without using the presets, but I haven't tried to analyze that much. |
|
@mapjedi it looks like your |
|
@tyrasd Unfortunately, no, i can't. With the decommissioning of the Wikimedia toolserver, all accounts there have been expired, and right now I am lacking both the time and access to an adequate machine to have up-to-date statistics generated. However, iD still creates an impressive stream of broken ways. A representative sample (those in Germany, unless someone else is faster at fixing them) may be found in changesets like this one: http://www.openstreetmap.org/changeset/20742315. |
How did you generate the list? I have access to databases and powerful enough machines |
Ah, I see - osmium and emacs lisp. This SQL query mostly works, but also returns issues like ways with nodes AA SELECT id, nodes
FROM ways WHERE EXISTS
(SELECT * from (SELECT e, lead(e) OVER () AS le FROM unnest(nodes) u(e)) s WHERE e=leIf someone gives me a date (or preferably minimum changeset_id) I can generate a list of any new ones |
|
Wall-E ran last a week ago, so I guess you can start then (that was Simon Am 03.03.2014 11:40, schrieb Paul Norman:
|
|
I've put a backup copy of the old file at http://osmac.bplaced.net/blame.txt ; it ends around cs 19700000. For generating new reports I would suggest starting from there. Computing power is not really an issue in generating current stats (processing the diffs took only a few seconds using rather slow tools); having moved only a couple of weeks ago, right now I simply don't have a fast internet connection or otherwise acces to a permanently connected machine to run cron jobs on, nor the time to set up a new process. |
|
It's a pure list of way IDs with no other information attached |
|
A recent changeset which created a dup node in way 234752583 https://www.openstreetmap.org/changeset/28292892 |
|
It is possible to combine any ways that have common first or last nodes. So if these ways have any another common nodes we can create selfoverlapping ways with duplicated nodes, even like this: |
|
In the changeset, https://www.openstreetmap.org/changeset/28292892, that simonpoole reported
The joining areas look like a great place to look for this duplication issue. I wonder if the "double tap" code is also an area to focus on. I wonder if 1650627780 is the "double tap" node to close of the way modification. The original thought that brought me here was that the OSM database only stores seven digits in fraction. I was wondering if the rounding process contributed to the duplication problems. But that would mean node on node not duplication of nodes in a way. The rounding code may still be another wild idea to look at. |
|
@bhousel I have copied the following information from #3676 as requested, and I have added a link to the node. I have watched iD generating a duplicate when testing for my pull request #3631, which is nicely monitoring such duplicates. I don't think the problem was due to my code modification. There were only the modification of the sidebar, but not the changes to mode select at that stage. And the sidebar haven't been opened when the bug occurs.
That was my first idea too, but I haven't been able to reproduce it. Maybe its needs to be too fast to be reproduced intentionally. |
Please make sure not to create ways containing multiple consecutive references to the same node (e.g. A-B-B-C).
Simple solution: before uploading, iterate through the each way's list of nodes and discard those which are identical to their immediate predecessor. However, such a situation should not even arise in the first place, so something is rotten elsewhere in the code if such a way is found.
Proof that the issue is not hypothetical:
http://www.openstreetmap.org/browse/way/216250602 v1 2013-04-07 iD 0.0.0-beta1
http://www.openstreetmap.org/browse/way/207430096 v1 2013-02-27 iD 0.0.0-alpha2
http://www.openstreetmap.org/browse/way/207323200 v1 2013-02-26 iD 0.0.0-alpha2
http://www.openstreetmap.org/browse/way/181500153 v5 2013-03-11 iD 0.0.0-alpha2
http://www.openstreetmap.org/browse/way/178471693 v2 2013-04-08 iD 0.0.0-beta1
http://www.openstreetmap.org/browse/way/44173536 v8 2013-04-05 iD 0.0.0-beta1
The text was updated successfully, but these errors were encountered: