Re: [Tagging] Why is this building not rendered?

[moltonel]

On 16 April 2017 11:54:19 IST, Warin <61sundow...@gmail.com> wrote:
>However on the information available to me ... I could not reliably map
>the extent of the school .. so I would map it as a node only.
>I think this is not regression but removes an assumption (from the 
>present tagging) that the school is limited to the building alone.

IMHO moving the tags from the building to a node is mainly a regression. Data 
users would no longer know that the full building is dedicated to the school 
(for example part of it could be residential/commercial/associative).

There is some logic in your POV that "no information is better than faulty 
information" (removing information about the school's geometry would be better 
than leaving a smaller-than-correct geometry), but if we were following that 
logic we'd hardly be able to contribute any data to OSM. Instead we add 
reasonably-correct data (amenity=school on the building) and later improve 
things.

If you can see that the school encompasses more than the building, draw the 
boundary. If you're not sure of the exact extent of that boundary, add a fixme 
tag or a note. Mapping a school as a node is probably only appropriate if the 
node is the only thing you map.
-- 
Vdp
Sent from a phone.

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

Re: [Tagging] Amphitheatre or outdoor non-sports venue

[moltonel]

On 14 September 2016 09:42:59 GMT+01:00, johnw  wrote:
>after searching the wiki for the correct spelling of amphitheatre
>(oops),  I found: 
>
>https://wiki.openstreetmap.org/wiki/Tag:amenity%3Dtheatre
>
>
>"For tagging amphitheatres
>, open-air or outdoor
>theatres, the Talk page
>
>suggests using theatre:type
>=amphi
>.”
>
>
>
>*sigh*  what is an Amphi? theatre:type=amphitheatre makes more sense,
>and the other types I suggest would be :type=natural and :type=stage. 
>
>looking for input on how to reconcile arts_centre and theatre. 

An art_centre has a much wider scope than a theare. It's not just about plays, 
coursee are held there, etc (see wiki). IMHO an amphitheatre is definitely an 
amenity=theatre, not art_centre.

http://taginfo.openstreetmap.org/keys/theatre%3Atype#values is fairly well 
established, and 'amphi' seems to be a mundane abbrev of 'amphitheatre'
-- 
Vincent Dp

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

Re: [Tagging] leisure=track on areas?

[moltonel]

On 4 August 2016 11:55:05 GMT+01:00, Tom Pfeifer  wrote:
>Warin wrote on 2016/08/04 08:14:
>> On 8/4/2016 3:42 PM, Daniel Koć wrote:
>>> but it appears we don't know how should we treat leisure=track: is
>it a linear object or maybe kind of area?
>>
>> I have seen it both ways.
>
>Yes exactly. The source of the uncertainty was that is used to be
>filled in the former
>mapnik and current carto style, along with other leisure features.

Incidentally, I tagged one yesterday with area=yes and josm warned that 
"area=yes is superfluous for leisure=*". I left the area tag there because in 
my mind it isn't clearly established yet.
-- 
Vincent Dp

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

Re: [Tagging] How to tag: public lands that are accessed by permit?

[moltonel]

On 21 July 2016 12:31:42 GMT+01:00, m...@chrisfleming.org wrote:
>
>In my view access=permit seems like they way to go. Having
>access=private with permit=something adds to the complexity without
>adding value. Keep it simple.

Joining this discussion late, but just as another datapoint, this usecase 
(permit required but routinely granted) matches one I mapped a while ago: a 
pilgrim path in Ireland that goes in part through private land. You need to 
apply for permit at the local abbey (no online form available). I went  with 
access=permit at the time: it seemed to fit very well, without needing a big 
discussion thread :p

http://www.openstreetmap.org/relation/1969406

-- 
Vincent Dp

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

Re: [Tagging] Draft of proposal tag 'sells' for shops..

[moltonel]

On 6 March 2016 08:47:36 GMT+00:00, Ralph Aytoun  
wrote:
>My personal opinion is that this is getting totally out of hand.
>Shops pay a lot of money to advertise their wares and you are stepping
>in 
>and trying to do commercial marketing for free.
>Not only that but who is going to maintain this information? Shops
>rotate 
>their stocks on a seasonal basis. They also stock multiple brands!
>
>So we will end up with tagging ...
>sells:bread:white:medium:Hovis=
>sells:bread:white:thick:Hovis=
>sells:bread:50-50:medium:Hovis=
>sells:bread:white:medium:Own_Brand=
>sells:bread:white:thick:Own_Brand=
>etc. etc. etc.
>
>With this kind of trend we are definitely moving away from the realms
>of 
>sustainable Mapping and creating some kind of stock take for each shop!
>And 
>some of us know that with regard to stock taking even the shops
>themselves 
>are hard pressed to maintain an up-to-date record. So where does that
>leave 
>us two weeks, two months or two years down the line?

I agree that this can get out of hand quickly and become unmaintainable. The 
detail level of some sells:* examples worry me.

But I can see its use for tagging oddities. You'd have the traditional tags 
implying what the place sells, and use the sells tag for exceptions, for 
example:
amenity=pub
sells:alcohol:wine=no
sells:books=yes


-- 
Vincent Dp

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

Re: [Tagging] Proposal to Change Road Classification, Road Surface, Road Condition, and Add Number of Lanes

[moltonel]

On 5 March 2016 21:13:48 GMT+00:00, Martin Koppenhoefer 
 wrote:
>> Am 05.03.2016 um 15:25 schrieb Alberto :
>> 
>> OSM does not establish the difference between inter-urban (rural)
>roads and urban roads (comprising mostly avenues and streets).
>
>
>there are tags in use that allow to make this distinction:
>source:maxspeed (if it's not signed ;-) ) and traffic_sign=city_limit

City limits rarely match the limits of urban areas. On one extreme there are 
multi-city agglomerations, on the other there are rural areas that are inside 
cities, for example in France where there is no "no-city's land", even the 
remotest countryside is part of a 'municipalité'.

That said, I dont see what would be gained in using completely separate highway 
classifications for urban/rural roads. The current scheme applies (as) well to 
both cases. It'd be silly to reclassify a road while it crosses a 'street 
village'. And I'm not looking forward to "where does the urban area start ?" 
debates.
-- 
Vincent Dp

___
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 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 <i...@matthijsmelissen.nl> 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]

On 27 January 2016 10:09:51 GMT+00:00, Martin Koppenhoefer 
 wrote:
>2016-01-27 10:39 GMT+01:00 Marc Gemis :
>
>> France ? The example boundary is in Ireland
>>
>
>
>;-)
>anyway, s/France/Ireland/ and the statement remains. I bet also the
>Irish
>have official names for their administrative units.

Official names are *way tiddyer* in France  ;)

As stated many times already, in this example 'name' comes from an ooc map (and 
the names in there were forcefully assigned by the british rule, in case you're 
hungry for another level of name-correctness debate...), and both 'name_1' and 
'name_2' come from a local who lived there for generations. I had never come 
accross the 'levallyroe' spelling/pronunciation before, but it's on the ooc map 
and census records, so I guess that makes it official and that's why I chose it 
for the 'name' tag. But the other two spellings are absolutely at the same 
level. They have the same source, with no preference given. The only correct 
way to store them is as multiple values of the same key.

I'm happy to discuss the tagging of individual objects (including this 
townland, if you have sources to complement mine), but I'm tired of defending 
the necessity of multiple values and the fact that foo_name is not always 
sufficent or more correct.
-- 
Vincent Dp

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

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

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

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

-- 
Vincent Dp

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

Re: [Tagging] Removing name_1 and alt_name_1 from Wiki

[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] Specifying maxweight, when different weight limits are signed

[moltonel]

On 30 December 2015 18:58:38 GMT+00:00, Marcos Oliveira 
 wrote:
>Do you know if this is a legal limit or if being smaller makes the
>weight
>less spread out which can structurally damage the bridge?
>
>If the first then I'd map the highest value, if the latter then the
>smallest one.

I dont think the legal/physical nature of the restriction shouuld influence 
your tagging (unless you want to use the :physical tag suffix and distinguish 
the two).

When in doubt, err on the side of caution and tag the most restrictive value. 
Use the smallest limit for the maxweight tag and add tags like maxweight:hgv 
for the vehicle-specific limits. See the access tag on the wiki for examples.
-- 
Vincent Dp

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

Re: [Tagging] Wi-Fi or internet access at Stores

[moltonel]

On 13 December 2015 00:08:16 GMT+00:00, Hans De Kryger 
 wrote:
>> What would be the point of tagging non-public Wi-Fi?
>>
>> Do you mean Wi-Fi for customer use only?
>> ​  ​
>My bad i meant ​(wifi_public=yes​)
>​ and i'm not sure that tag would be necessary at all. Public wifi
>should only be tagged.​

Customer-only and non-gratis wifi are arguably not "public" but they are 
mapworthy. And the subtags to express these are internet_access:access and 
internet_access:fee (with the usual values of the access and fee tags).
-- 
Vincent Dp

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

Re: [Tagging] Wi-Fi or internet access at Stores

[moltonel]

On 13 December 2015 12:02:22 GMT+00:00, Richard <ricoz@gmail.com> wrote:
>On Sun, Dec 13, 2015 at 11:22:53AM +, moltonel wrote:
>> Customer-only and non-gratis wifi are arguably not "public" but they
>are mapworthy. And the subtags to express these are
>internet_access:access and internet_access:fee (with the usual values
>of the access and fee tags).
>
>Depends on how you interpret customer-only: I would map internet cafes
>which 
>are customer-only but not hotel wifis which are available only for
>overnight
>guests.

By definition, overnight guests are customers. While some hotels do not mind if 
you come in just for the wifi without even buying a coffee, some will. In my 
experience, most free wifi is actually (intended to be) customers-only, even if 
most osm contributors don't bother to tag it.

>Also would not map hotspots which require eg a monthly subscription.

Do you make a difference between monthly and sorter timespan ? Is tacit 
reconduction the issue ? In any case, the *:fee tag should be used. When you're 
abroad, even a cumbersome signup process might be worth it.
-- 
Vincent Dp

___
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:
>> 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] Handle with care

[moltonel]

On 26 September 2015 19:05:09 GMT+01:00, "André Pirard" 
 wrote:
>It is
>:warning=
>which acts only when that key is changed.
>geometry:warning=  to protect the coordinates of the element
>name:warning=  to protect its name.
>Those tags do not warn against changing other tags.

May I suggest 'edit_warning', or something else that explicit (because a 
'warning' key could be used for so many purposes) ? And use proper namespace 
ordering, ie edit_warning:name=blah rather than name:edit_warning=blah (because 
many keys, like name or phone, are also namespaces that can be followed by 
arbitrary sufixes).

That said, you should open bugs on the various editors as soon as possible to 
discuss with them what they think of such a feature. Unless this tag gets 
editor support, it doesn't bring anything that the already popular 'note' tag 
doesn't give. Sadly, inexperienced mapers are the ones most likely to miss a 
plain 'note' tag, but they are also most likely using iD, whose developers are 
pretty warning-averse...
-- 
Vincent Dp

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

Re: [Tagging] Delete not marked walking routes?

[moltonel]

On 20 September 2015 11:54:00 GMT+01:00, Mateusz Konieczny 
 wrote:
>> Case b) Frequent use and 'the best' route. This would be contentious.
>
>So every mapper may add his favourite route?

That bothers me as well. Even if we restricted ourselves to only published 
routes, we'd open ourselves to a stupidly large number of candidate routes 
("publishing" today has a very very low barrier of entry). And relying on each 
contributor's subjective jugement to decide which routes are mapworthy doesn't 
sound like it can work.

I think that "the trail has to be physicaly waymarked, at least parts of it" is 
a good cutoff point for osm. It has a self-limiting quality and pushes the 
noteworthyness decision on to the local authorities.

Feel free to waymark your favorite trail to make it osm-worthy, and to put 
anything less tangible on your favorite trail-publishing platform instead.
-- 
Vincent Dp

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

On 10 September 2015 13:20:43 GMT+01:00, Joachim  wrote:
>Proposal:
>Define on the wiki page of highway=motorway_link that oneway=* must
>also be tagged for every motorway_link.

Sounds fair.

> If not tagged, the oneway=*
>status of this way is undefined.

You wont gain anything by de-defining the "oneway=no" default value. 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.

>- For routing purposes it is recommended to not route over ways with
>undefined oneway since any assumption may be wrong and it would be
>best to correct the data.

That's a very bad idea. Routers implementing it would skip a motorway exit (and 
lenghten the trip greatly) because of a missing tag. I'd much rather get to the 
exchange, see that the router is suggesting a link i cannot take, and drive 
around to find a nearby link I can use. Still frustrating but less time wasted.

>- In map editors undefined oneway should be displayed as tagging error.

And *that* is the actually usefull thing to do, instead of the proposal. File a 
bug to the major editors and QA tools suggesting to flag motorway links without 
a oneway tag as an warning.

Even better: if the software has the means to do it, flag that warning for any 
object having tag foo but not tag bar, if 95% of foo tags in the db are 
accompanied by a bar tag.
-- 
Vincent Dp

___
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 <matkoni...@gmail.com> wrote:
> On Fri, 11 Sep 2015 12:41:36 +
> moltonel <molto...@gmail.com> 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] Handle with care (was: Accuracy of survey)

[moltonel]

On 9 September 2015 21:46:54 GMT+01:00, "André Pirard" 
 wrote:
>There are various reasons for warning other mappers to be careful about
>their updates.
>I once temporarily overlaid two walking routes to show the effect of
>displaying two sorts of icons.
>Or I left in for a while drawing errors of a plugin as the best way to
>show the author what I talk about.
>Despite a don't touch note explaining why, a good soul passes, not
>reading note and makes a "correction".

Please run experiments like this on a test db, not on the main one. It's easy 
to point your editor to dev.openstreetmap.org for example (quoting from memory, 
not 100% sure). You never know when a data consumer will stumble upon your 
experiment, live or in a downloaded snapshot. Nobody expects osm data to be 
perfect all the time, but there's no point in knowingly making it worse.
-- 
Vincent Dp

___
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] Drafting proposal: use oneway=reversible or create tag?

[moltonel]

On 7 September 2015 17:38:45 GMT+01:00, Volker Schmidt  
wrote:
>tidal
>up to London, depending on tides (and wind). But I would be reluctant
>to
>tag the river's water flow from London downwards as flow_direction=both

Yes, rivers can be tidal without their flow reversing. The water level can rise 
during the rising tide but still flow toward the sea. tidal=yes is a fairly 
common tag.

>Also, one needs more values:
>flow_direction=forward|backward|tide_dependent|operator_controlled|...
>default value: forward

LGTM

I'd advise against any up/down value because the question normaly only arrises 
when the relief is fairly flat.
-- 
Vincent Dp

___
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] Highway proposed/planned distinction

[moltonel]

On 14 July 2015 19:57:30 GMT+01:00, jonat...@bigfatfrog67.me wrote:
Linguistically I would say proposed comes before planned.  Planning
your wedding is not the same as proposing marriage!  

+1

Personally I don't think we should routinely display proposed routes,
because they may never come to reality, but planned routes are ones
that have passed the usual planning discussions and are awaiting
construction, which can sometimes be many months or years, but will
happen, short of a political change of heart.

I think there's a fairly objective criteria that can be used to distinguish 
'planed' from 'proposed' : if the financing has been completed (money has been 
set aside in the budgets and will not be used for something else), then it fits 
the osm definition of planned.

There was some amount of tagging for the renderer shortly after the railway 
rendering changes, but it didn't last long (that i could see) and we now have 
better, more finegrained data. The same would hopefully happen with 
planned/proposed, especially with a clear criteria and less historical 
confusion.
-- 
Vincent Dp

___
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