On 22/01/2015, Tod Fitch <[email protected]> wrote: > With respect objects that have multiple values for a key, the arguments seem > to come down to either: > > 1. key=value1;value2;. . . ,valueN > 2. key:value1=yes + key:value2=yes + . . . + key:valueN=yes
3. key<indexseparator><index>=value > As a programmer I can parse either set using any number of different > methods. > > I am not against using a ":' in the key string to create name spaces and for > grouping related keys. I think that is a very useful construct. > > But from a purely logical point of view, I'd say the second way misses the > concept of "key=value" and is using "key:value" with a noise suffix of > "=yes". Typically missing keys should be treated as having a value of either > "no" or "unknown". Unless you can show me where key:value1="is something > other than yes" then I may suspect you of putting values into the key field > of the data. You've given examples yourself where the value isn't "yes". The keys addr1:housenumber and name_1 obviously don't have "yes" as a value. Note also that nobody ever tagged "addr=42;Backer Street". It's not "key:value" but "key:subkey". > At present we have approached each case on an ad hoc basis. Sometimes using > a number suffix by itself (addr2), sometimes preceded by a underscore > (name_1) and sometimes by using a semicolon delimited list in the value > field. By setting a simple convention for key with an array of values I > think many of these cases could be handled in a simple, easy to remember > unified manner. Yes, I'd actually like to see this discussion happening. Seeing "addr1" suggested when "name_1" is in use irks me (the separator isn't the same). Another format that occasionally gets suggested is "key[index]=value". And it might be a good idea to clarify the interpretation with subkeys (is it "key_1:subkey" or "key:subkey_1" ?). _______________________________________________ Tagging mailing list [email protected] https://lists.openstreetmap.org/listinfo/tagging
