Re: [Tagging] Proposal about suffixed tags has been approved

[moltonel 3x Combo]

On 03/03/2016, Martin Koppenhoefer <dieterdre...@gmail.com> wrote:
>> Am 03.03.2016 um 03:57 schrieb moltonel 3x Combo <molto...@gmail.com>:
>>
>> The fact that we don't know wether the extra name is an old_name or a
>> loc_name or something else is independant of how the extra name was
>> taged. The information is equally lacking from name_1, name=x;y, and
>> alt_name. Do not shoot the name_1 messenger when it is just telling
>> you that the mapper didn't have nuanced information about which
>> context the extra name fits best in.
>
> didn't you say before, name_n was for equally valid names?

Yes. That's what I said here as well. Same is true for alt_name and name=x;y.

> How do you
> distinguish names that are confirmed to be equally valid and bearing the
> same semantics from names where they are possibly not but the mapper didn't
> know?

You can't just by looking at the osm data, you'd need to
survey/research the question. It's possible that further research
might show that the extra name should go in (for example) old_name,
but that's not a garantee.

I think that Hakuch was refering to some TIGER imports which used
name_1 too lightly (I even believe that sometimes the difference
between name variants is just that one is abbreviated and the other
isn't). Most people agree that this was a bad import.

But Hackuch is (correct me if I'm wrong) using this bad import as an
example to say that semicolons should be used instead of suffixes.
That's reasoning is flawed, because if the import had used semicolons
instead of suffixes, it'd have the exact same problem (plus the
previously mentioned problems of using semicolons for names).

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

Re: [Tagging] Proposal about suffixed tags has been approved

[moltonel 3x Combo]

On 25/02/2016, Hakuch <hak...@posteo.de> wrote:
>>> That is absoulutely no justification for your edits without asking the
>>> the list.
>>
>> I honestly believe I acted in the same way that you did (no accusation
>> of wrong-doing).
>
> sorry but that is is really far from truth. Before I did the changes,
> there was more than a month full of drafting a Proposal -> starting a
> RFC -> Voting. In the end of that process, we had a decision by voting
> 38:10.
>
> You cant compare this with you actions yesterday. You just ignored the
> proposal process and reverted the result just because you don't like the
> outcome.

The moral ground I'm standing on is that I was correcting the
erroneous conclusion that there was enough consensus to accept the
proposal. I know this looks like I'm pushing my singular viewpoint
against the community's, but there are a few points which should make
the current "official conclusion" feel uncomfortable, whatever your
personal preference on semicolon vs suffixes is.

In OSM we have to walk a difficult path between making the data
consumable without too many headaches and describing a complicated
world. Mappers have a lot of freedom and different solutions emerge.

For some choices, like jewellery vs jewelry, there's no value in
keeping both solutions so an expeditious decision is warranted.

For other choices like suffix vs semicolons, the list of pros and cons
prevents a clear winner from emerging. Luckily, both solutions can
coexist and there is no need to choose a winner. Actually, if a winner
is to be found, the community as a whole is certainly a better judge
than the tiny fraction of the community that we ([tagging] readers and
wiki editors) represent. Given both options, the community should
naturally (if slowly) converge to the supperior solution if it exists.
In a case like this, we'd need very strong arguments to say that a
specific popular solution should not be used...

...But those strong arguments were clearly lacking:
* Of the [tagging] participants who tackled the "semicolon vs suffix"
question directly (so not counting peripheral topics like the iD bug,
blanks and orderings, or comparison to lanes/opening_hours), many
(dare I say most ? in any case more than 20%) participants leaned
towards using the key rather than the value to encode multiple values.
* Various issues with semicolons that some consider show-stopers (like
litteral semicolons, or the 255 chars limit) were either ignored or
brushed aside as not relevant.
* The current usage statistics (hinting at the greater community's
opinion) that name_N is 10 to 20 time more popular than semicolons
[1], but this was again brushed aside (including the principle of
documenting current usage).



[1]: Using today's taginfo db dump:
sqlite> select key,count(*),sum(count_all) from tags where key =
'name_1' or key='name_2' or (value like '%;%' and (key='name' or
key='alt_name')) group by 1;
name_1|250686|810490
name_2|29521|65868
name|15211|29136
alt_name|7975|10897
You can argue about the flaws of this simplistic query, but this won't
change the general result.



On 25/02/2016, Hakuch <hak...@posteo.de> wrote:
> On 25.02.2016 01:37, moltonel 3x Combo wrote:
>> Firstly, there is a difference between documenting current practices
>> and advising for one practice over another. I did my best to remain
>> factual and to document but not advise, even if I secretly wish that
>> we stoped using multiple schemes and converged on one that had less
>> flaws than the others.
>>
>> Secondly, while writing the MV page I did my best to summarize all the
>> opinions of the recent threads (even some I didn't fully agree with),
>> and my first email today was a way to ask people to join the
>> discussion.
>
> thats a problem of the wiki, that it is for doumenting as well as for
> advising. Thats a big problem for all unexperienced mappers and results
> in unsteady tagging. Thats why I ask you, to notice on the page that
> there are different positions. You even should link to the proposal
> because its also a document of the situation.

That's fair enough, any mention of the suffix and semicolon schemes
(for the name key as well as other keys) should also link to the
discussions, including the various proposals. I originally removed the
link to the "remove sufixed name-tags" proposal because it is IMHO
wrongly-accepted and because I was linking to the more factual "MV
tagging" page, but I'm happy to add links to the proposals and
discussions, as long as it is balanced.


>> If your proposal mentioned converting existing data as well as
>> removing its mentions from the wiki, it would have been more coherent.
>> Maybe I'm missreading things ?
>
> It is hard enough to do small steps :) Right, it wou

Re: [Tagging] Proposal about suffixed tags has been approved

[moltonel 3x Combo]

On 25/02/2016, Hakuch <hak...@posteo.de> wrote:
> On 24.02.2016 23:40, moltonel 3x Combo wrote:
>> Just like you 1) marked the proposal as approved 2) enacted the
>> proposal 3) emailed the list all in one session a few days ago, I
>> edited the wiki and emailed the list in one session today.
>
> sorry, but what is wrong that I did? The voting was over (to be honest,
> it was already some days over) and the decision was made. marking it as
> approved, setting the status of the proposal and emailing the list is
> just post-voting-cleanup and the typical procedure that SHALL be done.

What you did is not wrong, editing the wiki and emailing the list at
the same time is the pragmatic thing to do. Even taking the vote
counts to approve the proposal is not wrong, most would even say it's
right :p

> That is absoulutely no justification for your edits without asking the
> the list.

I honestly believe I acted in the same way that you did (no accusation
of wrong-doing). I couldn't have just emailed the list without editing
the wiki (or vice-versa), I drafted the email and the wiki changes
together, and only together do they form a full argument.

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

Re: [Tagging] Proposal about suffixed tags has been approved

[moltonel 3x Combo]

On 24/02/2016, Hakuch <hak...@posteo.de> wrote:
> On 24.02.2016 22:57, moltonel 3x Combo wrote:
>> The opinions were varied, but there was clear support in keeping the
>> name_N documentation, both for the basic principle of documenting
>> current practices, and because some contributors believe it is a
>> better way of tagging multiple-value fields. If anything, name_1 needs
>> to be kept because it is sometimes technically needed, even if it
>> isn't the prefered option. On top of that, this isn't an "either-or"
>> case where if we choose one scheme we need to deprecate the others.
>
> I really do not want to go again in this discussion, when you start this
> with just editing the wiki pages without asking on the list. But I also
> would like to know what means "technically needed"

When you have more than two names with the same semantic value, name_N
is the only way to tag this. alt_name can only contain one name,
semicolons are not a viable option for names.


>> I've reverted the deletion.
>
> that was against the decision of the proposal where everyone was able to
> take part.

And my reading of the situation is that there wasn't enough consensus
for the proposal, despite what the vote counts say. I suppose this is
the crux of this "appeal", and I discuss it further at the end of this
mail.


> At least, you should have pointed out your decision before
> you did the changes.

As far as I can tell, you're just as "guilty" of editing the wiki and
emailing the list at the same time (modulo typing speed) as I am. Your
approval of the proposal looked very strange to me, and had you
mentioned it on the list before enacting it on the wiki I would have
immediately commented on it. But such delays quickly get impractical,
so the pragmatic decision (yours and mine) is to do both at the same
time.


>>, which makes as little sense as deleting
>> the Semicolon page would.
>
> you can start a proposal if you want to delete the page

You missread me, I was comparing the deletion of the name_N scheme to
the deletion of the semicolon scheme. They both serve the same
purpose, but neither should get deprecated. Same goes for alt_name,
for that matter.


>> To make things a bit more constructive, I've
>> also created a page documenting MV tagging in general (trying to
>> gather all the points mentioned during last month's threads, sticking
>> to current practices, not advocating for one scheme over another) and
>> made other tweaks to the name pages. Feel free to discuss here or on
>> the wiki.
>
> As I told you in the message, I like the idea to have a special MV Page.
> But you shouldn't advise something there that has been discouraged by
> the proposal (you even removed the link to the proposal on the name
> page!) And the whole MV thing is still in discussion, you should inform
> about this on the page and call in the people to join the discussion
> with their ideas.

Firstly, there is a difference between documenting current practices
and advising for one practice over another. I did my best to remain
factual and to document but not advise, even if I secretly wish that
we stoped using multiple schemes and converged on one that had less
flaws than the others.

Secondly, while writing the MV page I did my best to summarize all the
opinions of the recent threads (even some I didn't fully agree with),
and my first email today was a way to ask people to join the
discussion.


>> As an aside, using a wiki proposal just to decide what should go in
>> the wiki, rather than what should go in the db, is a strange thing.
>
> the wiki is the entrance to the database, better it should be. Mappers
> who care for consistency check the wiki before they start just tagging
> as they want to (and what looks nice on an arbitrary map).

We agree on that. But it seemed to me that there was a disconnect
between the wiki edit proposal and your acceptance of existing data :

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

If your proposal mentioned converting existing data as well as
removing its mentions from the wiki, it would have been more coherent.
Maybe I'm missreading things ?


>> By
>> the time you reduced the scope of your proposal from deprecating
>> name_N to merely un-documenting it, when it became clear (?) that
>> name_N had an important role to play, the proposal was IMHO dead on
>> arrival.
>
> I dont understand this. Do you mean the problem of the title "remove
> suffixed tags" ? Just to mention here again, the title was bad, yes. But
> I never changed the content of the proposal. Just people who didn't read
> 

Re: [Tagging] Proposal about suffixed tags has been approved

[moltonel 3x Combo]

On 24/02/2016, Matthijs Melissen  wrote:
> Moltonel, could you please refrain from making changes that go against
> the community wishes? I know you have good intentions (and you might
> even be right), but the community has discussed this topic in depth
> and decided on the outcome by vote, and you are making changes that
> disrespect the voting outcome. It's you who is starting the edit war,
> not Hakuch (and I'm saying this as a neutral outside observer).

The possibility that I missjuged the community's opinion is one reason
it took me so long to reply. It took me a while to be confident enough
that the proposal was approved wrongly, and I've tried to state my
arguments clearly.

An edit war is not just about multiple reverts, it is also about the
speed of these reverts and the lack of discussion.

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

Re: [Tagging] Proposal about suffixed tags has been approved

[moltonel 3x Combo]

On 24/02/2016, Hakuch  wrote:
> hey, I didnt want to start an edit war, but I just didnt see that you
> wrote on the tagging list.
>
> i will write more later, I even informed you just by message, but the
> proposal was very clear, you were not allowed to just change the pages.
> You even should have informed the list BEFORE you did it. Now please do
> not put it in my direction, that i want to start a edit war

Fair enough, the timing was a bit short to read my email on the list.
I guess the short reaction time (especially compared to my multi-day
pondering) was what made it feel like an edit war to me, sorry.

Just like you 1) marked the proposal as approved 2) enacted the
proposal 3) emailed the list all in one session a few days ago, I
edited the wiki and emailed the list in one session today.

> this is just a quick mail

Looking forward to the long one.

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

Re: [Tagging] Proposal about suffixed tags has been approved

[moltonel 3x Combo]

http://wiki.openstreetmap.org/w/index.php?title=Template:Map_Features:name=next=1275945

Same here, reverted without discussion. I think those changes are
ill-advised and intend to restore name_N in the wiki but again: I
don't want to go in an edit war and would really like you to discuss
things.

On 24/02/2016, moltonel 3x Combo <molto...@gmail.com> wrote:
> http://wiki.openstreetmap.org/w/index.php?title=Key:name=next=1275952
>
> Hakuch, please do not start an edit war. I took the time to avoid a
> knee-jerk "revert this edit" reaction, and so should you. I've
> explained  how the approval of the proposal was IMHO a poor reading of
> the discussion on [Tagging], and why name_N cannot simply be
> deprecated.
>

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

Re: [Tagging] Proposal about suffixed tags has been approved

[moltonel 3x Combo]

http://wiki.openstreetmap.org/w/index.php?title=Key:name=next=1275952

Hakuch, please do not start an edit war. I took the time to avoid a
knee-jerk "revert this edit" reaction, and so should you. I've
explained  how the approval of the proposal was IMHO a poor reading of
the discussion on [Tagging], and why name_N cannot simply be
deprecated.

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

Re: [Tagging] Proposal about suffixed tags has been approved

[moltonel 3x Combo]

On 12/02/2016, Hakuch  wrote:
> https://wiki.openstreetmap.org/wiki/Proposed_features/Remove_suffixed_name-tags_from_wiki
>
> It was approved with 38 votes for, 10 votes against and 1 abstention.
>
> Approved due to >74% approval (79.167%). Wikipages has been changed
> https://wiki.openstreetmap.org/w/index.php?title=Key%3Aname=revision=1271795=1267803
> Key:name
>
> https://wiki.openstreetmap.org/w/index.php?title=Template%3AMap_Features%3Aname=revision=1271784=1204516
> Template
>
> thanks for participation

Sorry for the late reply, I was quite busy and it took me a while to
bring a constructive reaction, after letting go of my initial
annoyance.


There was not enough consensus to justify accepting and enacting the
proposal. Looking just at the vote counts but ignoring the discussions
around it makes little sense.

The opinions were varied, but there was clear support in keeping the
name_N documentation, both for the basic principle of documenting
current practices, and because some contributors believe it is a
better way of tagging multiple-value fields. If anything, name_1 needs
to be kept because it is sometimes technically needed, even if it
isn't the prefered option. On top of that, this isn't an "either-or"
case where if we choose one scheme we need to deprecate the others.

I've reverted the deletion, which makes as little sense as deleting
the Semicolon page would. To make things a bit more constructive, I've
also created a page documenting MV tagging in general (trying to
gather all the points mentioned during last month's threads, sticking
to current practices, not advocating for one scheme over another) and
made other tweaks to the name pages. Feel free to discuss here or on
the wiki.


As an aside, using a wiki proposal just to decide what should go in
the wiki, rather than what should go in the db, is a strange thing. By
the time you reduced the scope of your proposal from deprecating
name_N to merely un-documenting it, when it became clear (?) that
name_N had an important role to play, the proposal was IMHO dead on
arrival. I nearly didn't bother casting my vote against it.

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

Re: [Tagging] Discussion about Multivalued Keys

[moltonel 3x Combo]

On 27/01/2016, Colin Smale <colin.sm...@xs4all.nl> wrote:
> On 2016-01-27 22:54, moltonel 3x Combo wrote:
>> Concerning foo_1 vs foo[1] vs foo:1, I this the last one can be safely
>> thrown to the idea bin (despite being used by seamarks) because ':'
>> clashes with namespacing, which is firmly established. foo[1] looks
>> better than foo_1 to my programer eyes, but is has no technical
>> advantage (?) and I suspect that most people will find foo_1 more
>> pleasing, it's also one less character to type, less annoying to parse
>> with a regexp, and much more established in taginfo.
>
> Would you feel any different about your foo:1 example if it were written
> foo%1, avoiding any clash with namespacing?

I don't really care wether it's _1, %1 or [1], except that the first
one is already popular. But

> By the way, I am trying to maintain the distinction between the "suffix
> notation" where the index value is actually the final part of the key
> segment, and the "hierarchical/seamark" notation where the index value
> is a separate segment of the full key string.

As far as I'm aware, the "suffix notation" has always meant "suffix
within a namespace", not "suffix at the very end of the key". We
already have a significant number of "*name_1:*" keys in the db, for
example.

> Maybe we should look at some technical use cases, like "in a navigation
> map creator, find all the categories for a POI" or "find the per-lane
> destination (and destination:ref and turn-lane stuff) information so I
> can construct a simulated road sign". Some will be done with a
> programming language, others may naturally tend towards SQL.
>
>> Concerning using '.' as a separator instead of ':', I don; t see what
>> it brings us, beside familiarity to users of some programing languages
>> (but change language and sudenly ':' becomes more familiar).
>
> Sometimes using a familiar character (such as the ":" here) with new
> semantics can lead to confusion. There comes a point when it is better
> to make a clean break so there is no confusion. Whether it is a colon or
> a dot or some other character is "detail" really.

Yes, but in the "lane[1].destination=Paris" example, you use '.' for
something (namespacing) that we've always happily used ':' before. I
don't see a need for the change, my best guess was "it looks more
familiar to users of some programming languages" but IMHO it's not
worth the confusion it'll bring to most people.

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

Re: [Tagging] Discussion about Multivalued Keys

[moltonel 3x Combo]

Thanks Colin, this proposal makes some good points. Some comments :

For completeness, you should mention the possibility of an API-level
implementation[1]. Even if this'll be met with a "patches welcome" and
if we need a pragmatic solution in the meantime, supporting MV at the
API level has some impressive pros & cons.

You barely broach the subject of how MV and namespaces combine. For
example if an object has multiple refs with sources, it should be
clear wether an MV tag corresponds to "multiple sources for all the
refs" or to "source for the 2nd ref". In suffix syntax, this could be
distriinguished by "ref_1=x ref_2=y source_1:ref=a source_2:ref=b" vs
"ref_1=x ref_2=y source:ref_1=a source:ref_2=b", even though this is
becoming hairy.

Concerning ordered vs unordered, I don't think we should define it at
this level. Wether a key is treated as ordered or not will depend both
on the key and the consumer. For example searching for a POI will
always treat the MV as unordered, but displaying it is likely to treat
it as ordered (either by displaying an ordered list, or only
displaying the first value). Conversely, a carefully ordered list
might get interpreted as unordered (Say I want to promote POIs with a
particular tag, and always disply that one first if present. Or I've
loaded the values in a language structure that doesn't conserve
order).

A syntax to specify wether a list is ordered or not will typically be
ignored by consumers, and will only make the spec messyer. IMHO,
producers should write every tag as if it was ordered, and keep in
mind that consumers will do their own thing anyway.


[1]:http://wiki.openstreetmap.org/wiki/API_v0.7#Multiple_Tags

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

Re: [Tagging] Discussion about Multivalued Keys

[moltonel 3x Combo]

On 27/01/2016, Marc Gemis  wrote:
> The main problem is that the lane tagging is established tagging with
> several 10.000's of mapped ways. Do you really want to change that ?
> It will take years before they are all converted to whatever new
> syntax we come up with. Not to mention data consumers (e.g. OsmAnd)
> that have to be adapted to support both syntaxes.

While it may not make sense to convert existing lane tags to whatever
gets decided here, the lane attribute is a good usecase to test an MV
scheme against. If an MV scheme can't handle a known important
usecase, we'll have a hard time recomending it as *the* MV scheme.

FWIW, I think the suffix scheme maps to the :lanes namespace in a very
logical and straightforward way. It's just... Much more verbose than
the currently established scheme. Even if editors started supporting
this kind of structured data in a nice way, it'd be a hard sell
compared to typing a handfull of ';' and '|'. This is certainly an
important reason why semicolon-MV remains popular despite its
technical issues compared to suffix_MV. Mappers do not (all) think
like programers.

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

Re: [Tagging] Discussion about Multivalued Keys

[moltonel 3x Combo]

On 27/01/2016, Colin Smale  wrote:
> One way, using a "subscript syntax" with a "data structure" construct
> using a "." as a separator":
> lane[1].destination=Paris
> lane[2].destination[1]=Rome
> lane[2].destination[2]=Milan
> lane[3].destination[1]=Berlin
> lane[3].destination[2]=Munich
>
> Alternatively, using a "suffix syntax", something like you suggest
> lane_1:destination=Paris
> lane_2:destination_1=Rome
> lane_2:destination_2=Milan
> etc.
>
> Thirdly, using the "seamark" construction:
> lane:1:destination:1=Paris
> lane:2:destination:1=Rome
> lane:2:destination:2=Milan
> etc.


Concerning foo_1 vs foo[1] vs foo:1, I this the last one can be safely
thrown to the idea bin (despite being used by seamarks) because ':'
clashes with namespacing, which is firmly established. foo[1] looks
better than foo_1 to my programer eyes, but is has no technical
advantage (?) and I suspect that most people will find foo_1 more
pleasing, it's also one less character to type, less annoying to parse
with a regexp, and much more established in taginfo.

Concerning using '.' as a separator instead of ':', I don; t see what
it brings us, beside familiarity to users of some programing languages
(but change language and sudenly ':' becomes more familiar).

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

Re: [Tagging] Feature Proposal - Voting - (Remove name_1 and alt_name_1 from wiki)

[moltonel 3x Combo]

tOn 26/01/2016, Mateusz Konieczny  wrote:
> In my experience name, name:en, old_name, alt_name, alt_name:ru etc etc
> etc were always sufficient. An example where multivalue names are
> truly necessary would be interesting.

Andy has already given some good answers and I've rambled for too long
on the subject, but since you ask again I'll dig up
http://www.openstreetmap.org/relation/5257865 again, which cannot be
satisfyingly tagged with foo_name variations. Its name_1 and name_2
tags have absolutely no semantic difference, so puting them in
foo_name and bar_name would be wrong. In fact even its name tag is
semantically at the same level as the other two.

The local knowledge comes from my in-laws, who lived there for as far
as they can trace back.

You might want to brush this example off as too rare to bother about,
but I've stumbled uppon places with many names before. I used to
agonize over the decision of what to put in which foo_name tag (alt
and loc being the most likely candidates), with the result that I was
assigning semantic value ("this name is only used locally, this one is
a bit broader") when there was actually none. I'm sure I'm not the
only one in this situation. We've trained mappers to always prefer
foo_name but this is often wrong.

We need multi-valued keys to accurately describe the world. Until the
OSM data model supports that natively, we make do with either the
suffix or the semicolon hack (plus some niche and one-off solutions).
They are not great but they are necessary, embrace them. And while
you're at it, recognize the cases where semicolons are problematic and
embrace suffied tags.

___
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 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

[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] Please don't think name_1 tags are errors.

[moltonel 3x Combo]

On 17/01/2016, Hakuch  wrote:
> for me the use of alt_name_1 is more logical than the name_1, because
> alt_name is the meaning of name_1! So, if you have a second name and you
> dont know where to put it (loc_name, old_name...) you can use alt_name.
> And if you have a third name you SHOULD use alt_name:name2;name3 but in
> a bad manor you can use alt_name_1=name2, alt_name_2=name3. But name_1
> doesn't make any sense.

Well "alt_foo" and "foo_1" both mean "here's another value for foo".
So "alt_foo_1" expand to something like "here's another another value
for foo". "alt_" and "_1" are two ways of saying "another", and
juxtaposing two "adverbs" with the same meaning is superfluous and
grammatically akward. To use another analogy, it's like talking about
the "TCP protocol" or the "MIT institude of technology".

And because "_1" naturally naturally brings "_2" and so on (while
"alt_" doesn't naturally bring any followup), it makes sense to give
up on "alt_" altogether. It doesn't bring any benefit compared to "_1"
(but "loc_", "old_" and others are still ok because they carry a
different meaning).

Concerning your suggestion to use "name=n1 alt_name=n2;n3", let me
rethorically wonder why you didn't suggest "name=n1;n2;n3" ? I expect
it is because the risk of semicolons in the "name" tag catching some
consumers unaware. Well, that risk of catching consumers unaware is
pretty much the same with semicolons in "name" as in "alt_name".

So when are semicolons a reasonable way to specify multiple values ?
IMHO whenever the values are fixed or sanitizable (unlike for example
"name", which the mapper has no control over), and empty fields don't
make sense. There are actually quite few of them that wouldn't benefit
from a more elaborate mapping or tagging scheme. "Sport" and "ref" are
likely fine, but I'd rather leave the fun of determining which keys
are semicolon-safe as an exercise to future generations of mappers and
consumers. Myself, I'd rather use foo_1 everywhere and stop worrying.


Obligatory xkcd quote: https://xkcd.com/327/

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

[Tagging] Please don't think name_1 tags are errors.

[moltonel 3x Combo]

Hi, I've just reverted http://www.openstreetmap.org/changeset/36573638
where the mapper thought that name_1 tags were typos. That user is on
a key typo fixing spree, which is a good thing in itself, even if
mistakes happen.

But I wonder if some people know about the iD editor behavior below,
and assume that a name_1 tag must have been created that way ? If so,
consider this email as a reminder that the _N suffix is used on
purpose by many people. As always, contact the mapper if unsure.

On 09/01/2016, Hakuch  wrote:
> **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).

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

Re: [Tagging] Please don't think name_1 tags are errors.

[moltonel 3x Combo]

On 15/01/2016, Kieron Thwaites <kieron.thwai...@gmail.com> wrote:
> I completely endorse the removal of any and all *_N tags.

If so, you've got a serious amount of work comming up just to figure
how to say the same thing using different tags. Semicolons and various
namespaced schemes sometimes do the trick, but outright banning *_N
for the sake of (what ?) would cause a lot of headaches.


On 15/01/2016, Martin Koppenhoefer <dieterdre...@gmail.com> wrote:
> 2016-01-15 15:26 GMT+01:00 moltonel 3x Combo <molto...@gmail.com>:
> also shop_1 tags are created that way. I wonder why you would want to add
> these tags on purpose. E.g. for shops the values indicate a type of shop. A
> bookstore that also sells music cds? Still a bookstore IMHO. A music store
> that also sells some books? Still a music store. Now, a store that sells
> both, music cds and books, and maybe dvds and posters, maybe still a
> bookstore, maybe a new category like a media store, not sure, would have to
> decide on the particular case. In a majority of cases you still can decide
> on one of the types and that it is. A green grocer that also sells
> toothpaste, detergents, toys and cheese? That likely not a green grocer any
> more, that's either a convenience store or a supermarket.
> What I want to say: a shop that is 2 shops in one might well be neither of
> these shop types, but a new typology.
> In other cases, there is a well defined shop/restaurant/bar/kiosk/... which
> also offers some odd service or product you might find in some but not all
> of this kind of business, and which you consider so interesting that you
> want to map the presence of it. Examples might be tobacco/cigarettes,
> icecream, particular soft drinks (club_mate comes to mind [1]), public
> transport tickets, fresh milk, etc.

Yes, "shop=foo shop_1=bar" is not great. In the same way that
"shop=foo;bar" is not great. I'm all for either finding a new fitting
value or for tagging the main value plus a subtag, or for using two
objects.

But often mappers are not knowledgable enough or do not have the time
to fuss about this, and instead "simply want to express that this is a
deli and an optician".


> My solution for this is sells:foo=yes(/no/etc.)
> Obviously we wouldn't want people to tag the whole assortment of a
> supermarket like this, but due to the amount of work the risk is low.
> People will likely just tag the things they are particularly interested in,
> and that are not automatically thought of being available generally. So far
> the list is small ;-) [2]

Yes, ns:foo=boolean is a good alternate scheme, when you can use it.

> For names, the solution should be to use well defined name key variations,
> there's a whole lot of them [3], and introducing just another infinite
> amount of indexed ones seems completely unnecessary.

The problem is that all those name key variations carry semantic
meaning. A loc_name isn't the same thing as an alt_name which isn't
the same thing as an old_name. You can't shuffle all your names into
random foo_name keys, it has to make sense. And as soon as you've got
more than one name, you've got a problem. Which is solved very nicely
by _N.

To get back to my http://www.openstreetmap.org/relation/5257865
example, I've got 3 names to tag. One of them distinguishes itself by
also appearing on an out-of-copyright map, the other two are at the
exact same level with each other and, as far as I'm concerned, pretty
much at the same level as the first one. I can't fit them into "loc"
or "old" or "whatever" categories, to the best of my knowledge they
are just "other names". Which is solved very nicely by putting them in
name_1 and name_2.


Having multiple values for one tag is awkward in OSM, so we always try
to find clever ways around it. Sometimes that clever trick is the
right thing to do, sometimes we really just need a way to tag multiple
values. Semicolons and _N are two ways to do that, each with their
pros and cons (I don't think it likely or desirable to deprecate one
for the other). They are sometimes usefull, please leave them be an
accept them as another tool in your mapper's toolbox.



Changing the topic a little bit, I'd like to comment on alt_name vs
name_1 va alt_name_1. To me name_1 and alt_name are exact synonyms, I
don't see a semantic difference (as opposed to loc_name for example).
Therefore, if you've only got two names to tag you can use either. But
once you've got at least three you'll need to use either alt_name_N or
name_N. I find the concept of alt_name_N silly and would rather use
name_N, but I've seen some people disagree, For what it's worth,
alt_name_N is much less frequent in the db than name_N, but Nominatim
supports only alt_name_N. Any opinions on that issue (other than
"remove all *_N" :p) ?

___
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] amenity=bicycle_repair_station

[moltonel 3x Combo]

On 10/11/2015, Martin Koppenhoefer  wrote:
>> What ambiguity of repair_station would be cleared by tool_stand or
>> tool_station ?
>
> it is the word "station" that could be interpreted as a shop / service
> station. "stand" does not bear this risk (for me). "tool_station" would be
> similarly ambiguous.

I don't think the possible confusion with a service station is an
issue: plenty of them are unmaned. Or are you worried about the
assumption that one is free and not the other ? Also: to me a "stand"
sounds much more likely to be maned than a "station".

We're not going to get a unanimous opinion on wether
stand/station/repair/tool matches the maned/unmaned/free/commercial
concepts,  the link is too tenous. To me so far there's no clear
benefit in those alternate tags, to be weighted against the clear
downside of migrating away from an existing tag.

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

Re: [Tagging] amenity=bicycle_repair_station

[moltonel 3x Combo]

On 10/11/2015, Andrew Guertin  wrote:
> On 11/09/2015 09:41 PM, Bryce Nesbitt wrote:
>> amenity=bicycle_repair_station has a problem: it's attracting lots of
>> active tagging
>> of shops offering bicycle repair.  For example:
>> http://www.openstreetmap.org/node/3772809894
>> and http://www.openstreetmap.org/way/337421757
>>
>> That was not the intent.  amenity=bicycle_repair_station was meant for
>> unattended
>> tool stands, often outdoors, often 24/7, generally public.
>>
>> I'm seeking support for a mechanical edit to a new tag name.
>> There are known automated clients of this tag, and I am in contact with
>> both.
>
> I'd support a name change.

I don't see how a name change will help.
amenity=bicycle_repair_station and service:bycicle:repair=yes are
rather self-explanatory and well defined as far as I can tell.
Abandoning a tag because some large contributor misuses it isn't going
to improve the state of the database. Contact the ill-advised
contributors to make them understand the issue and fix objects which
got the wrong tag, but don't move a well-established tag to a new name
just to make cleaning up easyer.

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

Re: [Tagging] amenity=bicycle_repair_station

[moltonel 3x Combo]

On 10/11/2015, Martin Koppenhoefer  wrote:
> 2015-11-10 9:38 GMT+01:00 Mateusz Konieczny :
>
>> I like amenity=bicycle_tool_stand,
>
> +1, "repair_station" is ambigous / can easily be misunderstood. Even though
> "amenity=self_serve_bicycle_tool_stand" looks like an overkill on first
> sight, it is even more verbose and less likely to be misunderstood.

What ambiguity of repair_station would be cleared by tool_stand or
tool_station ? I can see the point of puting self-serve in there
somewhere, but even then I feel it is a very weak reason to rename an
established tag.

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

Re: [Tagging] Proposal: Sunset ref=* on ways in favor of relations

[moltonel 3x Combo]

On 08/11/2015, Dave Swarthout  wrote:
> In that section the author, sk53, says, "Creating a whole set of boundaries
> encompassing one country and part of another is not a light undertaking on
> OSM. It is fiddly work, and involves manipulating objects with many
> dependencies. In practice I find it somewhat reminiscent of software
> migration projects: mainly mundane but you need to keep your wits about
> you.
>
> Contrary to what some believe, none of the OSM editors can prevent damage
> to other objects in this process. Mapping boundaries on this scale
> inevitably involves relations, and relations are not semantically clean
> objects at the level of the OSM data model."

While I agree that relations can break and can be tricky to edit, I
find it tiring to see this argument repeatedly used against the use of
relations for this or that usecase.

The stuff we map is becoming more complex and, in increasingly many
cases, relations are the best available tool for the job. Why complain
about the difficulty of editin boundary,multipolygons,or routes
relations when maping the same features without relations would be
even worse ?

There are some grey areas: when do I switch from a shared-nodes closed
way to a multipolygon (or from ref tag on ways to a relation), but
we're lucky enough to have options. Let each maper decide wich
technique makes the best use of his (an furture contributors's) time.

Sure, It'd be great to have proper Area (and maybe even Multiline)
elements in the OSM data model to replace hacky uses of the Relation
element. Or even "just" have the API check uploaded relations for
geometrical correctness. But don't wait for that to start using
relations.

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

Re: [Tagging] Feature Proposal - Voting - Motorway link no default oneway

[moltonel 3x Combo]

On 29/10/2015, Joachim  wrote:
> I invite you to vote on the proposal "Motorway link no default
> oneway". The following is proposed:
>
> Strongly recommend explicit tagging of oneway=* on highway=motorway_link.

No need for a proposal and a vote to do that. Just go ahead and recommend it.

> Define that highway=motorway_link without tagged oneway=* has no
> implied oneway=yes

That's the case already, no change here. Only motorways are rather
universally expected to be oneway.

> and also the standard default of oneway=no does not
> apply. The oneway=* status of such a way would be undefined.

That's useless. You're not writing a spec to generate code in a
language that has a concept of nulls, you're writing some
documentation that might, maybe, be read by consumers and
implementors. And if all you can tell them is "it's your call" you
might as well not waste their time and not tell them anything.

> * For rendering purposes ways with undefined oneway should be
> displayed like the default, i.e. without oneway arrows.
> * For routing purposes no recommendation for ways with undefined
> oneway is made. A provider should decide on it's own considering the
> documentation history and current data.

That contradicts the "no implied oneway=yes" statement and is
inconsistent with the recomendation for renderers. Just leave the
status quo (most routers assume oneway=no) in peace please. I've given
examples before explaining why a mistaken oneway=yes assumption is
worse than a mistaken oneway=no assumption where routing is concerned.

> * In map editors undefined oneway should be displayed as tagging
> error. Corresponding tickets will be opened for JOSM/iD/Potlatch.

Again, no need for a proposal to do that. Just go ahead and open
feature requests if they don't exist already.

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

Re: [Tagging] Handle with care

[moltonel 3x Combo]

On 27/09/2015, André Pirard  wrote:
> But I'm afraid that the correct namespace order is name:edit_warning=*.
> edit_warning is a qualifier of name and not the opposite.
> It is the edit warning of (for) name and not the name of the edit warning.
> It's just like the order of the words in an English phrase.

I don't see the warning tag as a qualifier of the name, but as
metadata describing the name. As for the "English sentence" argument,
it's very easy and natural to phrase it with either 'name' first or
'waring' first.

> Adding a qualifier makes the word more specific, "with warning" rather
> than plain.
> If you speak of the building antenna type, it's building:antenna:4G=yes
> The left side of the road is road:left and not left:road.

Real-world objects have a left and a right, an antenna that is 4G or
not. They do not have a "warning: location is very precise" or
"warning: sat imagery is outdated". The warnings are not giving a more
specific description of the object, they exist outside the object.

> And BTW, source:maxspeed is a mistake, there is no such thing as the
> speed of a source
> The source of the maxspeed should be maxspeed:source.
> And its date should be maxspeed:source:date and not
> source:date:maxspeed or source:maxspeed:date or date:maxspeed:source..

Thank you for providing an example of a tag that is 'meta' just like
'warning' and correctly lives in its own namespace. It's always
source:foo, not foo:source.


So we've looked at the semantic, linguistic, and current practice
arguments. But here comes the technical one, based on a golden rule of
osm tag-crafting, "New tags should not break consumers that do not
know about the tag" :

Without knowing about these "warning" tags, I'll encounter them as I
read namespaces left to right. name:warning ? Huh, not sure what it
means, but the name tag is so complicated that I just add all of them
as alternative names anyway. phone:warning ? Ohhh I know about the
phone:foo scheme, it means that this phone "number" is the one to use
for warning purposes. etc...If you don't put warning in its own
top-level namespace, it's going to show up in a lot of places where it
shouldn't.

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

Re: [Tagging] Handle with care

[moltonel 3x Combo]

On 27/09/2015, Marc Gemis  wrote:
> My fear is that some overzealous mappers will start adding those tags to
> all objects in their neighborhood, just to "protect' their area and scare
> away newbies.
>
> Since we suppose that all data is mean to be correct and everybody makes
> edits to improve the map, I do not see a good reason for such a tag.

To be honest I'm not a fan of the idea either, but it's comming back
so regularly that I think we should treat it in some way.

Bryan proved me wrong by saying that he (as an iD developer) would
support some form of warning, and he makes the very interesting point
that values should be standardised (this begs the question of what to
do when an unknown values comes up, but hey).

Standard names offer the opportunity to guide which type of warnings
are good to have and not oversteping. And can link to help text that
can try its best to explain rather than scare away. Picking up on
Bryan's examples:
* outdated_imagery should be self-explanatory, I've used the note tag
for that a few times
* border_dispute can link to the many ressources explaining how to
handle these nicely
* current_event is... the same as outdated_imagery ? unless a precise
date is given ?
* authoritative_data can suggest mapers to alert the authority that
their data is crap ;)
* i_know_the_place_better_than_you is notably absent

Bryan also distinguished 'warning' (which just pop up a message but
lets the user continue) from 'restriction' (which don't let the user
edit until he removes the restriction tag). I think that 'restriction'
goes too far, an editor warning should be enough for all cases (as
long as it is visible enough).

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

Re: [Tagging] Delete not marked walking routes?

[moltonel 3x Combo]

On 20/09/2015, Martin Koppenhoefer  wrote:
> what about a map that shows the route and is placed on the ground, eg at the
> start of the route (let's say the map is in the public domain)?

To me that's a (partially) waymarked trail and is absolutely fine.

> Or signposted QR codes? This has recently become quite popular here, but
> without a smartphone (technical equipment) you can't verify the information.

I'm assuming you're talking about a lone QRcode somewhere (at the
trailhead ?) and not a QRcode printed beside each waymarks or designed
to be itself a recognizable waymark (in which case the fact that there
is a QRcode is secondary).

Otherwise, it depends. Is it really a QRcode standing there without
human-readable (and osm-worthy) context ? What prompted you to scan
it, potentially following a malware link ? Does the QR encode a url or
an actual gpx/geojson/etc file ? IMHO a standalone QRcode pointing to
a url is not mapworthy. Especially in today's world where it is so
easy to print one and stick it somewhere, it has no more authority
than a spray-painted graffiti.

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

Re: [Tagging] Semi-detached houses: undocumented iD preset

[moltonel 3x Combo]

On 18/09/2015, Frederik Ramm  wrote:
> I'd say the same applies to houses. Whether something is one half of a
> double house, or semi-detached, or terraced, or free-standing - isn't
> that something that I can automatically determine by looking at the
> nearby mapped buildings?

+1 I've always tagged those as "house". I try my best to avoid
building=yes and disntinguish all building types, but the various
detached variants I don't bother with. I'm much more likely to tag
roof:shape from imagery and building:levels from surveying.

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

Re: [Tagging] New proposal: Obligatory tagging of oneway on motorway_link

[moltonel 3x Combo]

On 11/09/2015, Mateusz Konieczny  wrote:
> On Fri, 11 Sep 2015 12:41:36 +
> moltonel  wrote:
>
>> Consumers (routers, renderers, whatever) will not be swayed by a wiki
>> page. They might look at stats and decide themselves what the absence
>> of a oneway tag means, but a wiki proposal is never going to
>> influence that decision.
>
> Documentation on wiki is one of main sources during development of map
> style.

It is indeed an important source for some consumers, but for something
like this stats are much more important than the wiki. You can go
ahead and work on that proposal, I just don't think it's an efficient
way to improve the situation.

And since you're talking about map styles, this proposal explicitly
says that motoway_link without a oneway tag should render the same as
oneway=no. In other words, this proposal doesn't change the status quo
for map styles, it doesn't concern them.

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

Re: [Tagging] Drafting proposal: use oneway=reversible or create tag?

[moltonel 3x Combo]

On 07/09/2015, David Marchal  wrote:
> I'm drafting a proposal concerning some waterways whose flow regularly
> changes direction, which happens near some sinkholes named estavelles, which
> drain or feed water according to the aquifer level. I would consequently
> propose a way to map it, but it should be consistent with current tags, so I
> wondered: should I propose using
> oneway=reversible, as it already exists and can be used on other ways than
> roads, according to the wiki, but would in this case be used to indicate
> that something is _not_ oneway, oranother tag, such as twoway=yes, which
> could be clearer in this context of a way you would expect to be oneway, but
> at the risk of duplicating the use of oneway=no?

Don't use oneway=*: it relates to the direction that vehicles (in this
case boats) are allowed to take, not to the waterflow.

I don't know of an existing tag. I've searched for 'flow' and
'up/downstream' in taginfo, but the only thing I found came from
imports and had very bad values from an OSM POV. Unless somebody has a
better Idea, I suggest creating a tag.
waterway:flow=forwards/backwards come to my mind, but that's an
endlessly bikeshedable topic.

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

Re: [Tagging] Proposed mechanical edit: surface=soil to surface=dirt (history (authors of changesets))

[moltonel 3x Combo]

On 02/09/2015, Mateusz Konieczny  wrote:
> On Tue, 01 Sep 2015 23:55:14 +0200
> "André Pirard"  wrote:
>> http://www.openstreetmap.org/api/0.6/node/3157502486/history
>>
>> will return the complete list (history) of authors, changesets and
>> dates for a given element.
>
> Yes, this would work (some parsing still would be needed). Unfortunately
> according to http://wiki.openstreetmap.org/wiki/API_usage_policy it is
> not OK to use API for that purpose.

I actually think using the API for that purpose is perfectly within
the usage policy:
* The ultimate goal is to edit OSM, by knowing who introduced a tag
and contacting him
* Contributors already do this all the time from within the editor,
only one object at a time
* Typical usage (on an ad-hoc basis and < 1000 objects) should be low
enough. While it can potentially be heavy enough to break the usage
policy, this is a separate issue of how the tool is used rather than
what the tool does.

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

Re: [Tagging] [OSM-talk] Proposed mechanical edit: surface=soil to surface=dirt

[moltonel 3x Combo]

On 02/09/2015, Friedrich Volkmann <b...@volki.at> wrote:
> On 01.09.2015 10:13, moltonel 3x Combo wrote:
>> But as a user of surface=soil, could you tell me what difference you
>> see between soil and earth (from an osm POV) ? To me, those two are
>> actual osm synonyms, but 'earth' is documented and 55x more popular.
>
> See my other message (Message-ID: <55e55c3e.8010...@volki.at>). Earth is
> documented, but with a wrong descripion, which is worse than no
> documentation at all. I prefer a tag with an obvious meaning over one which
> is ambiguous, unless there's already lots of applications relying on the
> ambiguous tag.

Well that's the point, it's not obvious at all, otherwise I wouldn't
have asked. Or rather, the obvious (to me) definition of both earth
and soil lead me to believe that they are synonyms for the OSM
usecase.

If the definition is wrong, discuss and correct it. If there's really
a nuance between soil and earth/ground/dirt that make soil usefull as
a distinct value, then document it.

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

Re: [Tagging] [OSM-talk] Proposed mechanical edit: surface=soil to surface=dirt

[moltonel 3x Combo]

On 01/09/2015, Friedrich Volkmann  wrote:
> Soil is not dirt. That's why I have used surface=soil myself, and I
> will revert any automated edit of such kind.

I agree that soil and dirt are different, and that the mechanical edit
should not proceed as originaly planned.

But as a user of surface=soil, could you tell me what difference you
see between soil and earth (from an osm POV) ? To me, those two are
actual osm synonyms, but 'earth' is documented and 55x more popular.

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

Re: [Tagging] [OSM-talk] Proposed mechanical edit: surface=soil to surface=dirt

[moltonel 3x Combo]

On 31/08/2015, Christoph Hormann  wrote:
> I would be careful here - 'dirt' is essentially a very vague term which
> probably originates from the concept of 'dirt roads' here.  'Soil' in
> the other hand is fairly precise, see
>
> https://en.wikipedia.org/wiki/Soil
>
> Only parts of the earth surface are actually covered by soil so if a way
> is correctly tagged with surface=soil (and i don't know if that is the
> case for the 400 cases you mention) this is something specific and
> potentially useful and should not be degraded by turning it into
> something as vague as surface=dirt.
>
> In general i think surface=ground is the most sensible tag for tagging
> ways that are just established somewhere without notible construction
> work when you can't be more specific - it implies that the way surface
> is essentially the ground there in its natural state.  surface=dirt
> OTOH can mean anything from the remaining tracks of a car driving
> across a wayless area to a solidly built gravel road.

Agreed.

Between soil, dirt, ground, earth, and mud, dirt is the worst defined
of the lot, and I would hesitate to use it for anything.

If you do want to consolidate tags, "earth" is a much better synonym
of "soil" and you should probably use that instead.

"Ground" is earth+rocks+sometimes_vegetation. "mud" is earth with a
lot of water and clay.

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

Re: [Tagging] Proposed mechanical edit: surface=soil to surface=dirt

[moltonel 3x Combo]

On 31/08/2015, Mateusz Konieczny  wrote:
> Is there some method to automate finding who introduced tags? Doing it
> manually would not be worth the effort. On the other hand - running
> script to detect users (and/or relevant changesets) may be a good idea.

curl -s 
'http://overpass-api.de/api/interpreter?data=%5Bout%3Ajson%5D%5Btimeout%3A25%5D%3B%0A%28%0A%20%20node%5B%22surface%22%3D%22soil%22%5D%3B%0A%20%20way%5B%22surface%22%3D%22soil%22%5D%3B%0A%20%20relation%5B%22surface%22%3D%22soil%22%5D%3B%0A%29%3B%0Aout%20meta%3B'
| grep user | sort| uniq -c

or

http://overpass-turbo.eu/?w=%22surface%22%3D%22soil%22+global (and add
'meta' to the output to extract the user/changeset)

These have the usual drawback that they only return who last touched
the object, not who introduced a particular tag. It gets more
complicated to do things exactly right, but this is a good starting
point.

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

Re: [Tagging] Trolltags

[moltonel 3x Combo]

On 31/08/2015, Mateusz Konieczny  wrote:
> Good
> luck with filtering out proposed=yes, abandoned=yes, vacant=yes,
> demolished=yes, construction=yes, empty=yes, ruins=yes, parsing
> start_date and end_date etc etc.

Case in point: have a look at
https://github.com/gravitystorm/openstreetmap-carto/blob/master/openstreetmap-carto.style
which lists the keys that the "default" rendering can use. The only
one available from that list is construction=*. Changing anything in
that file has been on hold for a long time, as it comes with a high
deployment cost.

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

Re: [Tagging] works_as_highway=primary

[moltonel 3x Combo]

On 29/07/2015, Marc Gemis marc.ge...@gmail.com wrote:
 On Tue, Jul 28, 2015 at 5:29 PM, moltonel 3x Combo molto...@gmail.com
 wrote:

 A router won't care about classification differences between far away
 places like Germany to Ethiopia. They just care about taking the best
 road in the area, and as long as OSM is locally consistent, this
 works. Even if a trunk turns into a primary for no physical reason and


 Seems like I didn't make my point correctly.
 I was trying to ask for global consistency so the router can use the same
 default weights for street types, everywhere in the world.  Something like
 'prefer primary roads over secondary' roads  to travel large distances.

Routers can already use 'prefer primary to secondary' worldwide.
Nowhere in the OSM world is secondary defined as better than primary.
In any given area. a car router can confidently prefer 'primary'.

What's true is that 'primary is X times better than secondary' will
have different X values from one place to the next. But the
differences between section of a given road can already be more
important than the average difference between primary and secondary
(for example an Irish secondary´s maxspeed can go from 60 to 100, but
a primary isn´t generally 1.6x better than a secondary).

Consider also the case of motorways : in all countries I've driven in
they are very clearly defined and have legal specificities. OSM
couldn't afford to mistake a motoway with something else. Yet the
difference between a motorway and the next best thing is bigger in
Germany than in Ireland.

TD;DR: It's naive to think that routers can make a good decision using
the highway tag alone. Harmonising highway tag worldwide would be of
little use, and it would break local expectations. A locally coherent
highway tag is preferable, and if you want more precise routing add
the other tags.

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

Re: [Tagging] works_as_highway=primary

[moltonel 3x Combo]

On 28/07/2015, Martin Koppenhoefer dieterdre...@gmail.com wrote:
 Am 28.07.2015 um 11:02 schrieb Pavel Zbytovský zbytov...@gmail.com:

 1) technically the small secondary roads part works as primary road
 network. So we would suggest a tag similar to works_as_highway=primary. Do
 you think its ok? Any suggestions?


 from what you have written it seems to me that these are tagging errors: if
 a road works as primary it should get the primary tag in osm.

 Country specific deviations that result from following different criteria
 (like road maintenance class / entity, or physical criteria, etc.) should be
 repaired (map those properties differently and not in the highway tag) and
 the highway tag should be used like it is elsewhere.

Sorry but no, too simplistic. A lot of local OSM communities follow
the official national road classification where possible. For example
in Ireland, any ref=Nxx road with xx51 is highway=trunk, and switches
to highway=primary when xx50.

http://wiki.openstreetmap.org/wiki/Ireland/Roads

This makes sense because it is expected by any Irish driver and map
user. While it does result in some road classification changes without
any physical changes, this just reflects the administrative reality.


 OSM is a global dataset and following everywhere the same criteria to
 determine the highway tag is important for a smooth usage of the data across
 borders.

That ideal doesn't match the practical reality. highway=primary has a
very different definition between Ethiopia and Germany, by necessity.
A global uniform standard for highway=* would be pretty unusable. But
we do use a collection of local standards, so we have local
consistency (hopefully at least at the national level), which is the
most important thing.

That said, there are plenty of tags other than highway that are
usefull and objective: maxspeed, lanes, width, traffic lights, speed
bunps, and even surface (but that one is getting subjective again). Go
map them, in that rough order of priority. They are used by routing
software and solve the OP's question for routing. If you want to use
those tags for rendering, talk to your map style developer (you'd need
to do that anyway to make use of works_as_primary).

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

Re: [Tagging] works_as_highway=primary

[moltonel 3x Combo]

On 28/07/2015, Pavel Zbytovský zbytov...@gmail.com wrote:
 Since nobody objected much, i would probably go with
 works_as_highway=primary - i think it reflects the state of reality, so its
 useful to be added in OSM dataset.

FWIW, I'm not a big fan of this, because it is just a variation of
tagging for the renderer, with no support by current rendering styles
to begin with. Routers should already have no problem with the data.

That said, I don't see a better tag that your style could use to
decide displaying that road (from your 1st example) earlyer. The
maxspeed is just 50 and there are only two lanes, that seems like weak
arguments for force early display.

What I'm going to say may sound beside the point, but I suggest you
simply ignore this as a non-problem. Leave the data and rendering
as-is :
* If the user asks for routing, the secondary road will be used properly.
* If the user is looking at a low-zoom rendering, he's probably only
interested in a rough idea anyway like I'll get near Praha using this
primary road, and can probably reach city center from there.
* If the user zooms in, he'll see the secondary road.

See ? No problem to be solved :)

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

Re: [Tagging] works_as_highway=primary

[moltonel 3x Combo]

On 28/07/2015, Marc Gemis marc.ge...@gmail.com wrote:
 On Tue, Jul 28, 2015 at 4:14 PM, moltonel 3x Combo molto...@gmail.com
 wrote:

 That ideal doesn't match the practical reality. highway=primary has a
 very different definition between Ethiopia and Germany, by necessity.

 While they can be very different, a router should still be able to prefer a
 primary road to navigate you from city A to B and avoid secondary or
 tertiary roads. Of course in Germany it might be a smooth asphalted road
 and in another country a sand road, but that doesn't matter.

 Are the current router properly routing over the Irish roads ? Can they
 properly deal with the classification changes ? Or are those changes
 ignored because the speed limits are properly tagged.

I was arguing against a worldwide unified classification. What you're
worried about is only local classification :

A router won't care about classification differences between far away
places like Germany to Ethiopia. They just care about taking the best
road in the area, and as long as OSM is locally consistent, this
works. Even if a trunk turns into a primary for no physical reason and
without additional helpfull tags like maxspeed, a router likely won't
be thrown off and avoid the primary, because there's nothing better
than the primary_which_used_to_be_trunk around.

One routing error that came up recently is a trunk with a lower than
typical maxspeed, and a trunk_link without a maxspeed tag. The router
used its default idea of maxspeed for that link, and tried to use it
as a shortcut. The router could have been smarter, but the data should
have been more complete too, adding a naxspeed tag.

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

Re: [Tagging] Disputed area

[moltonel 3x Combo]

On 20/07/2015, Greg Troxel g...@ir.bbn.com wrote:

 Warin 61sundow...@gmail.com writes:

 On 20/07/2015 1:08 AM, Greg Troxel wrote:
 So perhaps a relation that carries the border tag with two ways as
 members.  The relation would have the boundary tags, and also a disputed
 tag of some sort listing the set of countries involved in the dispute.
 Then each member way has a tag of which country (countries really, but
 only those adjacent) thinks that way is the border.  We could require
 that the ways making up the relation make up a closed area,

 This could get tricky for 3-way or more situations, but it seems
 reasonably straightforward for the described case.

 I'd use the tag

 source= ?

 That does simply state the source of the information... why add another
 tag that does the same thing?

 It's not about the source (which is how you found out a fact).  It's
 which party is asserting something, whcih is part of the fact.

 Also, the point is to be machine parseable.

How about:
* Map each boundary as that boundary's country sees it, allowing
overlaps. So the France boundary relation is according to France's
views, and vice-versa for Italy.
* Create a relation containing the boudary relations as members, with
roles litteraly set to either opinion_a or opinion_b, and the tags
type=dispute, dispute:opinion:fr=a, dispute:opinion:it=b,
dispute:opinion:united_nations=a, dispute:negociations=peacefull (not
suggesting that the UN either sides with France or is the sole
pan-governmental organisation whom OSM should tag the opinion of).
* Setup a QA looking for overlaping boundaries without an acompanying
dispute relation
* Work on renderings to take this into account.

There's no need to add a disputed=yes tag to the boundary relations
themselves, the fact that they're members of a dispute relation is
enough.

While that dispute relation sounds nice to me, it may be a bit naive.
It really needs a review from people familiar with various disputes
and with potential data consumers such as renderers and geocoders. For
example, what if a country has multiple disputes with neighbouring
countries ? Does puting the boundary ways instead of the boundary
relations as members of the dispute relation work as well ?

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

Re: [Tagging] Highway proposed/planned distinction

[moltonel 3x Combo]

On 16/07/2015, jonat...@bigfatfrog67.me jonat...@bigfatfrog67.me wrote:
 I would say it depends if the untouched land is still in its original use or
 not.  If it is then mark it as planned, if it’s cordoned off waiting for the
 construction to get there then I would mark it as under construction.

Agreed. My understanding from johnw's mail was that the other sections
were not even cordoned-off yet. In my experience (Ireland/France),
this is the usual way that road builders do things.

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

Re: [Tagging] Rural Alley?

[moltonel 3x Combo]

On 08/07/2015, johnw jo...@mac.com wrote:
 https://www.google.com/maps/@36.431238,139.246753,3a,78y,233.04h,65.44t/data=!3m6!1e1!3m4!1sqk2OIIDRfkCjb8uqWNbkhw!2e0!7i13312!8i6656!6m1!1e1

To me this (along with the description) is highway=track
tracktype=grade1. You can add surface, lanes, maxspeed, width, etc for
good measure.

The difference between track and service is not about the quality of
the road, but about its intended purpose. Track for agrigulture,
service for built up areas (very simplified). It's the same for all
highway=* values : the purpose and official classification are more
important criterias than the road quality. Which makes the secondary
tags even more usefull.

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

Re: [Tagging] Changes + additions: shop= photo, hobby, model

[moltonel 3x Combo]

On 05/06/2015, Warin 61sundow...@gmail.com wrote:
 shop=hobby No documentation present so added

   * text to suggest a more detailed tag be used.
   * link to the wiki shop= hobby area.

shop=hobby is a terrible tag. Every activity is a hobby to somebody,
so shop=hobby gives no clue as to what the shop sells.

So why document that tag at all ?
* The wiki suggests that hobby relates to art and music, which I'm
willing to bet is not what every users of the tag had in mind.
* There's 204 occurences in taginfo, which is a fairly small threshold
for in use.
* Even if the page starts with a do not use paragraph, it raises the
prominence of the tag, contributing to the tag's popularity instead of
reducing it.

So I suggest deleting that wiki page. And of course, surveying and
retagging all the shop=hobby you come across.

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

Re: [Tagging] SHAPE_Leng, SHAPE_Area, GIS_ACRES

[moltonel 3x Combo]

On 04/06/2015, Jean-Marc Liotier j...@liotier.org wrote:
 Nothing wrong there - in Europe, people have been improving on CORINE
 Land Cover polygons since the dawn of time.

CORINE landuse in Europe is a bit like TIGER highways in USA : great
as an initial map-filler, but requires a *lot* of fixing and tweaking.

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

Re: [Tagging] Deprecating wikipedia Tag

[moltonel 3x Combo]

On 26/05/2015, Martin Koppenhoefer dieterdre...@gmail.com wrote:
 My main concern with wikidata for the moment: it's mostly as fuzzy as
 Wikipedia is - because the objects are not created by humans but conversions
 of articles. Using only wikidata would mean we are sure that wikidata will
 be a success.

Agreed. I initially tought that wikidata was mostly human-curated,
which led me to believe that it could only play catch-up with
wikipedia in terms of content and that wikidata items would not always
be available for OSM tags.

The fact that pedia and data are kept so tightly in sync (one being a
metadata backend for the other) is a mixed blessing. It's nice that
you can always count on a wikipedia item existing if the pedia article
exists, but it adds a lot of noise. The combination of stable ids and
tracking non-stable articles means that a lot of bloat must
accumulate. Seeing that there's 13.9M wikidata items for 4.8M English
wikipedia articles doesn't reasure me (I know it's not all bloat, but
still).

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

Re: [Tagging] Deprecating wikipedia Tag

[moltonel 3x Combo]

On 26/05/2015, Andy Mabbett a...@pigsonthewing.org.uk wrote:
 You don't link to a Wikidata label, you link to a Wikidata item.

QED, you can only use wikidata IDs such as Q936 in OSM tags, which
is much less userfriendly than the wikipedia equivalent. You brought
wikidata labels to the discussion; they're nice but they're irrelevant
for OSM tags.

 Even in the best-case scenario, it
 seems that an OSM wikidata tag can drift off-target following
 reorganisations that are correct from a wikimedia POV but not from an
 OSM POV.

 Example?

 An hypothetical example:

 I was asking for a real example.

Why ? My example illustrates a genuine concern. If it's unfounded (I'd
love it is was), please explain why (I'm still no wikidata expert).
Dismissing because it's not a documented occurence doesn't help. I
used an hypotetical example because finding an actual one is hard. If
it was easy, the problem would go away because contributors would find
and fix them.


 a hotel that includes a restaurant. OSM uses
 two objects from the begining, both linked to the single wikidata
 article that talks about the hotel as a whole.

 OSM should only link the hotel item to the Wikipedia article.

There only one pedia/data article/item at this stage in my example, so
of course OSM links to that. Did you mean linking to wikidata ? This
example is meant to verify how much more failsafe wikidata links are
compared to wikipedia ones, so I'm just looking at the wikidata tags
in osm usecase.


 The restaurant later
 gets spun off as an independent business and get its own wikidata item
 (either a split or a new one), but OSM still links to the hotel as a
 whole wikidata item.

 This is no different to a new Wikipedia article being created.

I thought that wikidata could help by keeping a bridge item that
shows that the hotel and restaurant used to be part of the same item ?


 Does wikidata have some tricks up its sleeve to reliably deal with
 that kind of problem ?

 No. Does a highway system have a trick up its sleeve for when a new
 road is built, that OSM doesn't yet know about?

Please don't be so defensive, I'm actually trying to assert the
advantages of wikidata for osm tags. To me the unfriendly ids are a
big downside of wikidata, so the upsides (stability and localised
version) need to be strong enough to offset that.

From what I've read so far, we want to have both wikipedia and
wikidata tags for each object in OSM. The pedia ones for
mapper/humans, and the data ones for programs/QA. Neither is perfect,
but the combination of both is a bit better.

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

Re: [Tagging] Wiki: Key:level: proposed rewrite

[moltonel 3x Combo]

On 25/05/2015, Michael Reichert naka...@gmx.net wrote:
 I oppose. Numeric level values can be used to display a building plan
 layer by layer where higher floors lay over lower floors. Most software
 which uses level=* at the moment expects that it is a numeric value.

 Example: https://youtu.be/qcB5CP-IkLg?t=17m12s

 If a building has named levels, you can still use numbers at OSM. (It's
 like our usage of layer=*)

+1. There are two distinct needs : enabling software to sort levels
for rendering and navigation  purposes, and the need to show the
textual name that humans expect. The level=* key is currently used
for the fist case (otherwise you'd see a lot more text values in
taginfo).

 If you want that data users get the floor names, why don't you add a
 level:name=* tag, e.g.

Looked tempting at first, but I'm not sure I'm a fan:
 * It's brand new and never used before.
 * level=* tags are currently typically added to POIs inside the
buldings. Keeping level:name in sync on all those nodes seems like an
awful lot of tedious error-prone work.
 * We should be able to have an osm object representing the level
itself, and tag that with a standard name=*.

I won't pretend to be up to date with the various schemas for indoor
mapping, but the type=site site=level relation seems quite
idiomatic, and can be named as usual.

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

Re: [Tagging] Wiki: Key:level: proposed rewrite

[moltonel 3x Combo]

On 25/05/2015, pmailkeey . pmailk...@googlemail.com wrote:
 There are two distinct needs : enabling software to sort levels
 for rendering and navigation  purposes, and the need to show the
 textual name that humans expect. The level=* key is currently used
 for the fist case (otherwise you'd see a lot more text values in
 taginfo).

 Not necessarily as many buildings' floor names are numeric in nature.

Out of 127k uses, the first non-numeric level=* value in taginfo is
unknown (94 uses / 0.07%). Then come story_1 (44 uses), story_2
(32), from -1 to -2 (23), primary (17), secondary (16), blue
(10) and finally UG (6).

I think that if level=* was somewhat regularly used for the *name* of
a floor, we'd see a lot more of Ground floor, Lobby or G. The
idea that 4th floor gets abbreviated to 4 doesn't explain the
values seen in taginfo. The only reason I see is that level=* is not a
name but a synthetic value used for OSM internals, just like leyer=*.

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

Re: [Tagging] Deprecating wikipedia Tag

[moltonel 3x Combo]

On 25/05/2015, p...@trigpoint.me.uk p...@trigpoint.me.uk wrote:
 I think a lot of us mappers  are going to need a lot of convincing,
 wikipedia tags, in common with other osm tags, are human readable.
 When reviewing changes I do not see a number that is meaningless without
 following the link, and even then the wikidata page looks pretty
 meaningless.

Also, a lot of wikipedia articles do not (yet) have a wikidata
counterpart. As OSM is quite a time sink already, I am not going to
start creating wikidata (or even wikipedia) articles when none exist
for an OSM object I'm editing.

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

Re: [Tagging] Wiki: Key:level: proposed rewrite

[moltonel 3x Combo]

On 25/05/2015, pmailkeey . pmailk...@googlemail.com wrote:
 Also knowing the street elevation would give the clue as to which floor was
 'ground level' - as would a highway linking internal routes to external.

You shouldn't focus on trying to determine the ground level, as
there are many many buildings that have no reasonable unique answer to
that. Just like with the layer tag, the important thing is to get the
stacking order right, and coherent with the neaby data. When there's a
clear ground level it's nice mnemotechnic to number it level=0, but
that's optional. Routing and rendering, not labeling.

 Ele would at least tie in with 3D mapping whereas positional info is lost
 with 'level='

To me, ele=* associated to a particular floor sounds awfull. Is it the
altitude of the floor ? Ceiling ? Eye-level ? 3D and indoor mapping is
great, and I wish we had better tools and data model to represent it
in OSM. ele=* could be used as a poor man's Z coordinate for 3d
modeling, but please don't mix it with the concept of building floors.

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

Re: [Tagging] Deprecating wikipedia Tag

[moltonel 3x Combo]

On 25/05/2015, Guillaume Allegre allegre.guilla...@free.fr wrote:
 I already replied that I wonder what's the idea behind that enforcement.
 Why wouldn't Wikidata be used also rather than instead?  Is it
 really a goal of OSM insisting to destroy Wikipedia?

 Wikidata has one more advantage : sometimes, Wikipedia pages are renamed
 (bad initial convention, or real-life renaming, or whatever), whereas
 Wikidata items identifiers (Q...), are persistent for unique concepts.

I don't think that anybody claimed that wikidata tags were not
desirable, nor a superset of wikipedia tags. The objections are about
the idea that the wikipedia tag should be deprecated in favor of the
wikidata tag :

* wikipedia names are friendlyer to mappers, and generally more well-known
* wikidata objects don't necessarily exist for all wikipedia articles
we want to use
* For data consumers wanting to show the wikipedia article (by far the
most common usecase), using the wikipedia tag is much more
straightforward than using the wikidata tag (leaving the language and
renames issues to more meticulous data consumers).

So. I'm quite happy with the status quo, having both wikipedia and
wikidata tags in OSM. I'm sure there's a QA tool somewhere that can
point ou discrepancy between the two tags, if need be.

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

Re: [Tagging] Deprecating wikipedia Tag

[moltonel 3x Combo]

On 25/05/2015, Martin Koppenhoefer dieterdre...@gmail.com wrote:
 2015-05-25 16:24 GMT+02:00 moltonel 3x Combo molto...@gmail.com:
 Also, a lot of wikipedia articles do not (yet) have a wikidata
 counterpart.

 I thought all wikipedia articles had been transformed into wikidata
 entities (that's what I was told from a guy from wikimedia).
 The big difference that I see that could be there (in theory, the current
 situation wasn't like that when I had looked at it some months ago):
 wikidata is about entities. wikipedia articles are that: articles, they
 could deal with different (wikidata) entities in the same article. Actually
 they do, if you look at what in osm is place and admin, the articles often
 (but not always) refer to both of them, while for wikidata it does always
 make a difference (IIRR).

I admit not knowing wikidata that well, so the following might be misinformed :

There can't be  a mapping from every wikipedia article to a
corresponding wikidata id. Where in wikidata would you link all the
wikipedia List of Foo articles for example ? And if I'm creating a
new article for that restaurant I like, how does the corresponding
wikidata object get created and linked ?

Automatically creating wikipedia articles out of wikidata objects
shouldn't be too hard. The reverse seems unlikely. As far as I
understand, wikidata will always be playing catch-up to wikipedia, to
some extent.

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

Re: [Tagging] Deprecating wikipedia Tag

[moltonel 3x Combo]

On 25/05/2015, Andy Mabbett a...@pigsonthewing.org.uk wrote:
 On 25 May 2015 at 17:13, moltonel 3x Combo molto...@gmail.com wrote:

 * wikipedia names are friendlyer to mappers, and generally more well-known

 Wikidata labels should be more useful, contain less redundancy, and be
 no less well-known. For example, High Street rather than High
 Street, Birmingham

How do you link to a wikidata label in an OSM tag ? One that never
suffers from renaming ? As far as I know, we can/should only use
wikidata ids, which are stable but not user friendly.


 * wikidata objects don't necessarily exist for all wikipedia articles
 we want to use

 Apart from newly created Wikipedia articles, with a Wikidata item not
 far behind, the reverse is true.

Thanks to all who countered my examples. I see now that, even if
wikidata may lag a bit (any stats to define a bit ?), there should
be a wikidata item for every wikipedia article.


 * For data consumers wanting to show the wikipedia article (by far the
 most common usecase), using the wikipedia tag is much more
 straightforward than using the wikidata tag

 Except when the Wikipedia article has been moved and the old name reused.

I had also mentioned rename issues. Why leave that sentense out of the
quote and then restate it ?

Of course ignoring renames and not taking advantage of the API to find
the translated article is a bad thing, and no consumers should do
that... But in the real world, most consumers will use the wikipedia
tag instead. Because it's obvious, and because a simple regexp-replace
will give you the url to forward the user to, instead of having to
query so wikidata REST api. And when those consumers eventually
encounter an OSM object that has a wikipedia tag but not wikidata,
they'll display nothing.

Which is why we should keep wikipedia tags (along with the
human-friendly IDs). And when both wikipedia and wikidata tags are
present, we can QA that they are in sync (just like we currently QA
that website an wikipedia are not 404).


Speaking of stable ids, how does wikidata handle renames, merges and
splits on the wikipedia side ? Even in the best-case scenario, it
seems that an OSM wikidata tag can drift off-target following
reorganisations that are correct from a wikimedia POV but not from an
OSM POV.

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

Re: [Tagging] Deprecating wikipedia Tag

[moltonel 3x Combo]

On 25/05/2015, Andreas Goss andi...@t-online.de wrote:
 ikidata will always be playing catch-up to wikipedia, to
 some extent.

 Can you just show me a single Wikipedia entry without a Wikidata object.

https://en.wikipedia.org/wiki/List_of_map_projections
Ok, maybe that one doesn't count because it's kind of metadata that
doesn't belong in wikidata.

https://en.wikipedia.org/w/index.php?title=Campagne_(restaurant)action=history
https://www.wikidata.org/w/index.php?title=Q15207004action=history
Hum, 2 months lag between data and pedia. Technically it proves my
point about the lag, but it isn't too bad.

https://en.wikipedia.org/w/index.php?title=Whiddy_Island_Disasteraction=history
https://www.wikidata.org/w/index.php?title=Q780440action=history
3.5 years is worse, but maybe the import-from-pedia bot wasn't active
until recently ?


No time to look for more right now. Didn't find wikidata links on the
wikipedia articles, it would have made search faster. I admit the lag
is fairly short, and many pedia article that I didn't expect to find
in wikidata were in fact there.

Your confidence in wikidata indicates that you know it well, which
I've stated is not my case. If, instead of asking rhetoric questions,
you can shed light on some inner workings of wikidata that garanties
that all OSM-worthy objects with a wikipedia article will also have a
wikidata item (and vice-versa), I'd be happy to forget about that
imagined downside of wikidata compared to wikipedia.

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

Re: [Tagging] Deprecating wikipedia Tag

[moltonel 3x Combo]

On 25/05/2015, Andy Mabbett a...@pigsonthewing.org.uk wrote:
 On 25 May 2015 at 22:18, moltonel 3x Combo molto...@gmail.com wrote:

 How do you link to a wikidata label in an OSM tag ? One that never
 suffers from renaming ? As far as I know, we can/should only use
 wikidata ids, which are stable but not user friendly.

 http://wiki.openstreetmap.org/wiki/Proposed_features/Wikidata

I see nothing there that enables using a wikidata label in an OSM tag.
The only reference to labels is a javascript library that does the API
calls for you, which is a completely different usecase.


 I had also mentioned rename issues. Why leave that sentense out of the
 quote and then restate it ?

 You wrote using the wikipedia tag is much more straightforward than
 using the wikidata tag (leaving the language and renames issues to
 more meticulous data consumers); my point apllies to all reusesrs,
 bnit just the more meticulous.

We agree, just a misunderstanding on the wording. All users of the
wikipedia tag will have issues with renames. The more meticulous
consumers will use the wikidata tag instead, which avoids rename
issues.


 Which is why we should keep wikipedia tags (along with the
 human-friendly IDs).

 But as already shown, Wikipedia tags have a higher-rate of link rot.

Yes. I'm not saying that wikipedia tags are better. Just that we need
to keep them, for better or worse.


 And when both wikipedia and wikidata tags are
 present, we can QA that they are in sync (just like we currently QA
 that website an wikipedia are not 404).

 Who will do that QA?

I know Keepright does, and I'd be surprised if Osmose doesn't.


 Speaking of stable ids, how does wikidata handle renames,

 Links from the Wikidata item are updated.

Ok, I assumed as much.

 merges and splits on the wikipedia side ?

 New bridging items are created.

Interesting. Where can I find examples and doc ?

 Even in the best-case scenario, it
 seems that an OSM wikidata tag can drift off-target following
 reorganisations that are correct from a wikimedia POV but not from an
 OSM POV.

 Example?

An hypothetical example: a hotel that includes a restaurant. OSM uses
two objects from the begining, both linked to the single wikidata
article that talks about the hotel as a whole. The restaurant later
gets spun off as an independent business and get its own wikidata item
(either a split or a new one), but OSM still links to the hotel as a
whole wikidata item.

Does wikidata have some tricks up its sleeve to reliably deal with
that kind of problem ?

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

Re: [Tagging] Long Tail ( was Removal of amenity from OSM tagging)

[moltonel 3x Combo]

On 19/05/2015, Simon Poole si...@poole.ch wrote:
 On 19. Mai 2015 03:18:14 MESZ, johnw jo...@mac.com wrote:
 

there’s no preset “I want to add a business” or “I want to add a park”
tutorials that walk through the basics and hold your hand, bring up
options and ask you natural language questions to help you learn how to
tag things. a person who just wants to add a node tag can have very
little asked of them, and the node placed in the correct spot. another
mapper can flesh it out later.

 I've many times suggested that if we really want to exploit the long tail we
 need wizards not simple editors (I'm not sure that the later actually
 exists). We shoudn't kid ourselves though, we are unlikely to squezze a
 higher conversion rate  to reasonably active mappers out of  our audience
 that way, just a longer long tail. Any way we do it we are asking for people
 to spend more/a significant amount of time contributing and that will only
 happen if somebody is actually interested in the subject matter.

http://onosm.org/ is IMHO not a bad answer to that. Maybe it could get
integrated on osm.org, alongside a collection of other special-purpose
wizards for various usecases.

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

Re: [Tagging] shop=confectionery / pastry / candy / sweets

[moltonel 3x Combo]

TL;DR: off-topic, rant, noise


On 12/05/2015, pmailkeey . pmailk...@googlemail.com wrote:
 On 12 May 2015 at 03:26, John F. Eldredge j...@jfeldredge.com wrote:

 Minor nitpick: desserts are sweet foods, usually eaten at the end of a
 meal. Deserts are areas with little rainfall, and sparse or no
 vegetation.

 Bearing in mind this context - of general discussion rather than written
 text book - do you know 'desert' was not merely an accidental typo ? In a
 more formal setting, I'd have jumped on it too :)

Yes, just like the typos in croissant and viénoiserie from that
same email (writen late at night), which John didn't pick on because
they're not on the list of classic English mistakes that some people
like to pick on. And while we're on language show-off mode, a French
person (like me) would never misspell dessert for desert (except
for typos) because in French the pronounciation differs and matches
the spelling.

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

Re: [Tagging] shop=confectionery / pastry / candy / sweets

[moltonel 3x Combo]

On 11/05/2015, Martin Koppenhoefer dieterdre...@gmail.com wrote:
 I believe there is some overlap between the shop values

 confectionery
 pastry
 candy
 sweets

 shop=confectionery is used much more often than the other 3 (10K vs. 300
 vs. 100 vs. 50) and is likely covering all of these, but is quite generic.
 For the very reason it can be used for both: pastry (baker's confections)
 and candy (sugar confections), it is often less useful IMHO (at least
 without subtag, which is currently not documented). often, because in
 some countries these tend to be distinct shops, but in other contexts there
 might be shops that are offering both kind.

 If you are looking for sugar confections or baker's confections, finding a
 shop that only sells the other variant of confections will not be helpful
 but rather a big annoyance.

 From previous discussions on this matter I believe to remember that
 pastry is actually not covering the entire subset of baker's confections,
 so the term might be less appropriate.

 sweets is not very specific neither, is not defined in the wiki and can
 maybe cover both, candy and pastry, or might be a synonym for candy/sugar
 confections (I am not sure about this, would be nice to hear what the
 natives say). It also doesn't seem to add any additional information with
 respect to confectionery, so I would suggest to deprecate its use
 completely.

 I think we could deal with this situation in several ways:

 a) use confectionery, pastry and candy as competing top-level tags and
 suggest to be the most specific where possible (i.e. aim to have only mixed
 shops tagged with the generic confectionery tag and recommend the more
 specific pastry and candy tags where applicable).

 b) recommend to only use confectionery as the main top level tag and use
 subtags like bakers_confectionery=yes and/or sugar_confectionery=yes to
 make the distinction

 c) your suggestion here

 Personally I favor b). What do you think?

My initial reaction was there's no overlap between pastry and
confectionery, they are totally different things. Some cultural
background: in France, shops selling candys are very rare, but shops
selling pastries are very common because bread shops are everywhere
and usually also sell pastries and danishes. Pastry-only shops are
quite rare. See also shop=patisserie (62 uses).

But using shop=confectionery and refining that into raw sug^W^Wsubtags
makes sense too.

For the subtag itself, I'm not a fan of FOO_confectionery=yes: I think
that confectionery=FOO follows established tag-creation best practices
better. It's used a bit in the db already. And if one needs to tag
multiple types, either confectionery=FOO;BAR or
confectionery:FOO=yes confectgionery:BAR=yes works for me (but I
prefer the later).

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

Re: [Tagging] shop=confectionery / pastry / candy / sweets

[moltonel 3x Combo]

On 11/05/2015, Daniel Koć daniel@koć.pl wrote:
 W dniu 11.05.2015 18:18, Andreas Goss napisał(a):
 Pastry-only shops are
 quite rare. See also shop=patisserie (62 uses).

 But is pastry = patisserie ?

 Yet another item just for sugar?... =}

Blaspheme ! :p You shouldn't compare Haribo-type sweets which *are*
mostly sugar with the deserts sold in a patisserie which can be
relatively healthy (yes, you need to double-check with the
boulangère). There's no sugar at all in the traditional croissant
recipe, and the butter-less version is common. Come and visit some
day, I'll bake you my no-sugar yes-beetroot brownie which is tastyer
than the classic brownie :)

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

Re: [Tagging] shop=confectionery / pastry / candy / sweets

[moltonel 3x Combo]

On 11/05/2015, Andreas Goss andi...@t-online.de wrote:
 Pastry-only shops are
 quite rare. See also shop=patisserie (62 uses).

 But is pastry = patisserie ?

To me it is, but deserts are very tied to the local culture, so I'm
sure opinions will differ.


 http://media-cdn.tripadvisor.com/media/photo-s/03/de/f0/35/el-tawhid-pastry.jpg

 http://media-cdn.tripadvisor.com/media/photo-s/05/28/25/df/patisserie-richard.jpg

 Because the first image is what every bakery in Germany usually sells,
 too. But the 2nd one while you can often find some limited selection at
 bakeries, is what we usually buy at a Konditorei which has a much larger
 selecter with higher quality and looks like this:

 http://www.reschinsky.com/online/media/Torten_2.jpg

A french patisserie will sell both kinds. A boulangerie will
almost always also sell croisants (the first kind) even if it sells no
other sweet stuff. For what it's worth, the first kind is generally
refered to vienoiseries in France (where I come from) and danish
pastry in Ireland (where I live).

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

Re: [Tagging] Colour coding of wiki description boxes

[moltonel 3x Combo]

On 06/05/2015, Andy Mabbett a...@pigsonthewing.org.uk wrote:
 On 6 May 2015 at 17:41, moltonel 3x Combo molto...@gmail.com wrote:
 On 05/05/2015, Andy Mabbett a...@pigsonthewing.org.uk wrote:

 If people choose not to (or are not bothered to) comment, that's an
 abstention.

 Indeed, it may reasonably be argued that of they choose not to comment
 on a proposal to do something, then they are content with the
 proposal.

 It'd only be reasonable if those people were contacted.

 You'll note my use of the word choose.

 You've neglected to quote the post to which I was replying; it said:

 pretty hard to tell when not all mappers were questioned or bothered to
 reply, not ?

 which includes the scenario where some editors were not bothered to reply.


We agree on the not bothered to reply, therefore treat it as abstain scenario.

But that original quote also mentioned the not all mappers were
questioned scenario, which is much more common. As Matthijs said,
contacting mappers individually has a very low response rate. So
instead, people use wiki votes and mailing list or forum threads as a
measure of the general opinion. That's practical but heavily biased.
Please don't think that it's the same thing as contacting mappers (and
then being able to assume that they agree if they don't respond).

Sorry for labouring the point if only replying to the mappers were
contacted scenario was intentional.

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

Re: [Tagging] Colour coding of wiki description boxes

[moltonel 3x Combo]

On 05/05/2015, Andy Mabbett a...@pigsonthewing.org.uk wrote:
 If people choose not to (or are not bothered to) comment, that's an
 abstention.

 Indeed, it may reasonably be argued that of they choose not to comment
 on a proposal to do something, then they are content with the
 proposal.

It'd only be reasonable if those people were contacted. Discussions on
[tagging] or [talk] or the wiki are *not* a good way to contact
mappers for democratic opinion-gathering purposes. OSM doesn't have a
policy that interested contributors have to participate on this or
that dicussion medium. I've joined [tagging] very late in my OSM life
(and can't afford the time to read it all), but I've always been very
interested in any change to the data I've contributed.

It may be a PITA, but it's a fact. The closest thing we have to
officially contacting mappers (and filing them under
abstain/uninterested if they don't answer) is the private messages on
osm.org. But using that for a large number of users is frowned uppon.

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

Re: [Tagging] electric zigarrettes

[moltonel 3x Combo]

On 24/04/2015, Thorsten Alge li...@thorsten-alge.de wrote:

 I fear at this stage we can only agree to disagree : to me using
 e-cigarettes *is* smoking. I don't care much for the physicist's
 definition of smoke. It's the social/medical definition that matters
 here, the one that gets turned into laws and ultimately into osm tags.

 No offence but it is more a matter of law and house rules. Smoking (a
 cigarette) is strongly regulated by law in Germany and only partly by
 operators of amenities. In the case of vaporizers its for the operator
 to decide. So we have amenities where it is forbidden to smoke
 cigarettes but allowed to use vaporizers.
 So I don't want to take up the cudgels for vaporizers but I also think
 if we tag smoking=* we should also tag for vaporizers.

Absolutely, wherever the rule differ between the two practices, we
need to tag that.

Currently e-cigarettes have managed to define themselves in a way that
avoid most countries' anti-smoking laws (I expect the laws to
eventually catch up, but also to be more lennient towards
e-cigarettes). So the law often says nothing, and it's up to
manager/owner to decide. The only time I saw somebody smoking an
e-cigarette in a cafe (in a medium Irish town that has a few shops
dedicated to e-cigarettes) I asked the owner what his policy was and
his answer was same as classic cigarettes, I would have stoped the
smoker had I seen her. Granted it's just one annecdote, but I've seen
plenty of other hints that people expect the social rule to be the
same for e-cigs and traditional cigs, despite the law being silent on
the subject.

OSM-tagging-wise, this leads me to belive that :
 * In the absence of specific information, the social rule is likely
to be the same for both practices, and therefore smoking=* can be
used as the fallback value for ecig-permited-key=*.
 * both practices are similar enough that it makes sense to group them
in the same namespace (smoking: for obvious historical reasons).

By all means, go ahead and setup a QA tool that complains about the
lack of e-cigarette tags if you want.

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

Re: [Tagging] electric zigarrettes

[moltonel 3x Combo]

On 23/04/2015, Martin Koppenhoefer dieterdre...@gmail.com wrote:
 you're suggesting smoking as a single namespace, which doesn't apply to
 vaporizers. Maybe inhaling?
 On the other hand, smoking is also forbidden when not inhaling... ;-)
 I think different namespaces make sense here, because they are different
 things.

I fear at this stage we can only agree to disagree : to me using
e-cigarettes *is* smoking. I don't care much for the physicist's
definition of smoke. It's the social/medical definition that matters
here, the one that gets turned into laws and ultimately into osm tags.

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

Re: [Tagging] electric zigarrettes

[moltonel 3x Combo]

On 22/04/2015, Martin Koppenhoefer dieterdre...@gmail.com wrote:
 2015-04-22 9:19 GMT+02:00 Paul Johnson ba...@ursamundi.org:

 Well, electronic cigarettes aren't really smoking in the first place,
 unless you want to claim that a teapot boiling is smoking, which is
 something most people realize isn't the case by the time they're 10...

 +1, e-cigarettes should IMHO not be covered by the smoking tag, because
 they have nothing to do with smoking. Yes, it is a form of nicotin
 consumption, but so are nicotin pills, chewing gum, patches, chewing
 tobacco, sniffing tobacco and maybe others. None of them is covered by
 smoking, there is no smoke.

That's taking the word much too litteraly. The reason behind all the
anti public-smoking laws is that non-smokers are subjected to the
product and most of the associated health risks. Pills, patches and
gums are different because you can't be a passive pill swallower.
The fact that e-cigarettes seem less harmfull (it'll take many years
to properly quantify the risk) doesn't change that. The it isn't
actual smoke argument is a technicality, a PR stunt, a legal hack
enabling nicotine addicts to smoke in public.


Getting back to the subject of OSM, for places that do distinguish
between classic- and e-cigarettes, I suggest using a namespace for the
sake of consistency, discoverability, and compatibility :

smoking=yes/no/outside/etc for the general value
smoking:type=yes/no/etc for exceptions
With type being any of cigarette, e-cigarette, hooka, marijuana, opium, etc.

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

Re: [Tagging] electric zigarrettes

[moltonel 3x Combo]

On 22/04/2015, Bryce Nesbitt bry...@obviously.com wrote:
 On Wed, Apr 22, 2015 at 9:34 AM, moltonel 3x Combo molto...@gmail.com
 wrote:
 smoking=yes/no/outside/etc for the general value
 smoking:type=yes/no/etc for exceptions
 With type being any of cigarette, e-cigarette, hooka, marijuana, opium,
 etc.

 That would quickly get unwieldy, trying to tag different restrictions for
 each nicotine delivery method.

 However just repeating the smoking tagging scheme can cover all cases
 the smoking tag does:

   smoking=no
   vaporizing=no
   vaporizing:outside=separated
   smoking:outside=no

How is it unwieldy ? Your scheme uses exactly as many keys as mine for
a given usecase. The only difference is that I put everything under a
single namespace, which makes it tidyer and more discoverable.

Also, being and an evolution of the existing rather than a brand new
tag, and having a general value, consumers that aren't up to date with
the latest tagging trend will still get a somewhat usable value.

Lastly, I'm not a fan of the term vaporising : it's rather new and
not yet well established. It has other meanings that have nothing to
do with nicotine. It's confusing. There was a discussion about the
value for shop= not too long ago, and e-cigarette eventually came
slightly on top (now reflected in taginfo). I think it's much clearer
than vape and derivatives,

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

Re: [Tagging] electric zigarrettes

[moltonel 3x Combo]

On 21/04/2015, Thorsten Alge li...@thorsten-alge.de wrote:
 is there a tag to express that the use of electronic cigarettes is
 permitted at a location? If not I'd like to suggest the use ecigarette=*
 or vaporizing=* with the same values as smoking=*.

I've never seen a place that permitted one type of smoking but not
another. Unless you' ve got a specific surveyed example to share, it's
probably best to keep everything under smoking=*.

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

Re: [Tagging] Way inside riverbank

[moltonel 3x Combo]

On 14/04/2015, Christoph Hormann chris_horm...@gmx.de wrote:
 It is the other way round - the riverbank polygon is optional and 'nice
 to have'.  The waterway line is what actually defines a river in OSM,
 it also gets the name tag and other attributes.

Yes, this is the same principle that gives us highway=* vs
area:highway=* 
(http://wiki.openstreetmap.org/wiki/Proposed_features/Street_area).
Note that as a result, the riverbank polygon doesn't need a name=*,
because that is taken from the linear river way instead.


Changing topics, I've just stumbled on the wiki on the natural=water,
water=river tagging that I wasn't aware of and is supposed to replace
waterway=riverbank. 4 years after being approved, it still
represents only about 3% of the riverbank tagging. I guess that the
it's more uniform and logical argument wasn't compeling enough, and
that tagg...@osm.org != osm community...

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

Re: [Tagging] Proposal: Rename wiki status Approved to Published

[moltonel 3x Combo]

On 05/04/2015, Frederik Ramm frede...@remote.org wrote:
 I really see two paths - either continue what I did, let the Wiki use
 terms like approved but make it clear enough to everyone that the Wiki
 isn't the OSM bible but just what a very small number of people think
 about OSM; or try to increase the standing of the Wiki as an
 authoritative source but then we'd really have to be careful not to
 mislead people with terms like approved.

The way I understand it, the approved-published proposal follows your
first path : making it clear enough that the wiki isn't the osm bible.
You seem to imply that this path can only be followed by elements
outside the wiki, but in fact the wiki itself can/should aknowledge
that it isn't the bible. With that goal in mind, a lot of people feel
that approved puts the wiki proposals on too high a pedestal, and I
support a change of wording that help take it down a notch.

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

Re: [Tagging] Proposal: Rename wiki status Approved to Published

[moltonel 3x Combo]

On 04/04/2015, Warin 61sundow...@gmail.com wrote:
 On 4/04/2015 8:58 AM, Bryce Nesbitt wrote:

 It is a 'No' vote. Not an abstain.

 .
 For an English definition see
 http://www.oed.com/view/Entry/154075?redirectedFrom=published#eid

That's behind a paywall. Would you copy oed's definition here ? A
small enough quote should be fair use. I went ahead and looked at
https://en.wikipedia.org/wiki/Publishing instead, which I feel would
be more universal than a uk-centric definition anyway.

   Replacement of the word 'Approved with Published' will cause a
 similar level of confusion. No gain, indeed a loss as time will be
 wasted changing the word 'approved'.

I'm sure published will bring its fair share of confusion. And if it
didn't, this mailinglist would have a very hard time agreeing on it :
we need to leave some marginof interpretation or else everybody will
veto some tiny detail.

But whatever the level of confusion of both terms may be, I still
think that approved is a step in the right direction. It's closer to
what *I* think proposals are good for. Even if the error bar was
bigger, the value is more correct and the term is better.

One can try to write a page defining what published means in the
context of wiki proposals. But given the current level of controversy,
I wish the authors good luck :p

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

Re: [Tagging] Revisiting proposal/voting scheme

[moltonel 3x Combo]

On 18/03/2015, Kotya Karapetyan kotya.li...@gmail.com wrote:
 On Wed, Mar 18, 2015 at 11:00 PM, moltonel 3x Combo molto...@gmail.com
  wrote:
 Why should the page be converted to a feature page ?

 Because I would mark a proposal page as such in some place. Otherwise a
 stable 10 year-old feature page cannot be easily distinguished from a
 proposal created yesterday. I see something like moving the page to a
 different namespace or removing a proposal status. Not changing the
 content or rewriting the page.

Ok, I understand better where you're coming from. But this doesn't
gain anything compared to the current workflow. You still have a flag
day when the proposal is deemed done/accepted. You're losing the
information that it's a design doc under consideration (in my view,
tagging schemes remain under consideration until they get widely
used in the db, regardless of their approved/rejected status).

Let's take an example. Somebody writes a proposal about the smoothness
key that finally solves all the problems and has unanimous acceptance.
If you convert that to a Key:Smoothness page, the wiki becomes
completely disconnected from the db. If instead you keep the proposal
page as-is, but add links on the key pages with conforms to /
contradicts proposal foo links for each value, you get the best of
both worlds.



 Feature pages and proposals should be writen in parallel, not one
 after the other.

 I am promoting writing a single feature proposal page, which, after the
 initial discussion, is made just a feature page. So nothing is written
 one after another.

It may be just editing/moving an existing page rather than creating a
new one, but you still have one after the other. At no point do you
have both the feature page and the proposal available at the same
time.

Remember that, in my initial suggestion, the feature page and the
proposal serve two different purposes : to document existing practices
and to document desired practice. I think it's important to clearly
distinguish the two in the wiki. The wiki is here to guide, not to
direct.

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

Re: [Tagging] Revisiting proposal/voting scheme

[moltonel 3x Combo]

On 18/03/2015, Kotya Karapetyan kotya.li...@gmail.com wrote:
 On Wed, Mar 18, 2015 at 11:00 PM, moltonel 3x Combo molto...@gmail.com
  wrote:
 Why should the page be converted to a feature page ?

 Because I would mark a proposal page as such in some place. Otherwise a
 stable 10 year-old feature page cannot be easily distinguished from a
 proposal created yesterday. I see something like moving the page to a
 different namespace or removing a proposal status. Not changing the
 content or rewriting the page.

Ok, I understand better where you're coming from. But this doesn't
gain anything compared to the current workflow. You still have a flag
day when the proposal is deemed done/accepted. You're losing the
information that it's a design doc under consideration (in my view,
tagging schemes remain under consideration until they get widely
used in the db, regardless of their approved/rejected status).

Let's take an example. Somebody writes a proposal about the smoothness
key that finally solves all the problems and has unanimous acceptance.
If you convert that to a Key:Smoothness page, the wiki becomes
completely disconnected from the db. If instead you keep the proposal
page as-is, but add links on the key pages with conforms to /
contradicts proposal foo links for each value, you get the best of
both worlds.



 Feature pages and proposals should be writen in parallel, not one
 after the other.

 I am promoting writing a single feature proposal page, which, after the
 initial discussion, is made just a feature page. So nothing is written
 one after another.

It may be just editing/moving an existing page rather than creating a
new one, but you still have one after the other. At no point do you
have both the feature page and the proposal available at the same
time.

Remember that, in my initial suggestion, the feature page and the
proposal serve two different purposes : to document existing practices
and to document desired practice. I think it's important to clearly
distinguish the two in the wiki. The wiki is here to guide, not to
direct.

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

Re: [Tagging] Revisiting proposal/voting scheme

[moltonel 3x Combo]

On 18/03/2015, David Bannon dban...@internode.on.net wrote:
 No, I'm sorry but I don't see how an interested party can be expected to
 objectively determine what the discussion concluded.
 [...]
 No, sorry, but a vote and an outcome may offend some politically correct
 members but it is necessary.

Don't you see the contradiction in those statements ? I fully agree
with your first paragraph, but that means that I disagree with the
second : a vote is not a good way to determine that the discussion has
concluded.


 In my experience, a wiki that is 'unmoderated' very quickly becomes such
 a mess its unusable.

I'm not sure why you see the proposed workflow changes as turning the
wiki into an 'unmoderated' thing.


 New users to OSM need to see the idea of 'approved' keys and values.

I do not see that at all. Only after a few years of editing did I
venture into the Proposal namespace on the wiki, and I was still far
removed from the concept of approved proposals. Editor presets,
default rendering, existing data, general wiki pages, and taginfo is
what guided me (in that order).

Approving a key has today more to do with politics than with
technical/practical considerations, and that's the last thing you want
to show to newbies.

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

Re: [Tagging] Separating usage docs from design docs (was: Increasing voting participation)

[moltonel 3x Combo]

On 18/03/2015, Martin Koppenhoefer dieterdre...@gmail.com wrote:
 * key/tag pages would document the actual use (mainly observed via
 taginfo)

 it is impossible to see  from taginfo what a tag is used for, and for what
 it can't be used. You only get statistics how much it is used

 * key/tag pages could be kept up to date fairly objectively

 I find this difficult. If I start using a tag in the belief that it means a,
 and after two years people decide that this was a bad idea and now it should
 mean only a*, am I to review all my previous edits?

Yes, being objective and figuring out exactly what the current usage
is can be daunting, and taginfo is sometimes of little use
(landuse=forest vs natural=wood for example). But I think having a
stated goal of objectivity is still better than the current situation,
where some key pages document values that have never been used. Being
able to trust the content of a key/tag page without systematically
having to double-check taginfo and other sources would be a welcome
improvement.

 Do we really need to change tag definitions, or would it be more sustainable
 to require new sub tags or alternative tags when the semantics should change
 or be amended?

We should certainly aim for backward compatibility when coming up with
new tags. It s not easy, we haven´t always succeeded. But that´s a
different topic.


 * proposal voters should put the page on their watchlist, in case a
 change in the proposal changes their opinion

 see previous comment

Yes, asking to watch pages is asking a lot. But I´d like to move away
from the formal drafted-proposed-accepted/rejected workflow, because
I think it just can´t work in OSM. That implies that proposals should
be able to evolve a bit over time. But if you make significant changes
after many people have voted, it´s probably better to create a new
proposal instead, to avoid backward-incompatibilities.

 also, I'd probably have to spend all day checking tag definition pages then

Not anymore than you watch actual OSM data, since tag definition pages
are supposed to reflect actual usage. So my suggestion should actually
reduce the need for page-watching compared to current workflow.

 * proposals should only be end-of-lifed if there is near-unanimous
 opposition and near-zero actual usage

 +1, if at all. Near zero usage should be 10

I don't like to give numerical thresholds, but yeah.

Another option for end-of-lifeing a proposal is if a newer proposal
replaces it in a backward-compatible maner.

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

Re: [Tagging] Separating usage docs from design docs (was: Increasing voting participation)

[moltonel 3x Combo]

On 18/03/2015, Christopher Hoess caho...@gmail.com wrote:
 That's an interesting idea, but I think it may be a little too heavy on
 coexistence; I think we'd gradually accumulate a cloud of contradictory
 proposals with no incentive to resolve them.

Are you afraid of wiki bloat ? I don't think it'd be much of an issue.
Proposals that fall into disuse will naturally lose their links from
feature pages and disappear from public view. We already have a
collection of old contradictory proposals that have never been
officially rejected. It doesn't hurt much, they sometimes come up in a
search, but since we probably  never want to fully delete them from
the wiki anyway...


 So, my modest proposal: if you want to create a new key, add a new page to
 the wiki. If you want to create a new value for a key, add it to the
 existing page for the key. If someone sees that edit and wants to change
 it, they can change it; if you object, the two of you can discuss it on the
 talk page. Tags used in the database that are not documented in the wiki
 (here comes the outrageous part!) are treated as provisional; they can be
 added or removed at will, by any editor, mechanically or otherwise.

Tempting, but I don't think it'll fly, for a few reasons:
 * We've got a huge backlog of frequently-used non-documented keys to
work through : 
http://taginfo.osm.org/reports/frequently_used_keys_without_wiki_page
 * For good or ill, a lot of contributors don't (want to) use the
wiki. Turning it into a mandatory part of osm just won't work from a
social point of view
 * You're raising the bar quite a bit for the creation of new tags,
without even improving the quality of tags in the process.
 * Suggesting that it's ok to undo somebody's work because he didn't
document it is a recipe for nasty conflicts.

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

Re: [Tagging] Revisiting proposal/voting scheme

[moltonel 3x Combo]

On 18/03/2015, Kotya Karapetyan kotya.li...@gmail.com wrote:
 I think some opposition to a proper voting mechanism is concentrating too
 much on the numbers. Indeed, we can have just 1 person proposing a tag, 20
 people voting about it, and thousands actually using (or miusing) it.
 However:

 1) As mentioned elsewhere, the discussion process accompanying the voting
 is valuable for the tagging improvement. There would be less interest in
 the discussion *and improvement* if we remove the competition and the
 question will my proposal get approved by the community?

 2) When a potential user sees the positive and negative votes (which,
 ideally, summarize the discussion), he may decide for himself whether or
 not to use a tag. If there is no voting, there is no such digest of the
 in-depth consideration by those who took care to get involved.

Yes, I started my get rid of the approval process suggestion by a
votes are usefull statement. We can/should keep votes because :
 * They trigger more discussion on the proposal
 * They are rewarding for the proposal author (even negative votes
show that people took an interest)
 * They help gauge wether the proposal is generaly thought by the
community to be a good one

However we should get rid of the approval process because :
 * It gives a false sense of authority to the decision
 * It'll only ever sample a tiny, self-selected minority of contributors
 * We still can't agree on good approval thresholds
 * It freezes the proposition on the vote date, preventing later
evolution and discouraging earlyer use


 I see however a problem in the fact that the proposal page, with its voting
 section, is not present in the final feature page. There is just an
 approved status, and most people wouldn't care to take a look at *how* the
 thing was approved. An 8:2 vote thus results in exactly the same perception
 of a tag as a 50:0 one.

That's why I suggested never closing the proposal page, and never
removing the crosslinks between the proposal pages and the feature
pages. There's no good reason to hide the proposal page afterwards, it
contains information that is just as usefull as the actual current
use of the feature page.


 The current system of a clear separation of the proposal and feature pages
 actually makes the closed voting necessary*. That *is why we need to agree
 on the numbers.

 Taking into account everything said in the (now multiple) threads on the
 topic here, would it make sense to *change the current proposal/voting
 mechanism like follows*?

 - Author proposes a feature as now.
 - RFC period with simultaneous page revision follows
 - Opinions for and against are expressed in the discussions and
 summarized at the top of the page (e.g. advantages and disadvantages of
 a tag) together with the current usage

So far so good.


 - When the discussion calms down (which can even be defined mathematically
 if needed), this very page is converted into a feature page. It is never
 approved or rejected, but the opinions are made clear.

Why should the page be converted to a feature page ? A good proposal
should already be nicely usable as documentation of the desired
tagging schema. So that converting it would basically mean removing
the votes/pros/cons sections and changing the name... Not really
usefull by itself.

By contrast, if the feature page documents actual use, that's a
different look at the same problem, interesting in itself.

Note also that the feature - proposal relation is not one to one but
many to many. Any nontrivial proposal will link to multiple tags, and
a particular tag may link back to multiple competing proposals (for
example addr:housenumber which can be used either in a addr:street
scheme or an associatedStreet one).

Feature pages and proposals should be writen in parallel, not one
after the other. A proposal without some proof-of-concept data
somewhere is suspicious, and so should a brand new tag without a
backing proposal.


 - People can add their concerns later just by editing the page. Thus there
 is no closing of the proposal phase. A feature can even get deprecated with
 time if the usage is low and too many issues became apparent. This would
 make discussions a bit more relaxed and positive.

Yes.


 The advantage of such approach would be:
 - Adherence to the wiki idea, when the community develops a good page by
 working on it more than by discussing it;
 - Matching the OSM logic where numbers matter
 - The majority of concerns regarding the discussion, voting, and
 approval/rejection mechanism are addressed
 - The system is even i18n-friendly, because such a top-of-the-page summary
 can be easily translated, unlike a discussion in a mailing list
 (potentially several of them).

Yes.

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

Re: [Tagging] Blatant tagging for the renderer: bridges abandoned railways

[moltonel 3x Combo]

On 11/03/2015, johnw jo...@mac.com wrote:
 Actual physical bridges - which may offer the only way across a ravine, or a
 landmark to where you are on a river sounds like a similar justification -
 so rendering abandoned, yet physically existing bridges seems like exactly
 the kind of thing that would be included - especially since their inclusion
 would offer no clutter or distraction at levels where other items would
 cause quite a lot of visual clutter for similar orinentation benefit.

[...]

Again : the osm-carto dev agree that all bridges should be rendered.
It's two longstanding bugs, it takes time to fix. Not rendering
abandoned railways (wether or not on top of a bridge which should
itself be rendered) is a separate issue (this time not a bug but a
conscious decision).

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

Re: [Tagging] Survey points

[moltonel 3x Combo]

On 11/03/2015, Malcolm Herring malcolm.herr...@btinternet.com wrote:
 I took a quick look at these objects  the few that I examined were
 actually created as areas, rather than had been converted from a node.
 The most egregious example is this one:
 http://www.openstreetmap.org/way/199650922. It is a square with sides
 over 500m, and a note that reads do not move this node!!??

Fixed.

See http://www.openstreetmap.org/node/670609313/history which was part
of the way and is the original proper survey point. Luckily the point
was not moved (just got its tags deleted) and was retained as part of
the way. The contributor probably used the replace geometry action
from utilsplugin2.

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

Re: [Tagging] Blatant tagging for the renderer: bridges abandoned railways

[moltonel 3x Combo]

On 11/03/2015, Richard Fairhurst rich...@systemed.net wrote:
 moltonel 3x Combo wrote:
 I'm playing the devil's advocate a bit here

 I believe the modern day term for that is trolling, and it wastes
 everyone's time.

Sorry if looked like trolling. I was genuinely trying to show both
sides of the argument, as a way to soften conflicts ahead of time
(since as far as I can tell they'll continue to happen). My devil's
advocate remark was indented to clarify that defending one argument
doesn't mean that I blindly always side with that camp.

 The whole railway episode has been really disheartening for the casual
 disrespect it shows to committed contributors. No-one has a monopoly on
 deciding what belongs in OSM and what doesn't, but honouring the dedication
 and commitment of the users who have made our map great must surely be high
 on the list.

 We've already imported too much of the bureaucracy and the automate
 everything attitudes that have damaged the Wikipedia community so. Please
 let's not adopt deletionism as well.

Agreed. I always strive to be conservative and chatty when touching
somebody else's work, railway or otherwise.

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

Re: [Tagging] Survey points

[moltonel 3x Combo]

On 11/03/2015, Malcolm Herring malcolm.herr...@btinternet.com wrote:
 OK, the mapper in question did not reply, but silently removed the tags.
 This leaves me none the wiser as to the more widespread usage of this tag.

At least that's reassurance that a buoy, which can drift quite a bit
on the surface, isn't considered as a survey point :p

 Looking closer at the data, it appears that man_made=survey_point is
 very often added to prominent objects, particularly towers, masts and
 lighthouses. Could it be that some survey agencies use these objects as
 triangulation points?

Often yes. And to make that survey point official when it isn't a
purpose-built structure, there is often a reference plaque placed on
the structure at the exact location of the point.

 If so, it raises a couple of issues:

 1. The man_made key should refer to the structure, not its usage.
 2. The drift towards micro-mapping means that such objects, originally
 mapped as nodes, get converted to plan outlines and the tags moved to
 that closed way. If the intent of the survey_point mapper was to set a
 lat/lon positional reference, then that scheme is undone.

 Might it not be appropriate to add a note in the Wiki page for this tag
 that it should not be added it to existing objects, but to always create
 a separate node?

The wiki already mentions that the tag only applies to nodes, which
should in theory catch upgraded to an area mishapps. There are
currently 64 survey_point ways in the db (compared to 287000 nodes),
so the problem exists but isn't too big. Care to review them ?

That said, a always add survey points as their own node
recommendation on the wiki can't hurt.

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

Re: [Tagging] Survey points

[moltonel 3x Combo]

On 11/03/2015, Martin Koppenhoefer dieterdre...@gmail.com wrote:
 2015-03-11 12:49 GMT+01:00 John Willis jo...@mac.com:

 I assume a tower on a distant mountain is a survey_reference_object or
 similar.  It certainly isn't a point.

 maybe the tower has a point defined (e.g. top of the antenna or a sign or
 similar) which could be a survey_point.

Here is a fine example of this case : http://www.openstreetmap.org/way/236843122
The description tag explains that the reference point is the base of
the christian cross on this bell tower. I think it makes sense of
mapping this this way : in a sense the whole building *is* the
man_made=survey_point. Adding a separate survey_point node would have
little benefit.

There are other examples like this one, but not all of them have a
neat description of where the precise survey point is on the
structure.

On the other hand, some ways look a bit pointless and could probably
be nodes, but a survey is needed to be sure:
http://www.openstreetmap.org/way/4041174
http://www.openstreetmap.org/way/315474577

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

Re: [Tagging] Blatant tagging for the renderer: bridges abandoned railways

[moltonel 3x Combo]

On 10/03/2015, Bryce Nesbitt bry...@obviously.com wrote:
 On Mon, Mar 9, 2015 at 5:53 PM, moltonel 3x Combo molto...@gmail.com
 wrote:
 I've also seen the opposite mapping issue, where an abandoned railway was
 deleted from the map,
 when in fact large chunks still exist.

If an osm way represents a railway that is 50% gone, is it more
correct to keep the way or to delete it (ignoring the actually-correct
but time-consuming task of deleting only the parts that are gone) ?
Where would you put the % gone before complete deletion is justified
threshold ? Throw in the problem that gone is a subjective term
(plus different answers on the ground and using imagery), and you get
a nice recipe for disagreements.

I'm playing the devil's advocate a bit here, to show how quickly
opinions can diverge. Please always discuss your intent with the other
contributor.

Thankfully the distinction between abandoned and disused is clear.
It's between abandoned and razed/not_maped that things get tricky.

 Also, if an abandoned railway has evolved into something else, then
 it's not an abandoned railway anymore. If you add a highway=cycleway
 tag, you should remove the railway=abandoned tag.

 I don't see that railway=razed damages highway=cycleway.

s/razed/abandoned/. No damage done, it's just no longer usefull.

 The present day cycleway may well have photos of that same old railway on
 interpretive signs.  The current cycleway may in fact be called a rail to
 trail.  Some people seek those out explicitly, because they're associated
 with a flat grade and gentle curves.

 In cases like this the history is* a part of a present day object.*

Railway=* is a poor heuristic for flat grades and gentle curves : lots
of false negatives. If the cycleway is advertised as a 'rail to
trail', it'll transpire in other tags, name=* and maybe tourist=*.

I'm not saying that the attributes you describe are not interesting,
but that describing them by tagging the history of the object is the
wrong way around. Tag the current state, not how it came to be. Just
like we tag smoothness=* rather than the name of the road surfacing
company (yeah, silly example).


 Railroads are special in part because they're large and long, far bigger
 than any abandoned shop or razed cottage.
 They leave a major footprint on the future world, one that's often apparent
 well after the last bit of gravel is dug out and planted over.

 It's more like tagging shoe shop in a landmark beaux arts former post
 office than turn left where the fruit stand used to be.

Yes, railways do leave long-lasting signs. Then again, even cow paths
have a tendency to turn into avenues (with a tell-tale layout
appreciated by historians and tourists) given enough time, so it's not
particularly unique or impressive. Yet when it comes to tagging the
past, OSM apparently only cares about railways.

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

Re: [Tagging] Blatant tagging for the renderer: bridges abandoned railways

[moltonel 3x Combo]

On 10/03/2015, ael law_ence@ntlworld.com wrote:
 In passing, I am a little bemused that so many people seem to have missed
 the hint that I normally regard tagging for the renderer as evil by
 using the word Blatant in the title of this thread and that it was
 sort of a confession and plea for help on how to avoid doing that.

I don't think that anybody missed the hint, just confirmed that it was
just as evil and unnecessary in this case.

 Anyway, it seems to have been productive overall and it sounds as if the
 decision on the standard rendering might be revisited.

I very much doubt that the decision to not render railway=abandoned is
going to be revisited. As for the issue of rendering various cases of
stand-alone bridges, it was already on the todo.

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

Re: [Tagging] Blatant tagging for the renderer: bridges abandoned railways

[moltonel 3x Combo]

On 09/03/2015, Tom Pfeifer t.pfei...@computer.org wrote:
 +1, please tag what is on the ground,
 and railway=abandoned is not rendered on carto by decision, read here:
 https://github.com/gravitystorm/openstreetmap-carto/pull/542

As for the discussion on rendering standalone bridges :
https://github.com/gravitystorm/openstreetmap-carto/issues/1320

Note that there has been lots of arguing on the railway topic on
github (and elsewhere). Please don't refuel that particular debate,
osm-carto's choices may not match your own, but they are coherent.

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

Re: [Tagging] Blatant tagging for the renderer: bridges abandoned railways

[moltonel 3x Combo]

On 09/03/2015, ael law_ence@ntlworld.com wrote:
 On Mon, Mar 09, 2015 at 03:35:19PM +0100, Tom Pfeifer wrote:
 +1, please tag what is on the ground,
 and railway=abandoned is not rendered on carto by decision, read here:
 https://github.com/gravitystorm/openstreetmap-carto/pull/542

 Thanks for the link. Interesting reading. Obviously I support the
 case made there very clearly for (just) rendering the bridges. A pity that
 it seems to have been dismissed without any real explanation.

Developers like to keep issue/pull discussions on topic, and that
pull's topic was about no longer rendering railway=abandoned, not the
separate issue of rendering underlaying bridges. Two separate issues
were created (and linked to in this thread) to fix rendering of
bridges.

That pull discussion heated up quickly but certainly wasn't low on explanations.

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

Re: [Tagging] Blatant tagging for the renderer: bridges abandoned railways

[moltonel 3x Combo]

On 09/03/2015, Bryce Nesbitt bry...@obviously.com wrote:
 Ah thanks, I stand corrected. railway=razed would be the tag to discuss.

 The broader point is intact.


While there is a pretty strong consensus that osm describes the
present (leaving openhistoricalmap for the past), it seems that some
railway contributors like to map the past (that's what 'razed' and
'reused' describe). Railway=razed is the equivalent of keeping the
building=house way after big appartment blocks have been built and
maped in its location. Railway=reused (i believe it's usually tagged
as 'abandoned') is the equivalent of tagging 'this used to be a post
office' after it has been turned into a shoe shop. These comparisons
may be poorly chosen, but you get the idea.

I never understood what made railways different from buildings, shops,
streets etc in that respect. Maybe because it's easyer to deduce where
a railway used to pass than where a cotage used to be ?

To make things worse, a number of enthusiastic contributors have
tagged 'abandoned' what should have been tagged 'razed' (or better:
not mapped at all). This fact contributed to the decision of not
rendering 'abandoned' anymore.


 When making sense of abandoned bridges and oddly rounded buildings in
 various places, it is super helpful
 to see the context of the prior railroad grade.  It helps in mapping from
 the air and on the ground.

 A given railway grade may (and often does) exist as razed, abandoned,
 disused, and reused (e.g. highway=residential or highway=service,
 leisure=park) along it's length.  So how can we represent the former way,
 and the current use of each bit,
 in a rational way?

If there's still a bridge or maybe even an embankment, then
railway=abandoned is fair game (assuming it hasn't turned into, for
example, a highway=track in the meantime). And it'd be nice if
osm-carto rendered these bridges and embankments even though
railway=abandoned isn't (they are working on the former, at least).
These bridges are interesting to the contemporary map user. The fact
that they were built for a railway is only interesting to the
history-inclined map users, which osm-carto has decided not to target.

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

Re: [Tagging] Blatant tagging for the renderer: bridges abandoned railways

[moltonel 3x Combo]

On 09/03/2015, Bryce Nesbitt bry...@obviously.com wrote:
 Somehow I come down on the side that railways have enough footprint on the
 current world that
 they belong in OSM proper, unlike say old buildings or former shops.

 A abandoned railway slowly evolves from a mappable way, to a series of
 other things, before disappearing
 completely.   But it leaves significant land use patterns on the waterways,
 roadways and buildings it once ran near.

 I know it's a messy dividing line.  I see it as important context to
 current day mapping.

That's a fair point, but I've seen it pushed beyond reason too many
times. Often it seems that the contributor used an old map to trace
railway=abandoned without glancing at the satellite imagery (no,
there's nothing left of the raillway when a housing estate with a pond
have been built in its location).

Also, if an abandoned railway has evolved into something else, then
it's not an abandoned railway anymore. If you add a highway=cycleway
tag, you should remove the railway=abandoned tag. Lots of real-world
objects evolve while retaining traits from their previous use. In some
cases that trait can be tagged for itself and kept after the evolution
(deconsecrated building=church for example), but in the case of
railways, the only traits that survive are normally bridges, cuttings
and embankments. Those can be mapped for their own sake, without
resorting to railway=abandoned.

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

Re: [Tagging] Blatant tagging for the renderer: bridges abandoned railways

[moltonel 3x Combo]

On 09/03/2015, Warin 61sundow...@gmail.com wrote:
 Possible work around?

 Use the tag man_made=bridge to tag the bridge area?

 Keeps the railway correctly tagged. And places the bridge correctly.

 http://wiki.openstreetmap.org/wiki/Tag:man_made%3Dbridge

 Try that and see if it works.

Not rendered yet :
https://github.com/gravitystorm/openstreetmap-carto/issues/436

That doesn't mean that you shouldn't use man_made=bridge, it's a great
way to map what's there (see also the bridge relation). But it won't
provide your get it rendered by osm-carto fix yet (patches welcome).

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

Re: [Tagging] route=foot

[moltonel 3x Combo]

On 01/03/2015, fly lowfligh...@googlemail.com wrote:
 I just say, that out of the 25,000 objects tagged with route=foot over
 21,000 have been tagged either network=lwn or network=rwn and would be
 better tagged route=hiking as that is the route type for hiking routes.

 In general, I do not like route=foot but I sustain the description on
 the German wiki page and the little passage at the beginning of the
 second table on the English wiki page of route=hiking.

I think that's where the language nuance comes in. To me, hiking is
a special variant of walking. Something linked to sport, or love of
the outdoors. In contrast, route=foot looks like it caters to more
utilitarian reasons, where walking is the mean but not the goal.

The most obvious example being tourist trails to see the attractions
of a city. Tourists would rather do as little walking as possible to
see the different POIs. And it's perfectly reasonable for those routes
to have a network=*. In fact, I'd find any route relation with neither
network=* nor operator=* a bit suspicious.

To sum it up: I feel there's a usefull distinction between route=foot
and route=hiking, they don't have to be merged. However, that
distinction could (as always) do with better documentation.

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

Re: [Tagging] maxwidth vs. maxwidth:physical vs. width

[moltonel 3x Combo]

On 18/02/2015, Colin Smale colin.sm...@xs4all.nl wrote:
 As lots of people frequently point out, what about emergency vehicles?
 They can (often) ignore legal restrictions, but not physical ones:

 if(i_am_an_emergency_vehicle)

  maxfoo = min(maxfoo:physical, maxfoo:legal)

 else

  maxfoo = maxfoo:physical;

The other way around, but yes :)

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

Re: [Tagging] maxwidth vs. maxwidth:physical vs. width

[moltonel 3x Combo]

On 18/02/2015, Martin Koppenhoefer dieterdre...@gmail.com wrote:
 Am 17.02.2015 um 19:57 schrieb moltonel 3x Combo molto...@gmail.com:
 maxfoo = min(maxfoo:physical, maxfoo:legal)

 -1, maxfoo was always defined as a legal restriction so this function should
 go into your data evaluator but not be the rule for the data entering mapper

Allow me to disagree:

* maxheight is defined this way. Having maxwidth defined differently
is asking for trouble.
* The vast majority of consumers only care about min(physical,legal);
expecting them to know about and handle that particular quirk of the
osm schema (instead of simply taking the maxwidth value) is asking for
more trouble.
* There is currently a grand total of 22 maxwidth:physical tags in the
db (12500 maxwidth, 0 maxwidth:legal), and none of them have a
complementary plain maxwidth tag (one could argue that this is poor
tagging, like tagging name:en without name). So there's really no
backward compatibility to be worried about (and this whole thread is
dealing with a theoretical problem, not a practical one).
* I didn't do an exhaustive search, but even looking at maxheight I
didn't find any object where maxfoo isn't = maxfoo:*.

http://overpass-turbo.eu/s/7J5

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

Re: [Tagging] maxwidth vs. maxwidth:physical vs. width

[moltonel 3x Combo]

On 18/02/2015, Tobias Knerr o...@tobias-knerr.de wrote:
 On 18.02.2015 10:39, moltonel 3x Combo wrote:
 Allow me to disagree:

 * maxheight is defined this way. Having maxwidth defined differently
 is asking for trouble.

 I agree with you that we should define all the max* keys in the same
 way. But it would actually make much more sense to achieve that
 standardization by reserving them all for legal restriction. Look at the
 current situation:

 maxwidth:
  legal limit according to all sources
 maxspeed:
  legal limit according to all sources
 maxweight:
  legal limit according to all sources
 maxaxleload:
  legal limit according to all sources
 maxheight:
  legal limit according to infobox,
  min(legal,physical) according to introduction text

 The odd one out is clearly that introduction of the Key:maxheight page.

Fair enough, except that :physical doesn't make sense for speed, and
is pretty much impossible to measure for weight and axleload (or
rather the engineers calculated it, and the legal people took the
value verbatim). Because of that, legal == min(legal,physical) for all
those, so it doesn't make any difference and the simpler phrasing
wins, but the min(A,B) phrasing would be just as accurate.

maxspeed is actually much more complex, with lots of subkeys, and a
routing engine (for example) probably has to take many of them into
account. So a naive rule like maxspeed = min(legal,practical) would
not make sense.

Legal vs physical does make sense for height and width. The fact that
only height got an updated wiki page certainly comes from maxwidth:*
being basically unused.

As you point out, reverting the definition of maxheight to mean
maxheight:legal would make the wiki pages look more consistent. But
it'd make the data less usable. You go ahead and tell the owner of a
damaged vehicle that his satnav should have taken both
max{height,width} and max{height,width}:physical into account, I
prefer to avoid this using the min(legal,physical) definition.

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

Re: [Tagging] maxwidth vs. maxwidth:physical vs. width

[moltonel 3x Combo]

On 16/02/2015, Kytömaa Lauri lauri.kyto...@aalto.fi wrote:
 The width of the vehicle that could use the way can be wider than the way
 itself [...]

Another example where width != maxwidth:physical is a twisty tunnel.
The longer a vehicle is, the more margin it requires to be able to
pass. So a tunnel with width=2.5 could easily have a
maxwidth:physical=2.

Width concerns the feature itself, maxwidth(:physical) concerns the
vehicles using the feature.

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

Re: [Tagging] maxwidth vs. maxwidth:physical vs. width

[moltonel 3x Combo]

On 16/02/2015, Martin Koppenhoefer dieterdre...@gmail.com wrote:
 2015-02-16 10:42 GMT+01:00 Martin Vonwald imagic@gmail.com:
 * maxwidth: this is a legal limitation; nothing wider than the given
   value may use the feature

 +1, there is also the synonym maxwidth:legal (IMHO not advisable, as this
 is the same than the more used maxwidth)

That's what the maxwidth wiki page states, but it is strangely
inconsistent with maxheight. It really should be the same definition
for both, and I think the height variant makes more sense.

maxfoo = min(maxfoo:physical, maxfoo:legal)

Don't assume that legal = physical. For example, many roads have a
default legal max but didn't bother setting a legal limit on
individual chokepoints. When physical != legal, you may want to add
the subkeyed tag for the bigger value (or both), but most data users
will only care about the simple key.

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

Re: [Tagging] Electronic or 'e' cigarettes?

[moltonel 3x Combo]

On 01/02/2015, Tac Tacelosky tac...@gmail.com wrote:
 Another legitimate terms for these shops is a vape shop, and the practice
 of using any sort of electronic cigarette is now referred to as vaping.
 This is a better term than smoking, as the product emits vapors, not
 smoke.

 We are enthusiastic about seeing this term standardized, as many
 jurisdictions do not license or regulate vape shops in the same way they do
 places that sell cigarettes (and thus e-cigarette is a confusing term).
 Our research is often about tobacco shops, and vape shops, because they're
 not licensed, introduce a new wrinkle.

vape is not as established as the various forms of
electronic_cigarette, I don't think it brings any clarity in the OSM
usecase.

Off-topic non-OSM: Sellers of electronic cigarettes have been playing
a naming game to ensure that they are not classified as tobacco, to
avoid the harsh tobacco laws and taxes. But, as less harmfull as this
product may be, they're still an addictive nicotin-based drug with
unwitting consumers. The legislation really should have started by
treating them the same as classic cigarettes and *then* loosen the
rules, not the other way around. But the e-cig lobby is visibly still
playing the naming game everywhere...

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

Re: [Tagging] Tagging Voting system- time for reform?

[moltonel 3x Combo]

On 24/01/2015, Dave Swarthout daveswarth...@gmail.com wrote:
 Nobody votes because it's a borderline pointless endeavor.

I'd like to defend the voting system a bit. In my opinion it's working
fine. The only issue is that people have wrong expectations as to what
voting provides.

As has already been pointed out, there's no such thing as an OSM
authority that can say this is the only correct way to map (and
neither should there be). And the voters are a self-selected,
non-representative, biased population.

So what is voting good for ? I see it as just part of the discussion.
It's easyer for people to vote than to post lenghty arguments on a
mailing list or forum. Is proposition Foo generally accepted ? Look at
taginfo, look at voting, view some current osm data. They're all
important hints which will help you form an opinion. Maybe proposition
Bar has been largely voted against, but I still really prefer it to
the alternative and it seems like *some* people agree with me, so I
take the votes into account but still make my own informed decision.

The make up your own tag in concertation with others philosophy is
deeply ingrained in OSM. Voting is just one of many layers on top of
it. Reforming voting won't change the deeper nature of OSM.

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

Re: [Tagging] Deprecation of associatedStreet-relations

[moltonel 3x Combo]

On 25/01/2015, Marc Gemis marc.ge...@gmail.com wrote:
 My experience is that it is very hard to place every house in the right
 relation before you know the actual address. Especially with corner houses
 and in rural areas where the driveways to the farms do not always connect
 to the street with the address.
 Another problem is that the street endings in OSM might be wrong, so you
 have to move houses from one relation to another after your survey.

 At least that are cases that I have encountered during my surveys. Hope
 that you do not have to do this.

That has happened to me a couple of times (it certainly depends on the
part of the world you're mapping in), but is rare enough that this
workflow is still a big time saver. Changing the relation a house
belongs to in Vespucci is a bit annoying, but stil easy enough that it
can be done at surey time.

One type of armchair mapping error that I do much more often is wrong
splitting of joined buildings. For those, fixing in Vespucci is too
much of a pain so I add a fixme tag on the building instead, and do
a quick post-survey fixes changeset with JOSM.

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