[Tagging] Various alt_name values?

[Colin Smale]

So the "root problem" is how to support multi-valued keys. 

Using the semicolon puts the solution into the value, using numbered
keys puts the solution into the keys. As (AFAIK) both the keys and the
values are limited to 255 chars, I can see that being a limitation for
value-based solutions. 

Just putting ":1" at the end of the key is dangerous because this will
overlap with the namespace idea. Should you parse "a:1" as "the first
value of key a" or as "key 1 in the namespace a"? Adding "_1" will cause
similar issues - is "a_1" a the first value of key "a" or is it a key in
its own right? These are some of the things which will normalising and
documenting. 

The traditional way of representing a vector element uses some kind of
brackets, so we might have "name[1]=value". The advantage of this is
that it is unambiguous and familiar to many people. 

Multi-valued keys, if implemented properly in the underlying data model,
will require a change to the database layout, the XML/PBF formats, and
of course to numerous pieces of software. 

Colin 

On 2014-11-27 12:59, moltonel 3x Combo wrote: 

> On 27/11/2014, Colin Smale <colin.smale at xs4all.nl> wrote:
> 
>> Big +1 for that.
> 
> -1.
> 
> On what do you base your assumption that nominatim is the only
> software implementing numbered keys ? How is documenting what a major
> osm software does a bad thing ? For better or worse, the numbered keys
> scheme sees a good bit of use according to taginfo (it's harder to get
> numbers on the semicolon scheme).
> 
>> To me, solving it from the root means formalising the use of the semicolon as a value separator, and cracking some hard nuts like how to handle a legitimate semicolon in the data itself and how to handle the quoting/escaping that that will involve.
> 
> To me, the semincolon scheme as a general solution is a very bad idea,
> and I'd hate to see it "formalised" to the exclusion of other schemes.
> That's because it's so easy for data users to get it wrong. Either the
> data user forgets to do the split, or he does it when it wasn't the
> mapper's intent, or litteral semincolons in the data get in the way.
> 
> In contrast, the numbered keys scheme is a bit ugly and harder to use,
> but it's very unlikely that a data user would get it wrong. At worse,
> only the first value will be picked up, which is a more gracefull
> degradation than the semicolon worst-case.
> 
> It's still an unsatisfactory solution, and I've been arguing for
> direct support of multi-value keys in the osm data model, but that's a
> much longer-term prospect.
> 
>> But let's do it once and once only, so it can be used consistently across all the editors and consumers in our ecosystem.
> 
> Agreed. And that's why I don't like the semiclon scheme, because I
> can't imagine it being used in an error-free consistent manner.
> 
> PS: whiile we're talking about multiple values for the alt_name key
> specificaly... WTF ? "alt_name" is already a way to encode 1
> additional value for the "name" key, so if you're describing a scheme
> to add any number of additional values, apply this scheme to "name"
> and not "alt_name".
> 
> _______________________________________________
> Tagging mailing list
> Tagging at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging [1]
 

Links:
------
[1] https://lists.openstreetmap.org/listinfo/tagging
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20141127/4652ebf6/attachment.html>