NOTICE: is no longer in use from 1st March 2024. Please use the OpenStreetMap Community Forum

How come that the name cannot be set correctly if there is a wikidata link? I find numerous examples with names that cannot be set properly in the map.

Almost all have an english language wikidata whereas the correct name is in in some other language. In such cases the english name / wikidata entry always take preference.

My examples are for place names in Greenland where the are two officially approved names, an inuit one and a danish. Nevertheless the unofficial english which occur in nwikidata take preference.

Look here:

  • Prince Christian Sound: Real name is Ikerasassuaq
  • Christian IV Island: Real name is Sammisoq

asked 10 Aug '21, 19:28

andershl's gravatar image

accept rate: 50%

edited 10 Aug '21, 19:28

May be irrelevant: Note that the Wikidata item "name" is a label only, so it's not entirely correct to rely on that as the common name for name= in iD. The names should be properly recorded in properties P2561 (most well-known), P1448 (official), etc.

(25 Aug '21, 05:32) Kovoschiz

I guess that P2561 and P1448 relate to wikidata. Is that to say I am right in assuming that wrong settings in wikidata will take precedence over corrections in OSM? And if so, how can it be corrected? I have tried in vain and unsuccessfully to edit in wikidata...

(25 Aug '21, 08:03) andershl

The standard layer in OSM does not refer to wikidata, so corrections to the OSM database will show up there. As mentioned in another comment, updates to low zoom levels may take some time (e.g. a month). But that is nothing to do with wikidata.

(25 Aug '21, 08:30) alan_gr

The OSM database containing all the geographical information we (the OSM contributors) collect is completely independent from Wikidata.

Some map creators choose to take information from Wikidata to label their maps. The standard layer on does not.

The iD editor locks editing the name if a Wikidata item is present. I don't know the exact rules when it does but in any case there is no linking or copying from Wikidata names to OSM names. And even with the lock in place you can still edit the OSM name as described in this thread and in the tooltip in iD itself.

(26 Aug '21, 09:18) TZorn

Thanks. I realize that is has nothing to do with wikidata, but is simply a matter of (a lot of) patience. So far none of the geographical features that I have corrected for the last 3-4 weeks changed in default OSM.

As to ID: Oh, I found that I can just skip the top part and go to the tags. There I can add, change, and delete anything directly.

Shall just leave wikidata in future chagesets.

Particularly about Greenland: Lots of places have 2-3 inuit names. Until one of them has been selected, the official one will most often be in danish. After assignment the danish will be old. They have a database for it. So far I have seen NO places with english names (strait/bay/glacier). Moreover no iniut names have a danish or english type after their proper name. There are no "XXX Island" or "XXX Ø". The name will be "XXX". old name or name:da may be "YYY" (in danish)whereas name:en may be "XXX Island" all right..

(26 Aug '21, 10:04) andershl

You should be able to edit the name if you scroll down to the Tags area on the left hand side of the screen, which does not enforce the constraint.

Alternatively if wikidata tags are getting in the way of adding correct info to OSM then I would have no compunction in removing them, or renaming them so that the constraint no longer applies. In practice, I don't because I use the work-around above.

In principle tying a name to a wikidata tag aims to promote stability & discourage vandalism. Perhaps more importantly it helps newcomers avoid accidentally renaming significant features. One would hope that people adding wikidata tags do take care to check that the name tag is culturally appropriate when they do so.

permanent link

answered 10 Aug '21, 21:26

SK53's gravatar image

SK53 ♦
accept rate: 22%


Scrolling down in iD to the tags area is the way to do it. Removing (correct) wikidata link is vandalism in my view.

Just to clarify. This name enforcement is only done in the iD editor. It is not part of the underlying data model.

(11 Aug '21, 10:36) TZorn

Any feature which gets in the way of users correcting data is problematic. Wikidata tags aren't great because there are often 2 levels of indirection to check that they are actually correct. If a wikidata tag is assigned to an incorrectly named object, removing the tag if one does not have the time to investigate is hardly vandalism.

(11 Aug '21, 11:52) SK53 ♦

The iD editor is getting in the way of users correcting data, not the wikidata tag. I'm rarely seeing wrong or ambigues wikidata tags. I'd assume most of them are correctly applied. Just removing them because one editor decided to value them more than the name tag is vandalism in my opinion. There is a workaround you described yourself, so why sanction the deletion of the tags?

(11 Aug '21, 12:48) TZorn

Just to throw another point of view, I'm definitely seeing ambiguous wikidata entries. To take a specific example over at wikidata refers to both and in OSM. OSM just has more detail than wikidata here.

In that example it looks like someone has set "council_name" for what should actually be the "name", perhaps because of this very issue.

(11 Aug '21, 13:05) SomeoneElse ♦

@SomeoneElse this is precisely the sort of issue I come across with Wikidata, where wikidata conflates several objects which have rather different semantic meaning on OSM (typically village, political division, administrative division, etc). Many wikidata tags were created from Wikipedia and therefore may reflect notability & merging of articles which reflect wikipedias editorial policies.

(14 Aug '21, 09:22) SK53 ♦

The comments are interesting, but the challenge is still there. For the two example objects no matter what I have tried the english versions still take precedence.

Can anyone make the correct names take precedence and tell how it was done?

And I am fully aware that precendence in displayed map may be dependent upon your nls setting. I am danish, so as for any other object I expect to see the contents of name or name:da.

(17 Aug '21, 09:29) andershl

So you have actually been able to update the names in the database as described above. You are now wondering why you don't see the changes in the standard map layer on

The names of these large objects are only displayed on lower zoom levels and map tiles of lower zoom levels are not updated on demand but only infrequently as it takes some time.

So you have to be a bit patient.

(17 Aug '21, 10:04) TZorn

As to your last point. The standard map layer on uses static names, i.e. it always takes the value from the name key. Other maps may chose to use a different name tags or display names based on the language of the user.

(17 Aug '21, 10:08) TZorn

Yes, I could easily change the name tag with ID, but apart from that nothing has happened so far.

So I just need to have a LOT of patience to see it take effect = I should have waited some more weeks. Let's see...

(17 Aug '21, 15:47) andershl

"A bit patient". What does that incur? Weeks, months or or??

(24 Aug '21, 18:46) andershl

For zoom 0-12 it gets updated about once a month to change on the standard layer at, zoom 13+ should be faster, e.g theroretically in seconds (depending on the caching layers plus rendering queue length).

(24 Aug '21, 19:13) Spiekerooger

I note that some of the cycle maps are faster in reacting (or as I have seen it so far: They DO at least react)....

(26 Aug '21, 07:39) andershl

If you are looking at the maps shown on the main website, CyclOSM updates very frequently. Humanitarian and transit-focused OPNVKarte too.

(26 Aug '21, 10:03) Kovoschiz
showing 5 of 13 show 8 more comments

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here



Answers and Comments

Markdown Basics

  • *italic* or _italic_
  • **bold** or __bold__
  • link:[text]( "title")
  • image?![alt text](/path/img.jpg "title")
  • numbered list: 1. Foo 2. Bar
  • to add a line break simply add two spaces to where you would like the new line to be.
  • basic HTML tags are also supported

Question tags:


question asked: 10 Aug '21, 19:28

question was seen: 1,066 times

last updated: 26 Aug '21, 10:04

NOTICE: is no longer in use from 1st March 2024. Please use the OpenStreetMap Community Forum