[OSM-talk] keys with multiple values

Simon Poole simon at poole.ch
Wed Sep 17 12:34:19 UTC 2014


I'm not quite sure what the issue with formalizing the ";" convention is.

As Jochen Topf has wrote before, we do need to at least define the
semantics (set, ordered list etc), regardless of implementation.

Once we agree on that, agreeing on if we should simply define an escape
( ;; would be good enough IMHO) or do something new should be really easy.

Simon


Am 17.09.2014 14:06, schrieb moltonel 3x Combo:
> On 15/09/2014, Paul Norman <penorman at 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 at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstreetmap.org/pipermail/talk/attachments/20140917/90ebbcae/attachment.sig>


More information about the talk mailing list