openstreetmap / iD

🆔 The easy-to-use OpenStreetMap editor in JavaScript.
https://www.openstreetmap.org/edit?editor=id
ISC License
3.37k stars 1.21k forks source link

Never merge URLs #9834

Open jidanni opened 1 year ago

jidanni commented 1 year ago

URL

https://www.openstreetmap.org/node/1677675243 Version 3.

How to reproduce the issue?

Let's say node 1 links to wikipedia article A, and node 2 links to wikipedia article B.

Drag them on top of each other.

That creates e.g., wikipedia=en:Louisiana Purchase Historic State Park;en:Fifth principal meridian

So far so good.

But there still is only one box with an arrow.

20230814T031428

And it links to the impossible page, https://en.wikipedia.org/wiki/Louisiana_Purchase_Historic_State_Park;en:Fifth_principal_meridian

Therefore there should be multiple boxes, one for each article.

Screenshot(s) or anything else?

No, I'm not saying it is good to have two articles with a ";" between them, but when this is the case, then they need separate boxes with arrows.

Which deployed environments do you see the issue in?

Released version at openstreetmap.org/edit

jidanni commented 1 year ago

https://github.com/openstreetmap/openstreetmap-website/issues/4166#issuecomment-1676936028 implies iD shouldn't merge URLs like that in the first place.

jguthrie100 commented 1 year ago

I'm willing to fix this. @tyrasd - what is the expected behaviour for merging two or more nodes/items with wikipedia links? (or with any sort of link presumeably)

DujaOSM commented 1 year ago

The default behavior of iD is to simply concatenate the original entries in a semicolon-separated list, which may or may not constitute a valid value. In many cases, it is not; at least, it is not machine-readable.

However, there's no "expected behavior" in general case, and the current solution works fine in order prevent data loss and let the user sort it out manually later. Alternatively, iD could refuse merging with the message "These objects cannot be merged since some of their tags have conflicting values" (we have this one already, I'm paraphrasing from memory), although I must say I hate this approach: it's much easier to clean up after merging than to trying to make iD happy all the time. I'd much prefer having better validations on commit than restricting users to do a lot of stuff.

In other words, I would rather that we do not do anything here...

jguthrie100 commented 1 year ago

It's definitely wise to keep all of the data, but the way the link is opened obviously needs to change.

There either needs to be 2/3/4... buttons, or each URL needs to open in a new window maybe..

DujaOSM commented 1 year ago

It does not make much sense to have multiple Wikipedia entries, Wikidata entries, websites and similar for the same map feature. Remember the "One feature, one OSM element" mantra.

That leaves us with the options 1) Do nothing and let the user merge URLs or whatever and live with the consequences, or 2) Prevent merge and display the infamous "These objects cannot be merged since some of their tags have conflicting values"

jguthrie100 commented 1 year ago

What about having a warning come up (like with crossed ways etc), and then giving the option to select which of the URLs should be used for the entity.