Should Emojis be used in tags? 😎

During some other QA-work I stumbled across numerous (>1500) guideposts that have a direction_*-tag with a value including emojis.

our tags should be in British English, this would exclude using emojis as values, from my understanding.


I mean, emojis are used in (informal) British English as far as I know, just as anywhere else.

In any case I remember there was discussion on the OSMUS slack about what to do about I♥️NY souvenir shops, given their most prominently signposted name has the heart symbol (although the official name may be something else).

I say: eschew emojis at every possible opportunity to do so. They are “not especially real language,” despite Unicode acceptance / overlap.

This is an especially “conservative” (linguistic) position, I happily agree. Emojis are “new enough that not all language users agree.” You might say I am one of those.

It’s a bit like saying “mobile phones are disruptive.” Yes, they are (and have been for a decade or three). There is such a real thing as a “mobile phone” and it could be said to be “disruptive” in certain contexts, especially over the last decade or three. Can you say “emojis are actually part of language?” Well, yes, and no. I’ve been alive long enough to say “hell, no.” (And “hell, yes,” as I’ve worked on the Unicode standard since the '90s). Younger people might disagree. I don’t want to stand in the way of progress, but you have to see things from my (older human, in his 50s) perspective, too: there is nothing wrong with me insisting on that.

1 Like

Almost all of them were created by user @vmicho (99.9%) and are in Switzerland, but some are in Germany and Slovakia too.

User vmicho really likes to add emojis to all kind of keys in OSM.
And they also have a very opinionated way of mapping things, bordering on making stuff up so it renders nicely.
In the Swiss IRC channel and in their changesets we’ve discussed it quite extensively and haven’t really reached a conclusion regarding the direction if I remember correctly.


🚶 hiking does definitely not belong in a direction_* -tag.

This is a direct “transliteration”, since quite often Swiss guideposts have only a pictogram of a hiker on them and point to the direction to hike on.

Here’s a stock photo of one:


We have those in England too That sign will get added with direction_north=Huggate, the pictograms will get changed to designation tags. If there was no named direction I wouldn’t add “direction_X” at all.


I think the guidepost tagging is incorrect. However if a shop has a character in their name, we should add that to the name tag.


Guilty as charged: Way: ‪I ♥ Hair‬ (‪243532655‬) | OpenStreetMap

1 Like

Would you do the same now? or would you use “I love Hair” instead?

Well, at least according to the Yelp page, they were promoted as “I Love Hair” . However, it seems that the business has been closed down at that particular location.

1 Like

For completeness, there was also a rejected proposal back in 2020 to add emoji “translations” of non-emoji names. My understanding is that the proposed name:Zyse key was intended for a slightly different purpose, to be tagged on the place that an emoji inherently represents.

This rejection doesn’t necessarily prevent us from using emoji in name when it’s signposted. However, we should be careful about distinguishing between dingbats, emoji alternatives to those dingbats, and logos that happen to look like those emoji.

I ❤︎ NY and I ❤️ NY are merely stylized forms of the actual name of a shop. We may know that this logo is associated with the slogan “I Love New York”, but a text-to-speech engine will say “aye black heart suit en why”, “aye red heart en why”, “I corazón rojo ene y griega”, etc. Or it might skip over it entirely, confusing the user. Some major renderers are also unable to render emoji:

Every now and then, someone has a similar idea of using  or :apple: or :hot_pepper: for store locations because the chain signposts its logo without a wordmark or more prominently than the wordmark, but it’s pretty well known that these chains exist in plain vanilla Latin text as well:

Setting aside OSM software, you bet no government form or database would be able to handle these whimsical characters either, so it becomes a question of whether these are even real names. It couldn’t hurt to include these forms in alt_name or short_name in case a user enters them as a shortcut, but we don’t include gratuitous abbreviations in name, as a general rule.


Totally agree, @jimkats. Also, another argument against them is that emoticons are open to much broader interpretations by different cultures than plain text English is.

1 Like

“black heart suit” shows that the person has used the wrong emoji in the name. :wink: The name:pronunciation tag can be used to add the other tag. (Though alt_name is probably accurate too).

Ok. And? :wink: Many government agencies can’t handle äccénts either.

Regardless, we shouldn’t (mis)tag for the text-to-speech renderer.

I did discuss it on IRC at the time, and at least one person there said that the emoji was just “trade dress” and the “real” (unwritten) name should be used instead.

To be honest, I’d probably still go with the sign, if there’s no other signage showing the “real” name.


I know a thing or two about this. My family name should be spelled with diacritics, but that authentic spelling is not legally recognized. If I open a map shop named “Nguyễn’s Maps”, I’d want you to tag it with the diacritics even if the authorities are forbidden from typing these diacritics. My point is only that, if there’s any question as to whether the sign is showing a real name or a logotype, publications and databases that must stick to plain text can help us determine the plain-text contents of name=*.

Ouch, it stings to be accused of tagging for the renderer, but this is not what I’m suggesting. This principle exists to prevent people from optimizing for one renderer or one class of data consumer at the expense of another, when we should be aiming to document groundtruth accurately. This is a matter of fairness in an open project that encourages developers to create new and exciting uses for OSM data.

I hope it’s clear that I consider the emoji in these examples to be hacky abbreviations just to look cute in a particular renderer, at the expense of other data consumers, including assistive technology. The name “black heart suit” comes straight out of the Unicode Standard for the character :heart:, which renders as a red emoji on some systems. In a fit of irony, tagging an Apple Store as name= (U+F8FF, a private use character that resembles the Apple logo) would all but erase the store from the map as seen by Android, Linux, and Windows users, as that symbol is nonstandard and trademarked.

If a shop clearly wants its name to be an emoji – a specific emoji character – then by all means tag it as such. And if a shop pulls a Prince, insisting on being referred to by an unencoded pictogram, then the joke’s on us.

1 Like

Taking I♥️NY → i personally think this is a log for “I love New York” as a whole. Apple has a single apple as log but its name is still Apple.
Same goes for @Minh_Nguyen examples - its still Chilis as name, the chili itself is just a logo and should not be tagged.

For the sign-posts i would agree with what SomeoneElse said Should Emojis be used in tags? 😎 - #11 by SomeoneElse there.

Personally, I map guideposts that have a symbol in name, with the appropriate Unicode symbol. That’s why the symbols are there.
Take e.g. this guidepost. The meaning of this is “This guidepost is in the town of Nýrsko near a bus stop or a bus station”. So what is the correct name?
I believe in the On the Ground principle. I see a bus in the name, I put :bus: in the name. If there is a way to find a more official name without the emoji, I would use this. But if such a rigid organization as the Czech tourist club can use Unicode on their guideposts, I believe we can handle it in OSM.
I’m against putting emojis in places, where an official name is different and can be found OtG, like in some of the examples above.

Please note, this is more to illustrate the principle. In this case, the “official” name is Nýrsko (BUS), but we don’t have the permission to copy from this database. Edit: Also, “Bus” is not a Czech word, it is an abbreviation of “Autobus”, but in this case maybe “Autobusová stanice” (bus station) - who knows what I should put there?


And if you see a train, like in your example, you would put a locomotive, right? Meaning that it’s a steam train, not any other kind. Because in your example, it’s clearly a locomotive. Or not? Also, what do you use for that orange zig-zag line? I’m not sure; I don’t have any specific aversion to emoticons here, but they are too open to interpretation both ways: when you transfer them to the OSM map, and back, when our customers view them. It turns into a game with rebuses :wink:


Yes, I would use a locomotive. Probably the steam one, if there is one on the picture, yes. :steam_locomotive: Because that is the closest to what it says on the ground. One example.

That is not in the name, that is a symbol of the route. That is record-able using the wiki:symbol tag.

What do you mean “open to interpretation”? It is as close to the signposted name as possible. The symbol itself might be open to interpretation, but I would rather the data user to do the interpretation than the mapper.
If you mean that there could be several Unicode symbols for the symbol on the sign, I agree - and it can potentially cause problems to data consumers. But in my opinion, it is still better, than mappers guessing what the symbol means and writing their interpretation to the name tag.

1 Like

Yes, that’s what I mean indeed.

1 Like

Are you sure it’s part of the name? Naïvely, I would interpret this pictogram as destination:symbol=bus_station, based on similar standard signage on guide signs along motorways, and tag the destination as “Nýrsko” as you suggest.

Interesting that you should mention the guideline encouraging us to expand abbreviations in tags. :wink: