[Tagging] Removing name_1 and alt_name_1 from Wiki

Colin Smale colin.smale at xs4all.nl
Tue Jan 19 19:02:04 UTC 2016


Who says the lists using a semicolon are by definition unordered? 

A road with multiple ref's might have ref=A1;A2 where A1 is listed first
on the signs. A shop with multiple categories (I know this is subject to
some discussion) might have shop=a;b;c where shop=a is its primary
categorisation. A road with destination=City1;City2 may show City1 first
or more prominently on signs. If you try to say that these values are
unordered by definition, i.e. the order conveys no meaning at all, I am
sure you will get a lot of pushback.. 

Anyway, syntactically the semicolon syntax is pretty damn similar to the
pipe syntax for lanes, except that (so far) an empty value doesn't make
sense in the places that are currently using the semicolon syntax.
Looking through the eyes of a lexical parser I see no intrinsic reason
why the two delimiters should be treated so differently. Tags and values
are for machine processing, not for direct human consumption; in order
to be fit-for-purpose they have to lend themselves to machine
interpretation, and that usually means well-defined rules of syntax. 

//colin 

On 2016-01-19 19:41, Hakuch wrote:

> On 19.01.2016 19:25, Colin Smale wrote: 
> 
>> So how do you indicate a missing/empty value in the middle of the list?
>> Does "a;;b" mean a single value of "a;b" or does it mean three values
>> "a", "" and "b"?
>> 
>> The "lanes" tag family uses a different delimiter ("|"), sometimes
>> together with a semicolon to make a kind of 2-d array. A double pipe
>> ("||") indicates a missing value there. Wouldn't it be nice if we were
>> consistent?
> 
> no, that is a complete different situation. The lane-family use
> parameters (if you like it or not), so every position has a meaning.
> 
> The semicolon is for (unordered) lists, an empty value doesn't make any
> sense there.
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20160119/5aa4f399/attachment.html>


More information about the Tagging mailing list