During some other QA-work I stumbled across numerous (>1500) guideposts that have a direction_*-tag with a value including emojis. Almost all of them were created by user @vmicho (99.9%) and are in Switzerland, but some are in Germany and Slovakia too.
Some of the emojis used: 𒀭 ↻ 🅢
Definitely the weirdest Overpass-Query I have ever created so far (regex works with emojis too!): https://overpass-turbo.eu/s/1ybQ
Not saying this is particularly good or bad, but I’m curious to hear your opinions about emojis in tags.
One reason I would refrain from using emojis, is because not every drawing on the sings exists as an emoji.
Also, the emojis aren’t presented the same on all devices, which would cause confusion at the end-user, depending on the software and device.
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.
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.
We have those in England too https://map.atownsend.org.uk/tmp/153990.jpg. 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.
Would you do the same now? or would you use “I love Hair” instead?
UPDATE:
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.
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 or 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.
“black heart suit” shows that the person has used the wrong emoji in the name. The name:pronunciation tag can be used to add the other tag. (Though alt_name is probably accurate too).
Ok. And? 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 , 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.
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.
𒀭 
↻ 🅢 
or 
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:
The 
, which renders as a red emoji on some systems. In a fit of irony, tagging an Apple Store as 