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.
5 Likes
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.
2 Likes
đ¶ hikingdoes definitely not belong in adirection_*-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: https://media.istockphoto.com/photos/yellow-sign-for-swiss-hiking-trails-on-a-metal-mast-points-to-the-picture-id1180959355?k=6&m=1180959355&s=612x612&w=0&h=u6few0j8hkKqEA1vMKbhQ8LGj7BjcCJWuFZqzXtHnh4=
4 Likes
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.
4 Likes
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.
3 Likes
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.
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 
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:
https://www.flickr.com/photos/jeepersmedia/14252903113/
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.
9 Likes
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. 
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.
3 Likes
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.
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 
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?
2 Likes
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
2 Likes
Yes, I would use a locomotive. Probably the steam one, if there is one on the picture, yes. 
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.
2 Likes