Site icon indicating copy to clipboard operation
Site copied to clipboard

POI update created a duplicate node

Open zstadler opened this issue 2 years ago • 4 comments

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.

zstadler avatar Dec 01 '23 14:12 zstadler

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

github-actions[bot] avatar Mar 01 '24 00:03 github-actions[bot]

I think we should better understand the extent if this issue.

  1. We need a way to reproduce this
  2. 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.

HarelM avatar Mar 01 '24 09:03 HarelM

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.

zstadler avatar Mar 01 '24 17:03 zstadler

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.

HarelM avatar Mar 01 '24 18:03 HarelM

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

github-actions[bot] avatar May 31 '24 00:05 github-actions[bot]