[Tagging] Feature Proposal - RFC - information=qr_code

[Marc_marc]

Le 21.06.22 à 23:20, Anne-Karoline Distel a écrit :
> The purpose of the sticker is tourism=information, though, so I don't
> see why it should be mapped as a man_made thing.

because when it's a sign with text, we don't map it as information=latin
to describe a support with latin alphabet on it., nor we map it as 
information=arabic to describe that the encoding is the arabic alphabet
we map it as information=board : the content and not the encoding

if a support have a bitmap printed on it, again we don't map
it as information=bitmap, we map the content for ex informaiton=map

if a support have just a url printed with an latin alphabet,
I hope you don't map it as information=latin

if you map an touristic office, I hope you don't map
with depending of the "encoding" used for the paper material
or language used
I hope you map it as information=office

This is why I don't see any logic in a qr code being filled with an 
information=* value and not according to the content it provides once 
decoded

Le 22.06.22 à 11:18, stevea a écrit :
 > tourism=information + information=qr_code
 > qr_code=map

it is unfortunately the perfect nonsense that I feared:
depending on whether the map is encoded in a qr code or in a bitmap,
we end up with 2 different values for information=*:
one that describes the content and the other the encoding.

if the content is identical, the information value must be the same.
if someone wants to fill in the encoding, you need a key that only talks 
about encoding