Removing name_1 and alt_name_1 from Wiki

classic Classic list List threaded Threaded
44 messages Options
123
Reply | Threaded
Open this post in threaded view
|

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

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging

0x3CBE432B.asc (3K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Removing name_1 and alt_name_1 from Wiki

dieterdreist


sent from a phone

> Am 09.01.2016 um 19:50 schrieb Hakuch <[hidden email]>:
>
> 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
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Removing name_1 and alt_name_1 from Wiki

Marc Zoutendijk
In reply to this post by Hakuch

> Op 9 jan. 2016, om 19:50 heeft Hakuch <[hidden email]> 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
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Removing name_1 and alt_name_1 from Wiki

AlaskaDave

On Sun, Jan 10, 2016 at 4:32 AM, Marc Zoutendijk <[hidden email]> 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

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Removing name_1 and alt_name_1 from Wiki

Jo-2
I agree too, FWIW.

Polyglot

2016-01-09 23:25 GMT+01:00 Dave Swarthout <[hidden email]>:

On Sun, Jan 10, 2016 at 4:32 AM, Marc Zoutendijk <[hidden email]> 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

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging



_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Removing name_1 and alt_name_1 from Wiki - RFC

Hakuch
It might not be neccessary because there weren't any negative comments
about that all the time, but I started a formal proposal in the wiki. I
shortened the RFC duration to one week, so voting will start on 16th.

http://wiki.openstreetmap.org/wiki/Proposed_features/Remove_suffixed_name-tags_from_wiki

please comment there, thx


On 10.01.2016 00:16, Jo wrote:

> I agree too, FWIW.
>
> Polyglot
>
> 2016-01-09 23:25 GMT+01:00 Dave Swarthout <[hidden email]>:
>
>>
>> On Sun, Jan 10, 2016 at 4:32 AM, Marc Zoutendijk <[hidden email]>
>> 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
>>
>> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail> This
>> email has been sent from a virus-free computer protected by Avast.
>> www.avast.com
>> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
>> <#-688897245_DDB4FAA8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>>
>> _______________________________________________
>> Tagging mailing list
>> [hidden email]
>> https://lists.openstreetmap.org/listinfo/tagging
>>
>>
>
>
>
> _______________________________________________
> Tagging mailing list
> [hidden email]
> https://lists.openstreetmap.org/listinfo/tagging
>

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging

0x3CBE432B.asc (3K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Removing name_1 and alt_name_1 from Wiki

moltonel 3x Combo
In reply to this post by Hakuch
On 9 January 2016 at 18:50, Hakuch <[hidden email]> 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 even though that import has a lot of it), not on its genesis. At
least you can trace the suffix scheme's origin; the use of the
semicolon certainly pre-existed any wiki voting/approval process (?).


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

Agree on that point. If you've got more than two names, alt_name_1 is awfull.



> **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.

Again, disagree.

> And after that we can convince iD Editor to stop creating them
> automatically :)

Probably agree, I'd need to use iD to really form an opinion :p

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Removing name_1 and alt_name_1 from Wiki

Hakuch
hi

On 10.01.2016 22:29, moltonel 3x Combo wrote:
> * Spliting by semicolons (no regexp needed :p) is easy but naive,
> because semicolons are sometimes part of the actual value.
that should be only in a very little cases, do you know any? Anyway, it
is possible to happen, yes, but if we start to introduce complete
tagging schemes for all the mini-minor-might-be-existing cases we soon
will have much more chaos in our data.

I agree, that the semicolon wasn't the best solution for diverting
multiple values, but it happened to be so.

> * 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.
consumers (better: developers) should be the ones who use the data
correctly, especially in such easy cases. We should not motivate them to
work sloddy and its even easier to identify bad data than missing data.

>> 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.
it is not really established. It was added to the wiki by bad reasons,
it is not used by people who are not trained by iD to do so. It is just
a fragment of imports that seems to use this method to show "ok, heres
another name, I make a bad tagging to force you change it" not a good
reason for having this in the Wiki


--
BITTE BESORG DIR EINE NEUE EMAILADRESSE!

Wenn du mit mir über eine Gmail Adresse schreibst, landet alles was wir
kommunizieren bei Google und wird dort gespeichert, analysiert,
bewertet, verwendet.
Wenn dir das egal ist ok, deine Sache. Aber ich will da nicht mit
reingezogen werden.
Also schon aus Respekt deinen Kommunikationspartner-innen gegenüber, hol
dir bitte eine Adresse von Posteo.de, Mailbox.org oder Riseup.net

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging

0x3CBE432B.asc (3K) Download Attachment
0x3CBE432B.asc (3K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Removing name_1 and alt_name_1 from Wiki

Hakuch
In reply to this post by moltonel 3x Combo
just mentioning that there is another discussion thread for this topic
on the list:

http://gis.19327.n5.nabble.com/Please-don-t-think-name-1-tags-are-errors-td5864875.html

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

> On 9 January 2016 at 18:50, Hakuch <[hidden email]> 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 even though that import has a lot of it), not on its genesis. At
> least you can trace the suffix scheme's origin; the use of the
> semicolon certainly pre-existed any wiki voting/approval process (?).
>
>
>> It even makes less sense to have alt_name_1 AND name_1 because they do
>> not differ in any way.
>
> Agree on that point. If you've got more than two names, alt_name_1 is awfull.
>
>
>
>> **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.
>
> Again, disagree.
>
>> And after that we can convince iD Editor to stop creating them
>> automatically :)
>
> Probably agree, I'd need to use iD to really form an opinion :p
>
--
BITTE BESORG DIR EINE NEUE EMAILADRESSE!

Wenn du mit mir über eine Gmail Adresse schreibst, landet alles was wir
kommunizieren bei Google und wird dort gespeichert, analysiert,
bewertet, verwendet.
Wenn dir das egal ist ok, deine Sache. Aber ich will da nicht mit
reingezogen werden.
Also schon aus Respekt deinen Kommunikationspartner-innen gegenüber, hol
dir bitte eine Adresse von Posteo.de, Mailbox.org oder Riseup.net

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging

0x3CBE432B.asc (3K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Removing name_1 and alt_name_1 from Wiki

Hakuch
In reply to this post by moltonel 3x Combo
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
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging

0x3CBE432B.asc (3K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: 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
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Removing name_1 and alt_name_1 from Wiki

Andy Townsend
In reply to this post by Hakuch
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
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Removing name_1 and alt_name_1 from Wiki

Hakuch
In reply to this post by Colin Smale
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
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging

0x3CBE432B.asc (3K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: 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
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: 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.
>  
>

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging

0x3CBE432B.asc (3K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Removing name_1 and alt_name_1 from Wiki

Hakuch
In reply to this post by Andy Townsend
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

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging

0x3CBE432B.asc (3K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Removing name_1 and alt_name_1 from Wiki

dieterdreist
In reply to this post by Colin Smale


sent from a phone

> Am 19.01.2016 um 20:02 schrieb Colin Smale <[hidden email]>:
>
> 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
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Removing name_1 and alt_name_1 from Wiki

Gerd Petermann
In reply to this post by Colin Smale
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
Reply | Threaded
Open this post in threaded view
|

Re: 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
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Removing name_1 and alt_name_1 from Wiki

Colin Smale
In reply to this post by dieterdreist

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 <[hidden email]>:

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
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
123