special characters in tags

[Simon Poole]

See also 
https://wiki.openstreetmap.org/wiki/Any_tags_you_like#Syntactic_conventions_for_new_tags

Martins problem is that he is taking a name (actually a brand in this 
case), and just half converting it in to a stylized well formed key. He 
is lower casing it and removing spaces, but not replacing the "+".

Using award:Bett + Bike=yes would be the version using the actual name 
of the organisation.

Am 23.06.2022 um 22:20 schrieb Simon Poole:
> The API enforces
>
> - no duplicate keys
>
> - max key length (255 characters)
>
> everything else is convention which is traditionally enforced by the 
> editors and qa tools and that is exactly what is happening here, a 
> broken tagging scheme is meeting reality.
>
> Am 23.06.2022 um 22:12 schrieb Maarten Deen:
>> The API documentation should describe the allowed characters to use, 
>> and it does: https://wiki.openstreetmap.org/wiki/API_v0.6#Tags
>> "A tag is a Key-Value pair of Unicode strings of up to 255 full 
>> unicode characters (not bytes) each."
>>
>> No exemption of characters is made so that would imply that a "+" is 
>> allowed.
>> Having the JOSM validator flag them could be problematic in a way 
>> that people could take that as the rule and start removing all those 
>> characters just because JOSM says so.
>>
>> Regards,
>> Maarten
>>
>>> Op 23-06-2022 19:12 schreef Martin Koppenhoefer 
>>> <dieterdreist at gmail.com>:
>>>
>>>   Hi devs,
>>>
>>> in the German forum the question arose whether the “+” is an allowed 
>>> char in tags:
>>>
>>> https://forum.openstreetmap.org/viewtopic.php?pid=865766#p865766
>>>
>>> Maybe the validator is overzealous here, or is generally agreed that 
>>> some characters should not be used?
>>>
>>> Cheers Martin
>>>
>>>
>>>
>>> sent from a phone
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 495 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstreetmap.org/pipermail/josm-dev/attachments/20220623/8e6db343/attachment-0001.sig>