Add 🏳️🌈=primary tag to everything that's lgbtq=primary.
what is the purpose of your change? What should the "lgbtq = primary" mean.
Hey rorym 🏳️🌈,
can you explain what the diffence between lgbtq=primary and 🏳️🌈=primary is?
I have put some documentation for lgbtq tag here ( https://wiki.openstreetmap.org/wiki/Key:lgbtq ).
The 🏳️🌈=primary tag is for fun, since it can be more inclusive than "LGBTQ". Right now there is no difference, except that the OSM Wiki doesn't let you document a key like "🏳️🌈".
I think that emoji are more fun, but they can also break existing programs that are expecting plain text.
Even Unicode-aware programs can fail to handle emoji correctly, since they're combining characters outside the Basic Multilingual Plane. JOSM on Linux shows the tag as a black-and-white scribble, while viewing a dump of the changeset in a text editor shows the scribble plus a black-and-white flag.
For that matter, programs that handle emoji correctly can have problems. I came across this changeset while trying to figure out why a bunch of stuff had been tagged as "[flag of the Netherlands]=primary". I'm now reasonably sure it's supposed to be "[rainbow flag]=primary", but when the flag was shrunk for display, the color bands got merged to produce red-white-blue.
I can't see, why you should add redundant data. From computer science perspective it brings lots of issues along (especially consistency). What, if lgbtq=primary doesn't apply any more, a mapper removes that, but leaves [rainbow flag]=primary? Although for almost all of us OSM is a sparetime project / hobby, I think it is far from meaningless. Therefore we should handle such problems with care. There are enough inconsistencies in the database anywhere. Some other mappers seem to think this way too: https://wiki.openstreetmap.org/wiki/One_feature,_one_OSM_element#Tag_data
In a nutshell: I strongly oppose this tagging.
With kind regards
I'm not aware of any software that this has broken, if there is, please let me know. That would be a serious matter.
If your software expects ASCII text, you're not going to be able to work with lots of OSM data. 🙂 Lots of text looks like "black squiggles" to me (yes including this in my JOSM), that's not really a bug, merely a demonstration of how hard it is to display text. JOSM is well able to work with this tags (I added it with JOSM).
OSM is full of "duplicate data", such as "phone" and "contact:phone", and many ways to store the same data (footpaths!). If you're worried about that problem, this should not be your biggest worry.
You're right. These are other problems. But just because bigger problems do exist, smaller problems still should be solved if this can be done easily. In OSM the mass of data is that vast anyway that we can't fix everything (my assumption).
Sorry to be "emojiist" here, but I can think of plenty of things that won't work with that as a "character" (or indeed _any_ emoji as a character). Many things that prepare data in XML format for Garmin devices, for a start. If you're entering data that many people can't understand, can't read or can't enter then you're excluding people from OSM data in a way that I'm sure you wouldn't support.
Oh that would be a shame. I've never generated Garmin files. What happens when you do it with characters/tags like that? I'm surprised it hasn't caused a problem yet considering how big & global OSM is already.
Garmin's XML processing is notoriously flaky. What tends to happen is it just says that the file is invalid.
It's a bigger issue than Garmin though - I've no idea what the changeset source tag on this change is supposed to mean (looking at the data I can see that you've just done a mechanical edit copying the meaning of one tag into another). Please don't do this. Adding tags "just for fun" adds no value to OSM and just causes confusion when people using OSM for the first time (who may have no idea what an emoji is) come across them.
please revert this change, because it is problematic for many tools.
there is a good reason why you can find it here:
I think OSM is a database, no funny looking text book. Your tag is the only emoji-key in the whole database!
Many thanks, Alex
Do any more people need to jump in before you revert this?
I have seen many issues last years with problem-keys or problem-values. E.g. the char 0x7F (a char that is meant to be ignored, to delete what was there, needed in historic times) is interpreted different in OSM tools: some ignore it (as intended), some handle it as an invisinle char without size, some as a space. It caused names including it to be not searchable, even if it was the first or last symbol of string.
keys are more problematic tha values, as no all DB-server-engines out there can handle it as a valid column-identifier.
Firefox under Ubuntu) can show the symbol fine, but Google-Chrome under Windows-7 does only show rectangles.
try 2 OSM links (examples),
I did some analysis of current tags, there are almost 100 million non Basic Multilingual Plane characters already in OSM tags.
I'm curious what software will barf on this, and not other non-ASCII characters. What sort of errors do we see? Can we fix that software?
One complaint is about duplication. Perhaps switching from the lgbtq tag to 🏳️🌈 might help and be a better key? 😉
> I'm curious what software will barf on this,
I've already given an example of this.
> Can we fix that software?
No. See above. The only "fix" is to remove the offending data. That's what I've done when I'm extracting notes and fixmes from OSM for display on Garmin devices.
On a more general note, one of the "golden rules" of OSM is that no matter how much you think you are correct, if "everyone" is telling you you're wrong then you probably are.
Hi rorym, please separate between key and value (key=value). For keys I cannot find any special symbol-sign. Only for some values. And keys are more problematic, see also taginfo for this.
On the subject of software not displaying things properly, I'm currently 0 for 9 on web browsers showing this changeset discussion as intended (Seamonkey on Gentoo Linux comes close, but the flag more closely resembles that of the Netherlands than the intended rainbow flag). Email clients are currently 0 for 4 at displaying comment notifications, with Gmail on Firefox/MacOS coming closest ([white flag] [rainbow between two clouds] = primary). That's a lot of software we'd need to fix before this could even be considered for use.
do you plan to just wait for this to be forgotten? There are a lot of things now presented as broken and there hasn't been any reaction on that yet.
The Overpass Turbo Query Wizard does not handle emoji. Reverting might be hard. We would really like you to revert this edit - it is not part of the OSM community culture to revert other contributors intentional edits.
I can handle the revert if necessary. When doing reverts on behalf of the DWG I'd normally wait a week or so before doing reverts; this changeset has had that time and more and the consensus is pretty clear that it needs to be reverted, unfortunately.
Looks like this got reverted in https://www.openstreetmap.org/changeset/65667895 .
OpenStreetMap is a map of the world, created by people like you and free to use under an open license.
Hosting is supported by UCL, Bytemark Hosting, and other partners.