<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><br><br><div id="AppleMailSignature" dir="ltr">sent from a phone</div><div dir="ltr"><br>On 8. Jan 2019, at 14:35, Simon Poole <<a href="mailto:simon@poole.ch">simon@poole.ch</a>> wrote:<br><br></div><blockquote type="cite"><div dir="ltr">I'm not convinced that we really want to model such a level of
detail in the first place, but using a small set of common keys
for facilities with similar purpose has obvious advantages over a
multitude of special purpose keys that are difficult to discover.</div></blockquote><br><div><br></div><div>I do not believe either that we would want to map generally at such level of detail, but I can imagine people being interested in a particular detail, e.g. <a href="https://taginfo.openstreetmap.org/keys/drink%3Aclub-mate">https://taginfo.openstreetmap.org/keys/drink%3Aclub-mate</a> (or e.g. postage stamps, or public transport tickets)</div><div>and for these few exceptions (things with sufficient supporters and interest to “take off”) I am not sure a generic tag with multiple values is better than a specific property. A drink:club-mate=yes tag is less inviting to tag the availability of milk, cherry lemonade or beer than a generic tag available_drinks=club-mate, which will most likely lead to long lists soon.</div><div><br></div><div>With current tools there is no tag completion for the individual values in lists, while the alternative already works.</div><div><br></div><div>It is also simpler for data consumers, and as long as you want to distinguish only yes/no you could get along with just one bit for storage.</div><div><br></div><div><br></div><div>Cheers, Martin </div></body></html>