Talk:Proposed features/Multivalued Keys

From OpenStreetMap Wiki
Jump to: navigation, search


I don't recognise some of your categories: Subscript Syntax / Suffix Syntax / Hierarchy Syntax / Delimiter Syntax

My understanding is:

  • key[N] = valueN ~ not Subscript Syntax (?), rather Index syntax
  • key_N = valueN ~ not Suffix Syntax (?), rather Subscript syntax
  • key:N = valueN ~ Hierarchy Syntax (?), also called Namespace syntax, see Namespace and Category:Namespaces or suffix
  • key = value1;value2 ~ Delimiter Syntax, also called Semicolon syntax, see Semi-colon value separator

Good luck with the discussion. Althio (talk) 15:55, 27 January 2016 (UTC)

Pros/cons table

I've drafted this here on the talk page, but feel free to include when it has content.

All of the solutions have positive and negative sides to the them, so this table should be just a descriptive list for each variant. Whether each user considers them to be huge or unimportant, is to some extent a matter of personal judgement, and to some extent irrelevant. None of them are without any downsides, I tried to include all arguments I remember/I've seen especially on the tagging list. This could be sketched in another way too, but I'll leave that for later.

Subscript syntax Suffix syntax Hierarchy syntax Delimiter syntax Notes
Assuming all existing and future software is changed, mapper has to choose one value over others no * no * no * no * "no" if there's [1] or _1 or :1 variant always when [2] or _2 or :2 exists
Assuming existing software isn't changed, mapper has to choose one value over others yes yes yes partial Partial, because e.g. shop=supermarket;bakery isn't wrong, just not commonly rendered. "Yes" for others, because unaware software only sees the non-indexed key/tag.
Consumer can choose one value over others, regardless of "location" yes yes yes yes
Consumer can "show" all values (e.g. icons), assuming changes in software yes yes yes yes example for delimiter syntax at a tagging message
Known to have all data by indexing just the "key" no no no yes
Plain text search of "key" finds the element no no no yes Searching free form texts for most/all purposes employs some sort of wildcards for good UX.
Editing one tag is sufficient when adding/removing values no no no yes Indices of other keys must be validated each time?
Editing one tag is sufficient when changing order of values when manually editing tags? no no no yes for "no": up to n-1 other keys need to be changed
Key indexing can be broken when manually editing tags yes yes yes no
Manual tag editing separates the values yes yes yes partial A possible issue only with longer lists, or values with delimiters?
Tag editing UI can show values separately necessarily necessarily necessarily yes
All current and future "dumb" software retains the order? yes yes yes yes Currently, in index-based tags all but the first tag can be invisible/nonexisting.
Every value can be of maximum length (255) yes yes yes no For delimiter syntax, even with 8 values they can have 31 characters each.
Key "part" ordering obvious to all, every time (name:fi:1 or name:1:fi) random set random N/A
Symbols (delimiter) must be escaped or not used in the value no no no yes Hasn't been an issue to date?
Symbols must be escaped or not used in the key unlikely potential for misinterpretation * potential for misinterpretation * no Example: There could be in use population_2014=242, or hypothetical(?) building:usage:before:2012=office (i.e. not the 2012th value, but pertaining to e.g. a date)
Easy interoperability between single and multiple valued keys partial partial partial partial Depends on other choices? E.g. (key=x + key[2]=y) vs. (key[1]=x) (only), and on end user use case
Incompatible* with some current widely used tagging syntax e.g. turn:lanes=* yes yes e.g. seamark=* tagging? examples mentioned on tagging list. *) in the sense that vast changes required, if altered

IMO there's no point to decide; each modelling context can choose the best variant for that use. Even if toolkits exist for processing/pipelining the updates to some (backend) systems, ad hoc users/use cases have to decipher the data, too. Alv (talk) 19:53, 27 January 2016 (UTC)

Thanks for the excellent work so far. I hope to see some resolution of this thorny issue as a result. I think rendering semicolon separated values will be more difficult than individual keys, whether subscripted or suffixed, for us mkgmap users because of the way such objects are parsed during compilation. I realize this should not be a part of the present discussion but I did want to point it out. Another minor point: The table would be more readily understandable if it used syntax like "Symbols must be escaped or not used" rather than "No symbols need to be escaped or not used". The double-negative at the end makes it confusing, at least to me. AlaskaDave (talk) 02:32, 28 January 2016 (UTC)

Double negatives on some lines were there because I didn't initially want to use "yes" on red background or vice versa, but then I already added some lines that way, so I've changed that now. Alv (talk) 17:03, 28 January 2016 (UTC)


I'd like to see some examples. Mine? In UK landuse=farmland is a primary use of some land. It is also 'water catchment' for the collection of drinking water ... for example (and yes I'd like to see landuse=water_catchment as a new value ... some areas in Australia are dedicated to water catchment) {Oh ... and thanks for adding this page} Warin61 (talk) 06:09, 28 January 2016 (UTC)