Deprecate OSM reliance on name-tags

[pangoSE]

Hi.
I think we should have a roadmap for completely retire the use of name-tags in OSM for all objects that have a wikidata-tag.
The rationale is this:

• names are hard
• the osm names tags are a mess with poor or no references. Just look at the recent mailing list threads about name tags.
• the osm names are not possible to add a source individually which leads to subjective bad data.
• there is no such thing as an international name. Names are part of a language whih is part of a culture. They are not GIS objects and the osm datamodel does not handle this complexity well at all.
• having names in two places results in double workload
• wikidata has unique objects and osm really dont so its not hard to choose where to put the names.

JOSM should IMO
1) fetch all names from wikidata when downloading an area feom osm
2) enable searching and editing of names in wikidata directly from JOSM.
2.1)It should have a default filter in the search box that says "search wikidata names and fall back to name-tags only when nowikidata-tag is present"
3) encourage the user to treat the osm name yags for every object in osm with a wikidata tag as deprecated. E.g. warn when it is edited and suggest editing the wikidata one instead and provide a source foe the name preferably.
4) make it easy to add an image from a gpx file as a source to a namechange in wikidata. This requires uploading the image somewhere and I suggest wikimedia commons. JOSM should handle all this in the background seamlessly.

Maybe we need a new property in wikidata called OpenStreetMap-name. WDYT?

The result of this is:

• No more name disputes without source photos available for everyone.
• No more name vandalism in osm. We export the name handling to wikidata which has a much better system for handling vandalism.
• more focus on mapping, less on naming as most objects already have names which are fine in WD.
• better references for names over time, less subjectivity

[pangoSE]

This i mine. Forgot to login it seems.

[mkoniecz]

I think we should have a roadmap for completely retire the use of name-tags in OSM for all objects that have a wikidata-tag.

This is out of scope of JOSM.

Feel free to discuss it on tagging mailing list or in other place to discuss tagging. I want to note that several claims that you made are wrong, misleading or make no sense. Personally I consider it as a bad idea for multiple reasons, but I will not say more as it is out of scope to deprecate primary, widely used and extremely important tags via discussion on JOSM bug tracker.

I am not a JOSM developer, but I closed it as a clearly invalid. Sorry if I should not do this.

[pangoSE]

See my post today on the talk mailing list for a discussion of the wider ecosystem roadmap.

[mkoniecz]

That is a correct place to discuss it, I replied there.

[pangoSE]

Replying to mkoniecz:

I think we should have a roadmap for completely retire the use of name-tags in OSM for all objects that have a wikidata-tag.

This is out of scope of JOSM.

Really? JOSM is the most used editor. If the devs here are against this change it will probably be hard for the community to deprecate the names in the rest of the ecosystem.

Feel free to discuss it on tagging mailing list or in other place to discuss tagging. I want to note that several claims that you made are wrong, misleading or make no sense.

You are very welcome to elaborate what you mean. I might have misunderstood something. We might learn from each other 😀

Personally I consider it as a bad idea for multiple reasons, but I will not say more as it is out of scope to deprecate primary, widely used and extremely important tags via discussion on JOSM bug tracker.

I don't agree with names being an important tag anymore (for objects with a wikidata tag they are redundant and often not high quality. A wise data consumer discards the osm names whenever better names are available). I posted in talk also today.

I am not a JOSM developer, but I closed it as a clearly invalid. Sorry if I should not do this.

I think it will get more attention if we keep it open a little longer. The JOSM devs might have important technical input to the discussion. But its probably best to keep the discussion on the wider implications on the talk list and keep it JOSM relevant here.

From my point of view a few questions arise:
Is it doable?
Will it ruin the editing experience when editing objects in JOSM?
JOSM is today fully capable of getting information from Wikidata. What I'm proposing is implementing also updating data in wikidata.

It affects the upload and download dialogs most. A new UI for editing WD labels will of course be needed. IMO it should really stress the need for references. Is it a street? Suggest adding a gps referenced photo of the sign. We should strive to have a photo or url plus date for every change of name in WD.

[mkoniecz]

Really?

Yes, really. Deprecating one of fundamental, widely used, de facto, uncontroversial tags is out of scope for JOSM.

[pangoSE]

Replying to mkoniecz:

Really?

Yes, really. Deprecating one of fundamental, widely used, de facto, uncontroversial tags is out of scope for JOSM.

I'm not suggesting that the JOSM devs go solo and deprecate the tag. This is a long process that will need time to be implemented across the ecosystem affecting many tools.

Also it is unclear to me where a decision about this should be made (osm is quite horizontally organized it seems), so I post in here also to hear what the devs think about this.

[Klumbumbus]

In 16861/josm:

see #11541, see #19655 - Add wikidata textbox below every wikipedia textbox in all internal presets and warn if a wikipedia value looks like a wikidata value

[Klumbumbus]

I too think this should be discussed before on a wider base if osm wants to go this way.

(r16861 is neither a pro nor a con to this ticket, just the addition of wikidata to the presets.)

[anonymous]

clear case of something that JOSM will not do unilaterally

See also #22530 #22533

[anonymous]

Also, there is no evidence whatsoever that it has some actual wider support.