On 15/09/2014, Paul Norman <penor...@mac.com> wrote: > On 9/15/2014 9:45 AM, moltonel 3x Combo wrote: >> Supporting multiple values natively in the osm data model would >> provide a clean and efficient solution, but updating all the tools to >> support it would be a huge undertaking. > It's not going to get supported by most data consumers. This isn't a > question of upgrading tools, this is a question of tools relying on a > key=>value store, a single column, or some other external dependency > which doesn't allow multiple tag values. I believe when the API did > support multiple values for one tag almost no data consumers supported it.
Implementation doesn't need to break the "key=>val with keys being unique" restriction of common stores (like PG's hstore). The obvious way is to store a composite value in val. This is in essense exactly what the current semicolon-separated-value scheme does, but if it was done at API level, it would avoid the inconsistent parsing issues. msgpack is a very lean and fast format that could be used. Compared to the current csv approach, the overhead of storing a typical array of strings is just 2 bytes (and splitting would be faster). It can be introduced in a backward-compatible maner : The old API version can convert arrays to the traditional csv-string format when exporting, and convert them back to a proper array when importing (with the added benefit of syntax checking). The new API skips the conversion, dealing only in native strings and arrays. Any consumer that can't handle arrays can request the stringified version instead. All conversions are done on the fly; the integrity of the array/string data in the db is kept. _______________________________________________ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
