GoMap duplicated nodes

there is something strange going on in latest/testflight: some areas have duplicated nodes (one is part of the area, the other is under it at the same position but not connected), both nodes share the same id and metadata, it either happens for all nodes of the area (tagged landuse=forest and landcover=trees), or it doesn’t happen. When I move the unconnected node it doesn’t move the twin node or area, so I end up with the same node id on 2 different objects. The untagged unconnected nodes get a transparent brown square icon that is why I noticed them.

Apr 13 '19 10:04 dieterdreist

I made some tests: the disconnected nodes prevails, e.g. if I delete it and move his brother and add tags to it, the resulting xml is:

<?xml version="1.0" encoding="UTF-8"?>
<osmChange generator="Go Map!! 1.6.2" version="0.6">
  <delete if-unused="yes">
    <node id="908478127" timestamp="2010-09-12T14:39:28Z" version="1"></node>
  </delete>
</osmChange>

when I do it the other way round and first delete the node in the area and then add a tag and move the twin node, I don’t get the deletion (but the node is removed from the way and I get the position and tag changes which I didn’t get in the first test):

<?xml version="1.0" encoding="UTF-8"?>
<osmChange generator="Go Map!! 1.6.2" version="0.6">
  <modify>
    <node id="908478127" timestamp="2010-09-12T14:39:28Z" version="1" lat="41.86024177549933" lon="12.4791732651614">
      <tag k="fixme" v="test"></tag>
    </node>
  </modify>
  <modify>
    <way id="77168449" timestamp="2016-02-24T10:11:40Z" version="5">
      <nd ref="908478232"></nd>
      <nd ref="908478152"></nd>
      <nd ref="908478275"></nd>
      <nd ref="908478174"></nd>
      <nd ref="908478214"></nd>
      <nd ref="908478111"></nd>
      <nd ref="908478131"></nd>
      <nd ref="908478294"></nd>
      <nd ref="908478066"></nd>
      <nd ref="908478229"></nd>
      <nd ref="908478247"></nd>
      <nd ref="908478146"></nd>
      <nd ref="908478190"></nd>
      <nd ref="908478085"></nd>
      <nd ref="908478101"></nd>
      <nd ref="908478263"></nd>
      <nd ref="908478314"></nd>
      <nd ref="908478205"></nd>
      <nd ref="908478270"></nd>
      <nd ref="908478171"></nd>
      <nd ref="908478209"></nd>
      <nd ref="908478106"></nd>
      <nd ref="908478291"></nd>
      <nd ref="908478063"></nd>
      <nd ref="908478225"></nd>
      <nd ref="908478245"></nd>
      <nd ref="908478144"></nd>
      <nd ref="908478186"></nd>
      <nd ref="908478080"></nd>
      <nd ref="908478097"></nd>
      <nd ref="908478259"></nd>
      <nd ref="908478311"></nd>
      <nd ref="908478202"></nd>
      <nd ref="908478057"></nd>
      <nd ref="908478218"></nd>
      <nd ref="908478260"></nd>
      <nd ref="908478160"></nd>
      <nd ref="908478177"></nd>
      <nd ref="908478071"></nd>
      <nd ref="908478118"></nd>
      <nd ref="908478194"></nd>
      <nd ref="908478235"></nd>
      <nd ref="908478135"></nd>
      <nd ref="908478148"></nd>
      <nd ref="908478319"></nd>
      <nd ref="908478088"></nd>
      <nd ref="908478251"></nd>
      <nd ref="907706427"></nd>
      <nd ref="908478145"></nd>
      <nd ref="4023293266"></nd>
      <nd ref="908478188"></nd>
      <nd ref="908478082"></nd>
      <nd ref="908478100"></nd>
      <nd ref="908478262"></nd>
      <nd ref="908478312"></nd>
      <nd ref="908478204"></nd>
      <nd ref="908478219"></nd>
      <nd ref="908478119"></nd>
      <nd ref="908478162"></nd>
      <nd ref="908478058"></nd>
      <nd ref="908478072"></nd>
      <nd ref="908478237"></nd>
      <nd ref="908478283"></nd>
      <nd ref="908478179"></nd>
      <nd ref="908478307"></nd>
      <nd ref="908478199"></nd>
      <nd ref="908478242"></nd>
      <nd ref="908478140"></nd>
      <nd ref="908478154"></nd>
      <nd ref="908478323"></nd>
      <nd ref="908478092"></nd>
      <nd ref="908478255"></nd>
      <nd ref="908494119"></nd>
      <nd ref="908494073"></nd>
      <nd ref="908494182"></nd>
      <nd ref="908478274"></nd>
      <nd ref="908478173"></nd>
      <nd ref="908478213"></nd>
      <nd ref="908478109"></nd>
      <nd ref="908478129"></nd>
      <nd ref="908478293"></nd>
      <nd ref="908478064"></nd>
      <nd ref="908478227"></nd>
      <nd ref="908478297"></nd>
      <nd ref="908478193"></nd>
      <nd ref="908478232"></nd>
      <tag k="denotation" v="urban"></tag>
      <tag k="landuse" v="forest"></tag>
      <tag k="landcover" v="trees"></tag>
    </way>
  </modify>
</osmChange>

Apr 13 '19 10:04 dieterdreist

I fear I pushed some of those empty nodes to the map, yesterday: https://www.openstreetmap.org/node/6402747560 is empty, right (I find the changeset UI not very easy to understand…)

Is there a way to get rid of them easily?

XML: https://www.openstreetmap.org/api/0.6/changeset/69184840/download

Apr 14 '19 06:04 tordans

sent from a phone

On 14. Apr 2019, at 08:53, Tobias [email protected] wrote:

I fear I pushed some of those empty nodes to the map, yesterday: https://www.openstreetmap.org/node/6402747560 is empty, right (I find the changeset UI not very easy to understand…)

from what I experienced so far, it is more a UI problem, I could not see nodes actually duplicated on the server (but duplicates in the UI will also lead to confusion and unpredictable behavior if you edit them).

I tried to upload a screenshot yesterday but somehow it’s not here, another try: https://ibb.co/KXDyMBB

Apr 14 '19 07:04 dieterdreist

@dieterdreist if my commited changes look fine, then it might just be a stale datastore or cache. Did you try clearing the OSM object cache? After re-loading the OSM data the view errors where gone for me.

Apr 14 '19 07:04 tordans

sent from a phone

On 14. Apr 2019, at 09:32, Tobias [email protected] wrote:

@dieterdreist if my commited changes look fine, then it might just be a stale datastore or cache. Did you try clearing the OSM object cache? After re-loading the OSM data the view errors where gone for me.

good find, it had indeed to do with the cache, after deleting it the errors went away.

Apr 14 '19 17:04 dieterdreist

@bryceco is it possible that this issue with the cache will happen once you release the app for all users? If so, maybe a new release needs to purge the cache or something similar?

Apr 15 '19 15:04 tordans

Looks like changeset https://www.openstreetmap.org/changeset/72182783 introduced a similar duplicate node. You can't see it on osm.org, but you can from the API or JOSM.

Jul 13 '19 00:07 b-jazz

I will copy my Info from https://github.com/bryceco/GoMap/issues/333#issuecomment-638427228 over here:

I have had a few cases, where mappers have (had to) rework something I mapped while walking. Their comments where, that they removed duplicate nodes.

I could not pinpoint the issue further, yet, but I wanted to start collecting instances in this Issue

https://osmcha.org/changesets/86142530/?aoi=f0b96083-171b-4bbb-af00-c38f24cb7319

https://osmcha.org/changesets/86035743/?aoi=f0b96083-171b-4bbb-af00-c38f24cb7319

Assumed to be "broken" in https://osmcha.org/changesets/86002377/?aoi=f0b96083-171b-4bbb-af00-c38f24cb7319

(There are others but I need to find them again.)

Also Bryce's comment:

My guess is that there is some combination of undo/redo that triggers this, but any information is useful!

Also FvGordon (https://www.openstreetmap.org/user/FvGordon) wrote to me with more info; he wrote in Germany, so I will try a translated summary:

He is using http://tools.geofabrik.de/osmi/?view=geometry&lon=13.29592&lat=31.56540&zoom=8&opacity=0.75&overlays=duplicate_node_in_way to find those duplicate nodes
They seem to be created by iD and GoMap
Error type 1: A way with nodes …-A-B-C-D-…, where B and C have the same coordinates
- Those seem to be created by iD
Error type 2: A way …-A-B-B-C-…, where the nodes are added twice
- Those seem to be created by GoMap
For type 2, https://www.openstreetmap.org/way/375718173 is an example, with the last two nodes being twice in the way:

3802141975 3802141975
- Link to the XML: https://www.openstreetmap.org/api/0.6/way/375718173

Jun 04 '20 12:06 tordans

Maybe related? https://www.openstreetmap.org/user/karussell/diary/396620

May 06 '21 14:05 mmd-osm

Some recent examples all due to GoMap (v2.2.1):

https://www.openstreetmap.org/way/23547127 https://www.openstreetmap.org/way/227329906 https://www.openstreetmap.org/way/247137736

The planet was at some point with no duplicate nodes and so it would be good to avoid this, as GoMap seems to be the only editor that causes them. (There are currently hundreds of duplicate nodes due to a strange changeset but this will be likely reverted)

Jun 21 '21 17:06 karussell

I can't find any duplicate nodes in those 3 ways. How are you detecting them?

Jun 21 '21 18:06 bryceco

I added a check for duplicate nodes and purely by chance there were a bunch that I had in my cache from recently browsing the area around Niagara Falls. These were created by both JOSM and iD. Or maybe I misunderstand what you mean by duplicate? I'm testing for two nodes with identical lat/lon: Duplicate nodes: 8780052009, 8773945330 Duplicate nodes: 8773945329, 8780052008 Duplicate nodes: 8780052005, 8773945326 Duplicate nodes: 8829453913, 983951073 Duplicate nodes: 8773945324, 8780052003 Duplicate nodes: 8773945328, 8780052007 Duplicate nodes: 8773945327, 8780052006 Duplicate nodes: 8773945323, 8780052002 Duplicate nodes: 8773945325, 8780052004 Duplicate nodes: 3634818131, 8110145490

Jun 22 '21 05:06 bryceco

See the linked diary for a better description: https://www.openstreetmap.org/user/karussell/diary/396620

How are you detecting them?

This was originally detected with GraphHopper but you can also use JOSM. And "duplicate" in the sense that the same node ID occurs accidentally twice in the same way.

Jun 22 '21 06:06 karussell

Okay, that's a somewhat different bug than what this issue is about, but still good information. I'll add a check for that and see if I can reproduce it.

Jun 22 '21 07:06 bryceco

Ah, ok. Didn't mean to hijack the issue and thanks for looking into it :) !

Jun 22 '21 07:06 karussell