Re: [Tagging] Removing name_1 and alt_name_1 from Wiki

[Tijmen Stam]

With the value "none"

For example on German Autobahnen, where you can drive as fast as you 
want is "maxspeed=none" which is different from having maxspeed not set: 
this means maxspeed is unknown or not tagged yet.




On 20-01-16 09:06, Colin Smale wrote:

Exactly.

If a missing value (i.e. use the default) is not the same as explicitly
having NO value, how do you override the default with "no value"?

--colin

On 2016-01-20 08:50, Gerd Petermann wrote:


I don't think that the meaning really depends on the position. My
understanding is that the

complete value (e.g. "80||" ) is parsed by splitting it into separate
strings at each pipe symbol.

Result: three strings: "80" , "",""

The value "|80|" also gives three strings: "","80",""

Another point is that an empty value means "use the default", which can

only make sense in special cases  like this.

Gerd



*Von:* Colin Smale <colin.sm...@xs4all.nl>
*Gesendet:* Mittwoch, 20. Januar 2016 08:23
*An:* Tag discussion, strategy and related tools
*Betreff:* Re: [Tagging] Removing name_1 and alt_name_1 from Wiki

I meant that there is a value missing "between the pipes", which at a
slightly higher semantic level can mean "use the default". A
definition which varies according to position doesn't feel well-formed
to me.

//colin

On 2016-01-20 08:10, Gerd Petermann wrote:

Colin Smale wrote

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?


That is new to me. My understanding of a double pipe is that
described here:

http://wiki.openstreetmap.org/wiki/Proposed_features/lanes_General_Extension#Default_values

Proposed features/lanes General Extension - OpenStreetMap Wiki

<http://wiki.openstreetmap.org/wiki/Proposed_features/lanes_General_Extension#Default_values>
wiki.openstreetmap.org
A simple, straightforward extension of existing tags to specify
properties not only for a way as whole but for the lanes of the
way instead. Based on this general ...


which indicates that a double pipe means one or two default values,
depending on the position.
At the end of the value, it means two default values.

Gerd



--
View this message in context:

http://gis.19327.n5.nabble.com/Removing-name-1-and-alt-name-1-from-Wiki-tp5864465p5865207.html

<http://gis.19327.n5.nabble.com/Removing-name-1-and-alt-name-1-from-Wiki-tp5864465p5865207.html>
Sent from the Tagging mailing list archive at Nabble.com.

___
Tagging mailing list
Tagging@openstreetmap.org <mailto:Tagging@openstreetmap.org>
https://lists.openstreetmap.org/listinfo/tagging


___
Tagging mailing list
Tagging@openstreetmap.org <mailto:Tagging@openstreetmap.org>
https://lists.openstreetmap.org/listinfo/tagging



___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging




___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Removing name_1 and alt_name_1 from Wiki

[Colin Smale]

At present the string "none" is actually a value, the interpretation of which 
is specific to the key "maxspeed" . Maybe we should promote it to the 
equivalent of NULL in SQL. 


On 24 January 2016 10:43:16 CET, Tijmen Stam <mailingli...@iivq.net> wrote:
>With the value "none"
>
>For example on German Autobahnen, where you can drive as fast as you 
>want is "maxspeed=none" which is different from having maxspeed not
>set: 
>this means maxspeed is unknown or not tagged yet.
>
>
>
>On 20-01-16 09:06, Colin Smale wrote:
>> Exactly.
>>
>> If a missing value (i.e. use the default) is not the same as
>explicitly
>> having NO value, how do you override the default with "no value"?
>>
>> --colin
>>
>> On 2016-01-20 08:50, Gerd Petermann wrote:
>>
>>> I don't think that the meaning really depends on the position. My
>>> understanding is that the
>>>
>>> complete value (e.g. "80||" ) is parsed by splitting it into
>separate
>>> strings at each pipe symbol.
>>>
>>> Result: three strings: "80" , "",""
>>>
>>> The value "|80|" also gives three strings: "","80",""
>>>
>>> Another point is that an empty value means "use the default", which
>can
>>>
>>> only make sense in special cases  like this.
>>>
>>> Gerd
>>>
>>>
>>>
>
>>> *Von:* Colin Smale <colin.sm...@xs4all.nl>
>>> *Gesendet:* Mittwoch, 20. Januar 2016 08:23
>>> *An:* Tag discussion, strategy and related tools
>>> *Betreff:* Re: [Tagging] Removing name_1 and alt_name_1 from Wiki
>>>
>>> I meant that there is a value missing "between the pipes", which at
>a
>>> slightly higher semantic level can mean "use the default". A
>>> definition which varies according to position doesn't feel
>well-formed
>>> to me.
>>>
>>> //colin
>>>
>>> On 2016-01-20 08:10, Gerd Petermann wrote:
>>>
>>> Colin Smale wrote
>>>
>>> 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?
>>>
>>>
>>> That is new to me. My understanding of a double pipe is that
>>> described here:
>>>
>http://wiki.openstreetmap.org/wiki/Proposed_features/lanes_General_Extension#Default_values
>>>
>>> Proposed features/lanes General Extension - OpenStreetMap Wiki
>>>
><http://wiki.openstreetmap.org/wiki/Proposed_features/lanes_General_Extension#Default_values>
>>> wiki.openstreetmap.org
>>> A simple, straightforward extension of existing tags to specify
>>> properties not only for a way as whole but for the lanes of the
>>> way instead. Based on this general ...
>>>
>>>
>>> which indicates that a double pipe means one or two default
>values,
>>> depending on the position.
>>> At the end of the value, it means two default values.
>>>
>>> Gerd
>>>
>>>
>>>
>>> --
>>> View this message in context:
>>>
>http://gis.19327.n5.nabble.com/Removing-name-1-and-alt-name-1-from-Wiki-tp5864465p5865207.html
>>>
><http://gis.19327.n5.nabble.com/Removing-name-1-and-alt-name-1-from-Wiki-tp5864465p5865207.html>
>>> Sent from the Tagging mailing list archive at Nabble.com.
>>>
>>> ___
>>> Tagging mailing list
>>> Tagging@openstreetmap.org <mailto:Tagging@openstreetmap.org>
>>> https://lists.openstreetmap.org/listinfo/tagging
>>>
>>>
>>> ___
>>> Tagging mailing list
>>> Tagging@openstreetmap.org <mailto:Tagging@openstreetmap.org>
>>> https://lists.openstreetmap.org/listinfo/tagging
>>
>>
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>>
>
>
>___
>Tagging mailing list
>Tagging@openstreetmap.org
>https://lists.openstreetmap.org/listinfo/tagging
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Removing name_1 and alt_name_1 from Wiki

[Gerd Petermann]

I don't think so. Where do we need null values in OSM?

As you said, maxspeed=none means something like maxspeed=unlimited.

I can't think of any tag key which should be stored in OSM with a null value.

In what case would that add valud information compared to having no such tag ?


Gerd


Von: Colin Smale <colin.sm...@xs4all.nl>
Gesendet: Sonntag, 24. Januar 2016 10:58
An: Tag discussion, strategy and related tools; Tijmen Stam
Betreff: Re: [Tagging] Removing name_1 and alt_name_1 from Wiki

At present the string "none" is actually a value, the interpretation of which 
is specific to the key "maxspeed" . Maybe we should promote it to the 
equivalent of NULL in SQL.


On 24 January 2016 10:43:16 CET, Tijmen Stam <mailingli...@iivq.net> wrote:

With the value "none"

For example on German Autobahnen, where you can drive as fast as you
want is "maxspeed=none" which is different from having maxspeed not set:
this means maxspeed is unknown or not tagged yet.



On 20-01-16 09:06, Colin Smale wrote:
 Exactly.

 If a missing value (i.e. use the default) is not the same as explicitly
 having NO value, how do you override the default with "no value"?

 --colin

 On 2016-01-20 08:50, Gerd Petermann wrote:

 I don't think that the meaning really depends on the position. My
 understanding is that the

 complete value (e.g. "80||" ) is parsed by splitting it into separate

strings at each pipe symbol.

 Result: three strings: "80" , "",""

 The value "|80|" also gives three strings: "","80",""

 Another point is that an empty value means "use the default", which can

 only make sense in special cases  like this.

 Gerd




 *Von:* Colin Smale <colin.sm...@xs4all.nl>
 *Gesendet:* Mittwoch, 20. Januar 2016 08:23
 *An:* Tag discussion, strategy and related tools
 *Betreff:* Re: [Tagging] Removing name_1 and alt_name_1 from Wiki

 I meant that there is a value missing "between the pipes", which at a
 slightly higher semantic level can mean "use the default". A
 definition which varies according to position doesn't feel well-formed
 to me.

 //colin

 On 2016-01-20 08:10, Gerd Petermann wrote:

 Colin Smale wrote

 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?


 That is new to me. My understanding of a double pipe is that
 described here:
 
http://wiki.openstreetmap.org/wiki/Proposed_features/lanes_General_Extension#Default_values
Proposed
 features/lanes General Extension - OpenStreetMap 
Wiki<http://wiki.openstreetmap.org/wiki/Proposed_features/lanes_General_Extension#Default_values>
wiki.openstreetmap.org
A
 simple, straightforward extension of existing tags to specify properties not 
only for a way as whole but for the lanes of the way instead. Based on this 
general ...



 Proposed features/lanes General Extension - OpenStreetMap Wiki
 
<http://wiki.openstreetmap.org/wiki/Proposed_features/lanes_General_Extension#Default_values>
 wiki.openstreetmap.org<http://wiki.openstreetmap.org>
 A simple, straightforward extension of existing tags to specify

properties not only for a way as whole but for the lanes of the
 way instead. Based on this general ...


 which indicates that a double pipe means one or two default values,
 depending on the position.
 At the end of the value, it means two default values.

 Gerd



 --
 View this message in context:
 
http://gis.19327.n5.nabble.com/Removing-name-1-and-alt-name-1-from-Wiki-tp5864465p5865207.html
 
<http://gis.19327.n5.nabble.com/Removing-name-1-and-alt-name-1-from-Wiki-tp5864465p5865207.html>
 Sent from the Tagging mailing list archive at 
Nabble.com<http://Nabble.com>.



 Tagging mailing list

Tagging@openstreetmap.org <mailto:Tagging@openstreetmap.org>
 https://lists.openstreetmap.org/listinfo/tagging




 Tagging mailing list
 Tagging@openstreetmap.org <mailto:Tagging@openstreetmap.org>
 https://lists.openstreetmap.org/listinfo/tagging




 Tagging mailing list
 Tagging@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/tagging





Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Removing name_1 and alt_name_1 from Wiki

[Colin Smale]

We probably don't need a true technical null value, you are right. But
if we introduce a formal method of defining defaults or implied values,
for example if highway=residential implies maxspeed=30 "unless tagged
otherwise", how can we tag "maxspeed is truly unknown, do not apply the
defaults"? Sure, we can use maxspeed=unknown, but then the value
"unknown" has the effect of NULL, i.e. a placeholder where a value could
be stored, but there is nothing there now. If we agree on using a
specific value like "none" or "unknown" or "NULL" for this function,
then defaults could possibly be applied in a broader, more defined way. 

On 2016-01-24 11:12, Gerd Petermann wrote:

> I don't think so. Where do we need null values in OSM? 
> 
> As you said, maxspeed=none means something like maxspeed=unlimited. 
> 
> I can't think of any tag key which should be stored in OSM with a null value. 
> 
> In what case would that add valud information compared to having no such tag 
> ? 
> 
> Gerd 
> 
> -
> 
> VON: Colin Smale <colin.sm...@xs4all.nl>
> GESENDET: Sonntag, 24. Januar 2016 10:58
> AN: Tag discussion, strategy and related tools; Tijmen Stam
> BETREFF: Re: [Tagging] Removing name_1 and alt_name_1 from Wiki 
> 
> At present the string "none" is actually a value, the interpretation of which 
> is specific to the key "maxspeed" . Maybe we should promote it to the 
> equivalent of NULL in SQL. 
> 
> On 24 January 2016 10:43:16 CET, Tijmen Stam <mailingli...@iivq.net> wrote: 
> 
> With the value "none"
> 
> For example on German Autobahnen, where you can drive as fast as you 
> want is "maxspeed=none" which is different from having maxspeed not set: 
> this means maxspeed is unknown or not tagged yet.
> 
> On 20-01-16 09:06, Colin Smale wrote:
> Exactly.
> 
> If a missing value (i.e. use the default) is not the same as explicitly
> having NO value, how do you override the default with "no value"?
> 
> --colin
> 
> On 2016-01-20 08:50, Gerd Petermann wrote:
> 
> I don't think that the meaning really depends on the position. My
> understanding is that the
> 
> complete value (e.g. "80||" ) is parsed by splitting it into separate
> strings at each pipe symbol.
> 
> Result: three strings: "80" , "",""
> 
> The value "|80|" also gives three strings: "","80",""
> 
> Another point is that an empty value means "use the default", which can
> 
> only make sense in special cases like this.
> 
> Gerd
> 
> -
> 
> *Von:* Colin Smale <colin.sm...@xs4all.nl>
> *Gesendet:* Mittwoch, 20. Januar 2016 08:23
> *An:* Tag discussion, strategy and related tools
> *Betreff:* Re: [Tagging] Removing name_1 and alt_name_1 from Wiki
> 
> I meant that there is a value missing "between the pipes", which at a
> slightly higher semantic level can mean "use the default". A
> definition which varies according to position doesn't feel well-formed
> to me.
> 
> //colin
> 
> On 2016-01-20 08:10, Gerd Petermann wrote:
> 
> Colin Smale wrote
> 
> 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?
> 
> That is new to me. My understanding of a double pipe is that
> described here:
> http://wiki.openstreetmap.org/wiki/Proposed_features/lanes_General_Extension#Default_values
>  
> 
> Proposed features/lanes General Extension - OpenStreetMap Wiki [1] 
> wiki.openstreetmap.org 
> A simple, straightforward extension of existing tags to specify properties 
> not only for a way as whole but for the lanes of the way instead. Based on 
> this general ... 
> 
> Proposed features/lanes General Extension - OpenStreetMap Wiki
> <http://wiki.openstreetmap.org/wiki/Proposed_features/lanes_General_Extension#Default_values>
> wiki.openstreetmap.org [2]
> A simple, straightforward extension of existing tags to specify
> properties not only for a way as whole but for the lanes of the
> way instead. Based on this general ...
> 
> which indicates that a double pipe means one or two default values,
> depending on the position.
> At the end of the value, it means two default values.
> 
> Gerd
> 
> --
> View this message in context:
> http://gis.19327.n5.nabble.com/Removing-name-1-and-alt-name-1-from-Wiki-tp5864465p5865207.html
> <http://gis.19327.n5.nabble.com/Rem

Re: [Tagging] Removing name_1 and alt_name_1 from Wiki

[Lauri Kytömaa]

On Wed, Mike N wrote:
> On 1/20/2016 3:39 PM, Dominic Coletti wrote:
>> I see 808,000 uses of name_1 and 65,000 of name_2.
> Many of these are from the US TIGER import, and must not be automatically
> removed.  They would go into alt_name , etc based on local knowledge.

I believe this is a good point to make, the origin for many of those tags.
While the number of uses is reason to keep them as-is, if a major slice
of them comes from an import, the ratio isn't a good reason to *recommend*
entering more of them.

Browsing through this thread I didn't notice one point, the fact that with
alt_name=a;b;.. all the names are/should be in the semicolon separated
list, i.e. even without any processing that separates the parts/names into
distinct records, searching would indicate that the searched-for name is
within the list of alternative names (in most cases/some countries, not
doing some sort of wildcard matching gives a bad user experience, esp.
if the local word or abbreviation for "street" is always at the beginning).
With name_1 and name_2 and name_9 you'd never know how many tags
you have to look for when indexing the db dump and changes.

Also, with name_[n] the original mapper and the next mappers have to
order the names with reasoning or just how they like them (subjective),
whereas with name=The Name + alt_name=other names the alternative
names are then equal with each other (a collection of alternative names).
What should be in the plain name tag is easier to agree on (especially if
the operator behind the named entity can be asked), than it would be to
agree on the sorting of the other known names.

-- 
alv

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Removing name_1 and alt_name_1 from Wiki

[moltonel 3x Combo]

Taped "send" to early, here's the rest of my email:

On 23 January 2016 15:14:22 GMT+00:00, "Lauri Kytömaa" 
 wrote:
>I believe this is a good point to make, the origin for many of those
>tags.
>While the number of uses is reason to keep them as-is, if a major slice
>of them comes from an import, the ratio isn't a good reason to
>*recommend*
>entering more of them.

 It's a pity that the us taginfo site is defunct; it would have given an
 interesting approximation of how many name_1 come from tiger. But I'm tired
 of this "most name_1 tags are from an import, they should be ignored"
 argument :
 * coming from an import doesn't make name_1 wrong. It's a valid (IMHO
superior) way of expressing multiple values.
 * the most you can claim is that this import sometimes incorrectly
assigned multiple values when there should be only one.
 * there are plenty of uses of name_1 outside of tiger. While the
ratio is unknown, a glance at the taginfo map shows that it isn't
negligible.
 * while popularity of a tag can on its own be enough to justify
documenting the tag, it's never a good enough reason on it own to
justify recomending it. Accordingly, the calls to recomend name_1
usage are not just based on the tag's popularity.

>Browsing through this thread I didn't notice one point, the fact that
>with
>alt_name=a;b;.. all the names are/should be in the semicolon separated
>list, i.e. even without any processing that separates the parts/names
>into
>distinct records, searching would indicate that the searched-for name
>is
>within the list of alternative names (in most cases/some countries, not
>doing some sort of wildcard matching gives a bad user experience, esp.
>if the local word or abbreviation for "street" is always at the
>beginning).

That's a good corner-case example where a multivalue-unaware consumer
still gets some benefit of the multivalue if it is encoded using
semicolons. Of course it goes haywire again when trying to display the
value, and could cause other subtle issues, with stemming for example.

>With name_1 and name_2 and name_9 you'd never know how many tags
>you have to look for when indexing the db dump and changes.

I don't get that, or rather I don't get how it's different from never
knowing how many values you're going to get in the semicolon case.
Maybe you're thinking of an implementation that'd look for "name_1",
"name_2", etc explicitly for each variation ? No programmer in his/her
right mind would do that, (s)he'll regexp-match for "name_[0-9]+"
instead or (like for example Nominatim does) just match the beginning
of the string agains "name_".

>Also, with name_[n] the original mapper and the next mappers have to
>order the names with reasoning or just how they like them (subjective),
>whereas with name=The Name + alt_name=other names the alternative
>names are then equal with each other (a collection of alternative
>names).

Firstly, there's nothing that says "the order in which the values are
entered are their order of importance in real life". Wether the order
of the values matters or not is something that should be discussed on
a per-tag basis. The only tag that I know where this matters is
lanes=*, but it has its own complicated and well-defined
special-purpose syntax.

Secondly, the ordered_or_not situation is exactly the same with the
semicolon scheme as with the suffix scheme, neither can claim
superiority here.

>What should be in the plain name tag is easier to agree on (especially
>if
>the operator behind the named entity can be asked), than it would be to
>agree on the sorting of the other known names.

Again, there's no difference between the two schemes regarding the
tagging of the "default" value. It goes, on its own, in the "name" tag
and that's it. How you encode the default value does not influence how
you choose the default value. And yes, we should really discourage the
omission of a default value, whether it's by ommiting the plain "name"
tag or by putting semicolon-separated values in it instead of in
alt_name.

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Removing name_1 and alt_name_1 from Wiki

[moltonel]

On 23 January 2016 15:14:22 GMT+00:00, "Lauri Kytömaa"  
wrote:
>I believe this is a good point to make, the origin for many of those
>tags.
>While the number of uses is reason to keep them as-is, if a major slice
>of them comes from an import, the ratio isn't a good reason to
>*recommend*
>entering more of them.

It's a pity that the us taginfo site is defunct; it would have given an 
interesting approximation of how many name_1 come from tiger. But I'm tired of 
this "most name_1 tags are from an import, they should be ignored" argument :
* coming from an import doesn't make name_1 wrong. It's a valid (IMHO superior) 
way of expressing multiple values.
* the most you can claim is that this import sometimes incorrectly assigned 
multiple values when there should be only one.
* there are plenty of uses of name_1 outside of tiger. While the ratio is 
unknown, a glance at the taginfo map shows that it isn't negligible.
* while popularity of a tag can on its own be enough to justify documenting the 
tag, it's never a good enough reason on it own to justify recomending it. 
Accordingly, the calls to recomend name_1 usage are not just b

>
>Browsing through this thread I didn't notice one point, the fact that
>with
>alt_name=a;b;.. all the names are/should be in the semicolon separated
>list, i.e. even without any processing that separates the parts/names
>into
>distinct records, searching would indicate that the searched-for name
>is
>within the list of alternative names (in most cases/some countries, not
>doing some sort of wildcard matching gives a bad user experience, esp.
>if the local word or abbreviation for "street" is always at the
>beginning).
>With name_1 and name_2 and name_9 you'd never know how many tags
>you have to look for when indexing the db dump and changes.
>
>Also, with name_[n] the original mapper and the next mappers have to
>order the names with reasoning or just how they like them (subjective),
>whereas with name=The Name + alt_name=other names the alternative
>names are then equal with each other (a collection of alternative
>names).
>What should be in the plain name tag is easier to agree on (especially
>if
>the operator behind the named entity can be asked), than it would be to
>agree on the sorting of the other known names.
>
>-- 
>alv
>
>___
>Tagging mailing list
>Tagging@openstreetmap.org
>https://lists.openstreetmap.org/listinfo/tagging

-- 
Vincent Dp

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Removing name_1 and alt_name_1 from Wiki

[Colin Smale]

Thanks for your comments Martin! 

On 2016-01-21 12:21, Martin Koppenhoefer wrote:

> 2016-01-21 11:03 GMT+01:00 Colin Smale :
> 
>> A few candidates I can think of for incorporation in to the OSM (meta)model: 
>> 
>> * date/time format
> 
> +1, the opening_hours syntax is IMHO the defacto standard, it is also used in 
> other context, e.g. service_times or conditional tagging.

The opening_hours syntax goes way beyond the definition of a date/time.
I was thinking more about ISO8601, which on the one hand allows full
specification including fractions of seconds and timezones, and on the
other hand allows a degenerate partial syntax where all that detail is
not required. In opening_hours the time is specified as hh:mm, and this
is compatible with ISO8601. 

We also have values representing a date - such as start_date. The wiki
page already refers to ISO8601, but the point I would like to make is
that this reference should be at an "OSM" level, and not at the level of
an individual tag. 

>> * number format
> 
> what do you mean? "." or "," as decimal separator ? In Italy we often have 
> dates (or nobles, popes, ...) in street names, and those are written 
> differently in different documents / signs, sometimes as words, or arabian or 
> latin numbers, e.g. Quattro Novembre can also be "4 Novembre" or "IV 
> Novembre". or Pio Quinto can also be Pio V 
> Currently we either do nothing or we write the alternatives in alt_name etc.

I mean numerical values of keys, not as part of a string. For example
population which can have values into the millions, or maxweight which
has smaller values but may include decimals. Let's agree at a high
level, OSM-wide, that "numbers use . as a decimal separator and no
thousands groupings". Anywhere a key has a value which is a number, the
wiki page for that key should refer to the central definition of
"number". Same for date, time, etc - promote the definition from
key-local to OSM-wide. 

>> * units of measurement and their abbreviations

Not as straightforward as you might expect - look at all the different
"tons" there are in the world. Metric, Long Ton, Short Ton... all
different, and all used within OSM. In my work in the financial sector I
learnt that it is basically "extremely bad practice" to have an amount
(of money) without an explicit currency code in the same record - sooner
or later errors will occur. A 10 ton weight limit in the US is not the
same as a 10 ton limit elsewhere, but they are both written as "10" or
"10t". 

>> * support for polygon/area as primitive type
> 
> +1

.. and then redefine a multipolygon in terms of this... 

>> * multi-valued attributes (semicolons vs. _1, [1] etc)
> 
> +1, maybe also different syntax for ordered lists and not?

Indeed. Let's sort this out for once and for all. Re: ordered vs.
unordered: I think they can share a basic syntax, and the specific key's
definition can make it clear to what extent the order is significant. 
Note that the lanes stuff essentially has a syntax for a 2-dimensional
array, using a combination of ";" and "|", give or take some semantic
differences about missing values... 

>> * data structures (related attributes) possibly as a formalisation of the 
>> ":" syntax (so-called namespaces)
> 
> this one I would see a bit different: don't mix up different things, and you 
> don't need to mark "related attributes": all attributes on an object relate 
> to that object. All the times I have found OSM objects with different values 
> for common keys, they actually had been a mix of different objects and as 
> soon as you split them into different objects you don't need these any more 
> (stuff like bridge:name for instance, resulting from bridge objects missing 
> for a long time). You might still need namespaces to say which kind of 
> attribute is meant (e.g. (hypothetical) maxspeed:wet / maxspeed:snow / 
> maxspeed:dry ... or historic:civilization), but these are just different keys 
> that are "visually" grouped for convenience (a logical system that helps 
> finding consistent syntax for new keys) and to allow easier 
> interpretation/avoid misinterpretation of the key by giving a context 
> (similar attributes get similar key names).

I think your comment illustrates why we need to tidy up the definition.
I was thinking of examples like lanes and seamark, where there is
clearly a grouping of tags based on the prefix. You don't need to be
Einstein to extrapolate this into a kind of object/class type of
structure which will open the door to reuse of definitions of "data
structures"... 

I see your example with maxspeed more as a qualification of the key. We
achieve the same effect with maxspeed:conditional, where the effective
value depends on certain conditions, usually time-of-day but I bet there
are some really creative expressions out there. 

It would be nice if the syntax for the data structures can be combined
with the syntax for multiple values, so an object can have a 

Re: [Tagging] Removing name_1 and alt_name_1 from Wiki

[Martin Koppenhoefer]

2016-01-21 11:03 GMT+01:00 Colin Smale :

> A few candidates I can think of for incorporation in to the OSM
> (meta)model:
>
> * date/time format
>

+1, the opening_hours syntax is IMHO the defacto standard, it is also used
in other context, e.g. service_times or conditional tagging.


> * number format
>

what do you mean? "." or "," as decimal separator ? In Italy we often have
dates (or nobles, popes, ...) in street names, and those are written
differently in different documents / signs, sometimes as words, or arabian
or latin numbers, e.g. Quattro Novembre can also be "4 Novembre" or "IV
Novembre". or Pio Quinto can also be Pio V
Currently we either do nothing or we write the alternatives in alt_name etc.



> * units of measurement and their abbreviations
>
* support for polygon/area as primitive type
>

+1


> * multi-valued attributes (semicolons vs. _1, [1] etc)
>

+1, maybe also different syntax for ordered lists and not?


> * data structures (related attributes) possibly as a formalisation of the
> ":" syntax (so-called namespaces)
>

this one I would see a bit different: don't mix up different things, and
you don't need to mark "related attributes": all attributes on an object
relate to that object. All the times I have found OSM objects with
different values for common keys, they actually had been a mix of different
objects and as soon as you split them into different objects you don't need
these any more (stuff like bridge:name for instance, resulting from bridge
objects missing for a long time). You might still need namespaces to say
which kind of attribute is meant (e.g. (hypothetical) maxspeed:wet /
maxspeed:snow / maxspeed:dry ... or historic:civilization), but these are
just different keys that are "visually" grouped for convenience (a logical
system that helps finding consistent syntax for new keys) and to allow
easier interpretation/avoid misinterpretation of the key by giving a
context (similar attributes get similar key names).



* use of "curated lists" for certain keys (i.e. an enumeration where only
> certain defined values are allowed)
>

what do you think about here? Instinctively I'm inclined to reject this
idea, because it is against our open tagging model? As soon as you start
introducing exceptions, (some) people will try to extend this and go around
telling others that their way of mapping is "wrong".


> * reference datum for heights/elevations
>

something that could be agreed upon. Actually I'd guees the very most ele
indications are likely either unprecise (coming from "amateur measurements"
with cellphones or consumer gps devices and are based on GPS, i.e. they
have a higher error level than a wrong reference datum assumption would
produce) or are in the system locally (nationally) used (read off a sign,
copied from a book, etc.).

Cheers,
Martin
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Removing name_1 and alt_name_1 from Wiki

[Colin Smale]

It's a great shame that OSM seems incapable of moving its information
model forwards. There have been so many discussions about the need for a
way of representing multi-valued attributes (as occur in real life)
within the OSM framework, and yet it keeps coming back again and again.
Instead of discussing ad nauseam about individual tags, how about
putting a bit of structure into it, and agreeing a standard way of
representing things, which can be referred to from each wiki page,
instead of each one having its own definition of "what's a number" or
"how to write a date" or whatever. How about the "area" primitive which
has been in the "idea" stage for years? 

I fully expect this post to get shouted down or ignored, and I am
prepared for the worst. I will be listening out for constructive
comments though. 

A few candidates I can think of for incorporation in to the OSM
(meta)model: 

* date/time format 

* number format 

* units of measurement and their abbreviations 

* support for polygon/area as primitive type 

* multi-valued attributes (semicolons vs. _1, [1] etc) 

* data structures (related attributes) possibly as a formalisation of
the ":" syntax (so-called namespaces) 

* mechanism for defining/documenting default/implied values in a
hierarchy of territories 

* use of "curated lists" for certain keys (i.e. an enumeration where
only certain defined values are allowed) 

* reference datum for heights/elevations 

Maybe you can think of more candidates for updates to the OSM metamodel.


--colin 

On 2016-01-21 10:37, moltonel 3x Combo wrote:

> On 21/01/2016, Hakuch  wrote: 
> 
>> I just want to mention again: this proposal is about the wiki, that
>> name_1 and alt_name_1 should not be suggested there for good tagging.
>> Its not about the existing data in OSM.
> 
> And the ongoing discussion in this thread just explains in lenghty
> details why the proposal should be rejected. Existing data in OSM
> being only one of the reasons.
> 
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
 ___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Removing name_1 and alt_name_1 from Wiki

[Dave F.]

On 20/01/2016 09:01, Martin Koppenhoefer wrote:


Power users might switch on the data layer on osm.org  
and look at the data directly


I hardly describe the data layer as 'direct' viewing. It offers the same 
information, in the same format, as looking at a node/way individually: 
No Ks or Vs, & no XML formatting.


Dave F.


---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Removing name_1 and alt_name_1 from Wiki

[moltonel 3x Combo]

On 19/01/2016, Andy Townsend  wrote:
> It's not used by anyone as far as I can see:
>
> http://taginfo.openstreetmap.org/search?q=%3B%3B
>
> (unless taginfo is doing some special filtering)

http://taginfo.openstreetmap.org/search?q=%3B (a single ";") doesn't
find any value either, so taginfo can't be used like that.

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Removing name_1 and alt_name_1 from Wiki

[Dominic Coletti]

I see 808,000 uses of name_1 and 65,000 of name_2.

On Wed, Jan 20, 2016 at 10:07 AM moltonel 3x Combo 
wrote:

> On 19/01/2016, Andy Townsend  wrote:
> > It's not used by anyone as far as I can see:
> >
> > http://taginfo.openstreetmap.org/search?q=%3B%3B
> >
> > (unless taginfo is doing some special filtering)
>
> http://taginfo.openstreetmap.org/search?q=%3B (a single ";") doesn't
> find any value either, so taginfo can't be used like that.
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
-- 
Dominic Coletti
President & CEO
3Dreams Design
205 Anamoor Dr
Cary, NC 27513
(919) 463-9554

NOTICE: This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they are
addressed. If you have received this email in error please notify the
system manager. This message contains confidential information and is
intended only for the individual named. If you are not the named addressee
you should not disseminate, distribute or copy this e-mail. Please notify
the sender immediately by e-mail if you have received this e-mail by
mistake and delete this e-mail from your system. If you are not the
intended recipient you are notified that disclosing, copying, distributing
or taking any action in reliance on the contents of this information is
strictly prohibited.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Removing name_1 and alt_name_1 from Wiki

[Hakuch]

I just want to mention again: this proposal is about the wiki, that
name_1 and alt_name_1 should not be suggested there for good tagging.
Its not about the existing data in OSM.

On 20.01.2016 23:35, moltonel 3x Combo wrote:
> On 20/01/2016, Mike N  wrote:
>> On 1/20/2016 3:39 PM, Dominic Coletti wrote:
>>> I see 808,000 uses of name_1 and 65,000 of name_2.
> 
> And 609,505 alt_name and 6,013 alt_name_1.
> 
> These approximate figues have already been mentioned in this thread.
> Does Anybody have stats on how many "*name*" tags have values with
> semicolons ? Bonus points for pointing out cases of litteral ";" in
> the name.
> 
>> Many of these are from the US TIGER import, and must not be
>> automatically removed.  They would go into alt_name , etc based on local
>> knowledge.
> 
> Appart from using this as a cunning way to track which TIGER names
> have been reviewed, there's IMHO no good reason to convert an existing
> "name_1" to "alt_name".
> 
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
> 


0x3CBE432B.asc
Description: application/pgp-keys
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Removing name_1 and alt_name_1 from Wiki

[moltonel 3x Combo]

On 20/01/2016, Mike N  wrote:
> On 1/20/2016 3:39 PM, Dominic Coletti wrote:
>> I see 808,000 uses of name_1 and 65,000 of name_2.

And 609,505 alt_name and 6,013 alt_name_1.

These approximate figues have already been mentioned in this thread.
Does Anybody have stats on how many "*name*" tags have values with
semicolons ? Bonus points for pointing out cases of litteral ";" in
the name.

> Many of these are from the US TIGER import, and must not be
> automatically removed.  They would go into alt_name , etc based on local
> knowledge.

Appart from using this as a cunning way to track which TIGER names
have been reviewed, there's IMHO no good reason to convert an existing
"name_1" to "alt_name".

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Removing name_1 and alt_name_1 from Wiki

[Wolfgang Zenker]

* Mike N  [160120 21:47]:
> On 1/20/2016 3:39 PM, Dominic Coletti wrote:
>> I see 808,000 uses of name_1 and 65,000 of name_2.

> Many of these are from the US TIGER import, and must not be 
> automatically removed.  They would go into alt_name , etc based on local 
> knowledge.

The problem with that is that TIGER just gives several names for
a way segment without prioritizing them. Sometimes you can identify
some as mis-spellings but in most cases it is impossible to decide
from TIGER data alone which name should be in the name tag and
which one should be somewhere else. Hence the name_x tags with name
and name_x which are for any x presumed equally important.

That could of course be fixed with local knowledge, because many
of these multiple names are simply wrong. We just don't know which
ones, and for most of the rural parts of the US we don't have any
local mappers (yet).

Wolfgang

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Removing name_1 and alt_name_1 from Wiki

[Martin Koppenhoefer]

2016-01-20 8:30 GMT+01:00 Colin Smale :

> Yes I'm sure... Notice I put the word "direct" in there. No "end user" of
> the data will use the data directly, there is always a presentation layer
> in the middle, which formats up numbers and dates, converts units,
> localises key words, etc etc.



it really depends on the end user. Power users might switch on the data
layer on osm.org and look at the data directly (to people familiar with our
tagging I'd actually recommend to do so, would be nice if more applications
did actually offer this possibility). I agree though that most end users
won't.

Cheers,
Martin
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Removing name_1 and alt_name_1 from Wiki

[Hakuch]

On 20.01.2016 08:30, Colin Smale wrote:
> If the "semicolon
> syntax" defines a "list of values", shouldn't stuff remove an empty
> value from the list (i.e. replace ;; with ; ) and then remove the whole
> tag if the list is empty? 

no, because in this context (semicolons) the ;;  should't be recognized
as empty value but as an escaped semicolon. There is no sense for empty
values in this context.

Differently from the use of | pipes:
key=|| would mean: param1=empty, param2=empty
key=|50| would mean: param1=empty, param2=50, param3=empty

and this empty COULD be identified as "use default value XX for this
param", but that must be defined somehow (wiki...) for this specific
key. You even could define "there must not be any empty values", then
this tags would be invalid.

by the way, this topic has lost the connection to the proposal


0x3CBE432B.asc
Description: application/pgp-keys
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Removing name_1 and alt_name_1 from Wiki

[Hakuch]

however, everything depends on the key definition, in opening_hours for
example you use || as "or". Thats ok because that key does not expect
parameters, lane=* does

On 20.01.2016 15:05, Hakuch wrote:
> On 20.01.2016 08:30, Colin Smale wrote:
>> If the "semicolon
>> syntax" defines a "list of values", shouldn't stuff remove an empty
>> value from the list (i.e. replace ;; with ; ) and then remove the whole
>> tag if the list is empty? 
> 
> no, because in this context (semicolons) the ;;  should't be recognized
> as empty value but as an escaped semicolon. There is no sense for empty
> values in this context.
> 
> Differently from the use of | pipes:
> key=|| would mean: param1=empty, param2=empty
> key=|50| would mean: param1=empty, param2=50, param3=empty
> 
> and this empty COULD be identified as "use default value XX for this
> param", but that must be defined somehow (wiki...) for this specific
> key. You even could define "there must not be any empty values", then
> this tags would be invalid.
> 
> by the way, this topic has lost the connection to the proposal
> 
> 
> 
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
> 


0x3CBE432B.asc
Description: application/pgp-keys
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Removing name_1 and alt_name_1 from Wiki

[Hakuch]

ok, let not call it unordered, but it is just a list without positions.
If you are using | pipes, you have specific positions. And there, an
empty value is also a value/information. But if you have a list like you
should do with ; an empty value would be nothing, there wont be any
information that you could read from this non-value, differently from an
empty position with | pipes.

Anyway, if you want to introduce \; and not ;; for escaping, ok. but you
have to make a proposal and so on. ;; is already fixed in wiki, and I
really would not like to talk about such a situation that practically
never occurs.

On 19.01.2016 20:02, Colin Smale wrote:
> 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.
>  
> 


0x3CBE432B.asc
Description: application/pgp-keys
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Removing name_1 and alt_name_1 from Wiki

[Hakuch]

On 19.01.2016 19:40, Andy Townsend wrote:
> On 19/01/2016 18:02, Hakuch wrote:
>> It might not be used by that much developers,
> 
> It's not used by anyone as far as I can see:
> 
> http://taginfo.openstreetmap.org/search?q=%3B%3B
> 
> (unless taginfo is doing some special filtering)
> 

it seems so:
http://taginfo.openstreetmap.org/search?q=%3Bname#values

here Iam looking for ";name" but only "name" is found

> Rather than
> telling everyone else how to map, I'd suggest that you move on and map
> the rest of the world that isn't mapped yet.

ehm, this is a discussion for a proposal process, and this is the
tagging list, so its just the right place for discussions like this


0x3CBE432B.asc
Description: application/pgp-keys
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Removing name_1 and alt_name_1 from Wiki

[Hakuch]

On 10.01.2016 22:29, moltonel 3x Combo wrote:
> Actually to my human eyes, both semicolons and suffixes are equally
> ugly (but pragmatic). It's for processing that suffixes are supperior:
> * Spliting by semicolons (no regexp needed :p) is easy but naive,
> because semicolons are sometimes part of the actual value.
> * One workaround is to use some kind of escape character, but this is
> an impementation/spec minefield that we'll never get right.
> * Another is to maintain a whitelist of tags that can be split by
> semicolon, but it's extra work and everybody'll have a different list.

actually, I just found that we have a solution for this in Wiki:

http://wiki.openstreetmap.org/wiki/Semi-colon_value_separator#Escaping_with_.27.3B.3B.27

It might not be used by that much developers, but they can find it in
Wiki if they want to care for their data


0x3CBE432B.asc
Description: application/pgp-keys
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Removing name_1 and alt_name_1 from Wiki

[Andy Townsend]

On 19/01/2016 18:02, Hakuch wrote:

On 10.01.2016 22:29, moltonel 3x Combo wrote:

Actually to my human eyes, both semicolons and suffixes are equally
ugly (but pragmatic). It's for processing that suffixes are supperior:
* Spliting by semicolons (no regexp needed :p) is easy but naive,
because semicolons are sometimes part of the actual value.
* One workaround is to use some kind of escape character, but this is
an impementation/spec minefield that we'll never get right.
* Another is to maintain a whitelist of tags that can be split by
semicolon, but it's extra work and everybody'll have a different list.

actually, I just found that we have a solution for this in Wiki:

http://wiki.openstreetmap.org/wiki/Semi-colon_value_separator#Escaping_with_.27.3B.3B.27

It might not be used by that much developers,


It's not used by anyone as far as I can see:

http://taginfo.openstreetmap.org/search?q=%3B%3B

(unless taginfo is doing some special filtering)


but they can find it in
Wiki if they want to care for their data


Data consumers (or at least, _this_ data consumer) don't view the 
"official use" as all the information they need about how to interpret 
OSM data.  For example, if I see a highway=residential in the middle of 
a desert in the USA I don't think "residential road" I think "unfixed 
TIGER data".


Basically you (and some other people) have a different view as to the 
best way to represent multiple names compared to Vincent (and some other 
people).  It doesn't matter who is "right" or "wrong"; the thing to take 
away is that "actually, it's a fairly complicated issue".  Rather than 
telling everyone else how to map, I'd suggest that you move on and map 
the rest of the world that isn't mapped yet.


Cheers,

Andy



___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Removing name_1 and alt_name_1 from Wiki

[Colin Smale]

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.
 ___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Removing name_1 and alt_name_1 from Wiki

[Colin Smale]

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? 

FWIW a better way would be to escape the special character by prefixing
it with a backslash ("\"). If you need a backslash in the data you
escape it in the same way - so you get a double backslash. So the
example above would be "a\;b" for a single value, or "a;;b" for three
values (of which the second is missing or empty). This is the mechanism
adopted by just about all the modern programming languages in the world,
so there must be something in it 

Whatever syntax we use, it needs to be unambiguous, or we will run into
problems sooner or later. 

//colin 

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

> On 10.01.2016 22:29, moltonel 3x Combo wrote: 
> 
>> Actually to my human eyes, both semicolons and suffixes are equally
>> ugly (but pragmatic). It's for processing that suffixes are supperior:
>> * Spliting by semicolons (no regexp needed :p) is easy but naive,
>> because semicolons are sometimes part of the actual value.
>> * One workaround is to use some kind of escape character, but this is
>> an impementation/spec minefield that we'll never get right.
>> * Another is to maintain a whitelist of tags that can be split by
>> semicolon, but it's extra work and everybody'll have a different list.
> 
> actually, I just found that we have a solution for this in Wiki:
> 
> http://wiki.openstreetmap.org/wiki/Semi-colon_value_separator#Escaping_with_.27.3B.3B.27
> 
> It might not be used by that much developers, but they can find it in
> Wiki if they want to care for their data 
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
 ___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Removing name_1 and alt_name_1 from Wiki

[Hakuch]

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.


0x3CBE432B.asc
Description: application/pgp-keys
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Removing name_1 and alt_name_1 from Wiki

[Martin Koppenhoefer]

sent from a phone

> Am 19.01.2016 um 20:02 schrieb Colin Smale :
> 
> Tags and values are for machine processing, not for direct human consumption;


are you sure? Why are they human readable then, using actual words? Wouldn't it 
be more efficient to use binary code?

Empty values are not valid for keys, it means the key will be removed, at least 
this is common understanding and what editors do, although I couldn't find it 
in the API docs: http://wiki.openstreetmap.org/wiki/API_v0.6#Tags


cheers,
Martin 
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Removing name_1 and alt_name_1 from Wiki

[Gerd Petermann]

Colin Smale wrote
> 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? 

That is new to me. My understanding of a double pipe is that described here:
http://wiki.openstreetmap.org/wiki/Proposed_features/lanes_General_Extension#Default_values
which indicates that a double pipe means one or two default values,
depending on the position.
At the end of the value, it means two default values.

Gerd



--
View this message in context: 
http://gis.19327.n5.nabble.com/Removing-name-1-and-alt-name-1-from-Wiki-tp5864465p5865207.html
Sent from the Tagging mailing list archive at Nabble.com.

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Removing name_1 and alt_name_1 from Wiki

[Colin Smale]

I meant that there is a value missing "between the pipes", which at a
slightly higher semantic level can mean "use the default". A definition
which varies according to position doesn't feel well-formed to me.

//colin 

On 2016-01-20 08:10, Gerd Petermann wrote:

> Colin Smale wrote 
> 
>> 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?
> 
> That is new to me. My understanding of a double pipe is that described here:
> http://wiki.openstreetmap.org/wiki/Proposed_features/lanes_General_Extension#Default_values
> which indicates that a double pipe means one or two default values,
> depending on the position.
> At the end of the value, it means two default values.
> 
> Gerd
> 
> --
> View this message in context: 
> http://gis.19327.n5.nabble.com/Removing-name-1-and-alt-name-1-from-Wiki-tp5864465p5865207.html
> Sent from the Tagging mailing list archive at Nabble.com.
> 
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
 ___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Removing name_1 and alt_name_1 from Wiki

[Colin Smale]

Yes I'm sure... Notice I put the word "direct" in there. No "end user"
of the data will use the data directly, there is always a presentation
layer in the middle, which formats up numbers and dates, converts units,
localises key words, etc etc. That's where the "semicolon syntax" and
the "pipe syntax" will get resolved into something palatable to humans.

I agree about the completely empty values like "key=". If the "semicolon
syntax" defines a "list of values", shouldn't stuff remove an empty
value from the list (i.e. replace ;; with ;) and then remove the whole
tag if the list is empty? 

--colin 

On 2016-01-20 00:17, Martin Koppenhoefer wrote:

> sent from a phone
> 
>> Am 19.01.2016 um 20:02 schrieb Colin Smale :
>> 
>> Tags and values are for machine processing, not for direct human consumption;
> 
> are you sure? Why are they human readable then, using actual words? Wouldn't 
> it be more efficient to use binary code?
> 
> Empty values are not valid for keys, it means the key will be removed, at 
> least this is common understanding and what editors do, although I couldn't 
> find it in the API docs: http://wiki.openstreetmap.org/wiki/API_v0.6#Tags
> 
> cheers,
> Martin 
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
 ___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Removing name_1 and alt_name_1 from Wiki

[Gerd Petermann]

I don't think that the meaning really depends on the position. My understanding 
is that the

complete value (e.g. "80||" ) is parsed by splitting it into separate strings 
at each pipe symbol.

Result: three strings: "80" , "",""

The value "|80|" also gives three strings: "","80",""

Another point is that an empty value means "use the default", which can

only make sense in special cases  like this.


Gerd


Von: Colin Smale <colin.sm...@xs4all.nl>
Gesendet: Mittwoch, 20. Januar 2016 08:23
An: Tag discussion, strategy and related tools
Betreff: Re: [Tagging] Removing name_1 and alt_name_1 from Wiki


I meant that there is a value missing "between the pipes", which at a slightly 
higher semantic level can mean "use the default". A definition which varies 
according to position doesn't feel well-formed to me.



//colin

On 2016-01-20 08:10, Gerd Petermann wrote:

Colin Smale wrote
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?

That is new to me. My understanding of a double pipe is that described here:
http://wiki.openstreetmap.org/wiki/Proposed_features/lanes_General_Extension#Default_values
Proposed features/lanes General Extension - OpenStreetMap 
Wiki<http://wiki.openstreetmap.org/wiki/Proposed_features/lanes_General_Extension#Default_values>
wiki.openstreetmap.org
A simple, straightforward extension of existing tags to specify properties not 
only for a way as whole but for the lanes of the way instead. Based on this 
general ...


which indicates that a double pipe means one or two default values,
depending on the position.
At the end of the value, it means two default values.

Gerd



--
View this message in context: 
http://gis.19327.n5.nabble.com/Removing-name-1-and-alt-name-1-from-Wiki-tp5864465p5865207.html
Sent from the Tagging mailing list archive at Nabble.com.

___
Tagging mailing list
Tagging@openstreetmap.org<mailto:Tagging@openstreetmap.org>
https://lists.openstreetmap.org/listinfo/tagging
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Removing name_1 and alt_name_1 from Wiki

[moltonel 3x Combo]

On 9 January 2016 at 18:50, Hakuch  wrote:
> I propose, to remove the tagging of name_1 and alt_name_1 from the wiki.

I disagree.

> **better use diverse name-tags**

Diverse name tags are a good thing when there is some semantic
difference between names, but often enough there's no semantic
differences between various alternatives and we need to put a list of
values for the same tag. The question of wether to use semicolons or
tag suffixes is independant from that.

> **semicolons instead of _1 suffixes**
>
> Their only advantage is
> the better legibility for human eyes, thats a reason why some people may
> favour them over the semicolon. But for mechanical computation, it is
> easier to regex the semicolon than crawling through all possible
> existing suffixed tags.

Actually to my human eyes, both semicolons and suffixes are equally
ugly (but pragmatic). It's for processing that suffixes are supperior:
* Spliting by semicolons (no regexp needed :p) is easy but naive,
because semicolons are sometimes part of the actual value.
* One workaround is to use some kind of escape character, but this is
an impementation/spec minefield that we'll never get right.
* Another is to maintain a whitelist of tags that can be split by
semicolon, but it's extra work and everybody'll have a different list.
* Tag suffixes on the other hand can be implemented easily, for all
tags without distinction, and do not suffer from false-positives.
* If a consumer forgot to implement multivalue names, he'll have
incorrect data in the semicolon case and incomplete data in the suffix
case. Incomplete is usually better than incorrect, but it does depend
on the usecase.

> Furthermore the semicolon is already established
> and has been accepted for such special cases with multiple values.

So is the suffix, so this isn't a useful argument.


> **iD-Editor problem**
>
> unfortunately, the iD-editor is creating such prefixed tags and is
> training newbies to use them as a good tagging practice. When you use
> the raw-tag-editor and tries to add an already existing tag, iD does not
> throw any error or information but adds the tag with a suffixed number
> like _1 or higher.

That does sound like a pretty bad behavior.

> It suggests to the unexperienced mapper, that this is a usable method to
> add multiple values,

It is :)

> although this suffixing is only made to prevent the
> user of deleting data.
> We still couldn't convince the developer, that this suffixing method
> leads new mappers to bad practice
> (https://github.com/openstreetmap/iD/issues/2896).

I'm not a fan of the developer's decision here. Always avoiding
warnings complicates UI design a lot. Not sure what to propose to them
instead, I'm not an iD user and whatever I suggest probably would feel
odd in an iD context.

That said, it is an iD UI issue, not really on topic ? But if you
insist in using this example in the semicolon vs suffix debate, it's
an argument for keeping suffixes, because suffix-aware consumers will
be able to make some sense of a name_1 accidentally created by iD.

> **how the name_1 and alt_name_1 came to the wiki-heaven**
>
> But actually, my intention was to propose the removing or marking of
> name_1 and alt_name_1 tags in the wiki (the iD problem should be
> discussed in a new topic). Inititally, the alt_name_1 tag has been added
> by a Nominatim developer in Nov'14. The origin for this decision can be
> found in this discussion on talk
> (https://www.mail-archive.com/talk%40openstreetmap.org/msg50648.html)
> that took place in Sept'14.
>
> There, a member of the HOT team described a problem, that their manual
> massedit caused the tags alt_name:2 and alt_name_2. Now he wants to have
> a mechanical edit to change all alt_name:2 to alt_name_2, preferably
> worldwide. That also caused a readable discussion about the sense of
> suffixed tags. But already before starting that discussion, the author
> asked the nominatim team for adding the alt_name_x tags
> to the nominatim search. And the Nominatim developer did so and
> consequently added it two month later to the wiki.
> Today there are over 5500 alt_name_1 tags. But only a few of them
> outside of the mentioned HOT-area in western africa. Nearly half of
> them, are NOT combinated with alt_name!
>
> The tag name_1 was not proposed in any way, this one has only been added
> in Aug'15 because it exists in the database. By comment "Document
> de-facto name_N variant". That is true, currently there are about
> 800.000 tags with name_1. But when you look on the taginfo map, or the
> combinations, you can see that almost each of them results from the
> Tiger-Import (https://taginfo.openstreetmap.org/keys/name_1#map,
> https://taginfo.openstreetmap.org/keys/name_1#combinations). That
> tagging-scheme should not be proposed in the wiki for using.

So name_1 is a de-facto standard. So what ? The scheme should be
evaluated on its own merit and current usage (which is *not* just
TIGER 

Re: [Tagging] Removing name_1 and alt_name_1 from Wiki

[Marc Zoutendijk]

> Op 9 jan. 2016, om 19:50 heeft Hakuch  het volgende 
> geschreven:
> 
> I propose, to remove the tagging of name_1 and alt_name_1 from the wiki.

I agree.

Marc.



___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Removing name_1 and alt_name_1 from Wiki

[Martin Koppenhoefer]

sent from a phone

> Am 09.01.2016 um 19:50 schrieb Hakuch :
> 
> I propose, to remove the tagging of name_1 and alt_name_1 from the wiki.


I agree, also with the change of iD to stop making indexed tags like this.

cheers 
Martin 

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

[Tagging] Removing name_1 and alt_name_1 from Wiki

[Hakuch]

I propose, to remove the tagging of name_1 and alt_name_1 from the wiki.
Most mappers reject tagging with _x suffixes and it makes no sense to
have them in the wiki as a scheme for good mapping.

[I also started a discussion in the wiki:
http://wiki.openstreetmap.org/wiki/Talk:Names#Removing_Tags_name_1_and_alt_name_1_from_wiki]

**better use diverse name-tags**

Mappers should be motivated to use semantic more rich name-tags like
loc_name, old_name, short_name and so on. If theere is a name that does
not fit in this scheme, alt_name can be used. If there are multiple
names that does not fit, alt_name can be used with semicolons.

**semicolons instead of _1 suffixes**

Semicolons for multiple values have already been established even though
some mappers don't like them. Precise tags should always be preferred
(like the mentioned diverse name-tags), but we should
not use _1 suffixed tags instead of semicolons. Their only advantage is
the better legibility for human eyes, thats a reason why some people may
favour them over the semicolon. But for mechanical computation, it is
easier to regex the semicolon than crawling through all possible
existing suffixed tags. Furthermore the semicolon is already established
and has been accepted for such special cases with multiple values.

**iD-Editor problem**

unfortunately, the iD-editor is creating such prefixed tags and is
training newbies to use them as a good tagging practice. When you use
the raw-tag-editor and tries to add an already existing tag, iD does not
throw any error or information but adds the tag with a suffixed number
like _1 or higher.
It suggests to the unexperienced mapper, that this is a usable method to
add multiple values, although this suffixing is only made to prevent the
user of deleting data.
We still couldn't convince the developer, that this suffixing method
leads new mappers to bad practice
(https://github.com/openstreetmap/iD/issues/2896).

**how the name_1 and alt_name_1 came to the wiki-heaven**

But actually, my intention was to propose the removing or marking of
name_1 and alt_name_1 tags in the wiki (the iD problem should be
discussed in a new topic). Inititally, the alt_name_1 tag has been added
by a Nominatim developer in Nov'14. The origin for this decision can be
found in this discussion on talk
(https://www.mail-archive.com/talk%40openstreetmap.org/msg50648.html)
that took place in Sept'14.

There, a member of the HOT team described a problem, that their manual
massedit caused the tags alt_name:2 and alt_name_2. Now he wants to have
a mechanical edit to change all alt_name:2 to alt_name_2, preferably
worldwide. That also caused a readable discussion about the sense of
suffixed tags. But already before starting that discussion, the author
asked the nominatim team for adding the alt_name_x tags
to the nominatim search. And the Nominatim developer did so and
consequently added it two month later to the wiki.
Today there are over 5500 alt_name_1 tags. But only a few of them
outside of the mentioned HOT-area in western africa. Nearly half of
them, are NOT combinated with alt_name!

The tag name_1 was not proposed in any way, this one has only been added
in Aug'15 because it exists in the database. By comment "Document
de-facto name_N variant". That is true, currently there are about
800.000 tags with name_1. But when you look on the taginfo map, or the
combinations, you can see that almost each of them results from the
Tiger-Import (https://taginfo.openstreetmap.org/keys/name_1#map,
https://taginfo.openstreetmap.org/keys/name_1#combinations). That
tagging-scheme should not be proposed in the wiki for using.

It even makes less sense to have alt_name_1 AND name_1 because they do
not differ in any way.

**tl;dr**

I propose removing the name_1 and alt_name_1 from the Map Features or
rather marking them and to explain that and why they should not be used.
And after that we can convince iD Editor to stop creating them
automatically :)

german readers can also take a look into this discussion in forum:
http://forum.openstreetmap.org/viewtopic.php?id=53223


0x3CBE432B.asc
Description: application/pgp-keys
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Removing name_1 and alt_name_1 from Wiki

[Jo]

I agree too, FWIW.

Polyglot

2016-01-09 23:25 GMT+01:00 Dave Swarthout :

>
> On Sun, Jan 10, 2016 at 4:32 AM, Marc Zoutendijk 
> wrote:
>
>> > I propose, to remove the tagging of name_1 and alt_name_1 from the wiki.
>>
>
> Agree
>
>
> --
> Dave Swarthout
> Homer, Alaska
> Chiang Mai, Thailand
> Travel Blog at http://dswarthout.blogspot.com
>
> 
>  This
> email has been sent from a virus-free computer protected by Avast.
> www.avast.com
> 
> <#-688897245_DDB4FAA8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging