POI update created a duplicate node
What happened?
node 11238326637 is a ruin created using IHM about 2 months ago. It copied the tags and location of node 9723586619 and added an image1 tag.
This is not a case of parallel editing as the source node was last modified about a year ago.
What steps will reproduce the bug?
All we have is the OSM history of the two nodes.
It is the user's first update to OSM, so it is likely that he was using the app in a way we have not anticipated.
A possible flow, which I did not check is:
- Show the POI layer
- Select an OSM POI
- Click the "+" button (perhaps the user thought this is the way to add an image to the POI!?)
- Select the new private POI
- Press the upload button
- Select "More..."
- Respond "No" to the "Do you want to update: ...?" question
- Make some change to the POI
- Confirm the upload.
What I expect to happen
IHM should not enable users to duplicate POIs by mistake.
Platform
- [X] Israel Hiking Map app
- [X] Israel Hiking Map site in a browser
OS Name and Version
All
Browser Name and Version
All
Additional information
IHM checks if a new POI is within a certain distance from an existing POI. If the user chooses not to update the existing POI, a new POI is probably created even if it has the same coordinates as the existing POI.
Some of the options to avoid this:
- Prevent the upload of the coordinates are the same
- Always update the existing POI if the coordinated are the same
- When copying a POI to the private track, keep the original OSM id and use it somehow if the POI is uploaded to OSM
- Change the image on the "+" button of a public POI to a "copy" or "download" image
I assume there are other options that we can brainstorm about.
This issue is stale because it has been open 90 days with no activity. Remove stale label or comment or this will be closed in 7 days
I think we should better understand the extent if this issue.
- We need a way to reproduce this
- We need to know how many points like this exist
If we can't find a way to reproduce we can't be certain that we are solving the right bug. If this is a 1 to 1000 edits issue it might not worth the time to fix it in the code and we can consider running a script to fix OSM like other types of "bad" edits. Bottom line, this issue needs more data.
I have confirmed and simplified the steps to reproduction. https://www.openstreetmap.org/node/11682071570/history (now deleted) was created in a that way, as a duplicate of https://www.openstreetmap.org/node/6397867488, by editing the description.
I don't know how to identify the POIs that were duplicated. Moreover, how can we know if the duplication was by mistake or on purpose.
IMO, the critical step in the reproduction step is 'Respond "No" to the "Do you want to update: ...?" question' When a public POI was turned into a private POI and then uploaded, the application should always update the original POI.
I can't think of a good example of a point with the same/similar tags that exist in the exact same location - so I would consider every such point as a suspect of duplication. I'm sure we can find a way to find those points, I'm also pretty sure there won't be more than a handful.
In terms of risk, I prefer to touch as little as possible the POI add/update flows as those are hard to test and are complicated flows.
If this is something we can solve without touching this flow, it would be my preferred solution.
This issue is stale because it has been open 90 days with no activity. Remove stale label or comment or this will be closed in 7 days