Re: [Tagging] Increasing voting participation (Was Accepted or rejected?)

[Frederik Ramm]

Everyone,

   I think this is going in the wrong direction. I have just skim-read
this thread but I have the impression that the basic assumption seems to
be "tagging votes are an important core element of how we work at OSM,
so we must increase participation, make tagging votes more widely known,
and translate proposals so that everyone can participate".

It is however not true that tagging votes are an important core element
of how we work; we can do perfectly fine without. Even if certain things
were tagged differently in different parts of the word, that would not
break OpenStreetMap.

Tagging votes are not a big and important thing; in my opinion, they are
not even important enough to warrant a posting to a national-language
mailing list that says "please vote" (hello Bryce). Votes are neither
binding (for editors or renderers), nor are they final. If a vote were
held on something and it later turns out that a much larger proportion
of people than actually participated in the vote dislike the outcome,
then the vote is practically void.

A democratic vote might be a good tool for some things; it is not the
proper tool to decide on tagging in OpenStreetMap. The outcome of a vote
should really be phrased:

"The following 35 people think that this proposal is a good idea and
would recommend using it"

rather than

"This proposal has been accepted"

because the latter really affords the whole process much more relevance
than it actually has.

So please, don't go over board here by trying to force-involve every
mapper in tag votes; they're simply not important enough, and they
*should not be*. Don't try to make them important, lasting, or binding.

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"

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

Re: [Tagging] Increasing voting participation (Was Accepted or rejected?)

[Warin]

On 18/03/2015 6:21 PM, Frederik Ramm wrote:

Everyone,

  The outcome of a vote
should really be phrased:

"The following 35 people think that this proposal is a good idea and
would recommend using it"

rather than

"This proposal has been accepted"

because the latter really affords the whole process much more relevance
than it actually has.


Agree. But I'd resist naming the people, something like this?

"This key:value was supported by 30 people on the OSM tagging group."

? As the proposal page remains on the wiki and can be seen by all there is no 
point in repeating the names.
The number of approval votes gives some idea of the value of the statement.

Unfortunately the status value remains as 'approved'.
Perhaps 'recommended' or 'endorsed' for the status? Even add the number there 
'endorsed by 30'? .. 'supported' may be taken as being rendered so I'd not use 
that.


-
If 'we' want increased participation .. 'we' need to encourage membership.
And encourage new discussions on tags and tagging. No mater how 'inexperienced" 
some view the new member.

As the radius of knowledge increases the circumference of ignorance expands.


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

Re: [Tagging] Increasing voting participation (Was Accepted or rejected?)

[Warin]

On 18/03/2015 5:02 PM, Marc Gemis wrote:


On Tue, Mar 17, 2015 at 9:42 PM, Bryce Nesbitt >wrote:


A separate debate is how to increase voting participation.  making
pending votes more visible in the editing tools could help.


Just some idea:
Translate the proposal in German, French, Spanish and Russian, ... 
(the largest communities outside the English speaking countries)
Let people vote and discuss in their own language. Sum up the votes 
from the different pages.



It is a good idea.
The main problem is that an issue in one place may have been resoled in 
another. So there may need to be some cross flow between the discussions 
when required/requested?


The secondary issue is the translation. I'm afraid I'd be using one of 
those computer translators to do it .. thus there will be some amusement 
.. not a bad thing .. it can be cleaned up once done.



Not everyone is willing/capable to discuss in a foreign language.


Yep. And thus OSM misses out on probably some very good ideas.
And this may well encourage others to make more tags.

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

Re: [Tagging] Accepted or rejected?

[Martin Koppenhoefer]

2015-03-18 0:58 GMT+01:00 Kotya Karapetyan :

> Your rule would mean that with 7/3 would be a rejection while 8/7 an
> approval.
> I suggest to not only bring the logic back but also address this issue.
>



+1, I would like to reflect on the quorum rule. In the end, looking at how
many people map and how many people take part in tagging mailing list
discussions and voting on tags, any number we can reasonably put there will
be ridiculous compared to the number of mappers. On this background there
is not much difference between a vote of 6 people and one of 18. If we want
to stick to the quorum (what does likely make sense to avoid the
theoretical problem of one or two people alone "occupying" useful key or
value names with unusual definitions), I suggest to lower it even more,
like requiring at least 5 positive votes and a 2 third majority of positive
votes (or "not more than one third negative votes").

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

Re: [Tagging] Increasing voting participation (Was Accepted or rejected?)

[Martin Koppenhoefer]

2015-03-18 7:02 GMT+01:00 Marc Gemis :

> Just some idea:
> Translate the proposal in German, French, Spanish and Russian, ... (the
> largest communities outside the English speaking countries)
> Let people vote and discuss in their own language. Sum up the votes from
> the different pages.
>


-1, I doubt this will work, and I think this creates too much overhead.
First I believe it is not feasible, look how many pages for the approved
tags are actually translated. Of course you can have (and there is already)
discussion in different languages, but this doesn't have to be in the wiki
(a wiki is generally not a good platform to discuss stuff, IMHO). Secondly
I think that this will lead to more confusion because people will vote on
different stuff (a translation is always a translation and might bear
language intrinsic limitations, proposals get changed in the time until
voting, this is also desirable, but translations would have to keep up,
something we don't even achieve for the definition pages of well
established and frequently used "important" tags).

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

Re: [Tagging] Increasing voting participation (Was Accepted or rejected?)

[Martin Koppenhoefer]

2015-03-18 9:15 GMT+01:00 Warin <61sundow...@gmail.com>:

> "The following 35 people think that this proposal is a good idea and
>> would recommend using it"
>>
>> rather than
>>
>> "This proposal has been accepted"
>>
>> because the latter really affords the whole process much more relevance
>> than it actually has.
>>
>
> Agree. But I'd resist naming the people



actually I think naming the people is important, because this way you can
decide if this has been looked through by someone you have confidence in.
This is a way people can get reputation and others can decide based on
their preferences and the reputation the people that voted have gained or
lost from their personal point of view. If this was anonymous the naked
number would be much less useful.

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

Re: [Tagging] Increasing voting participation (Was Accepted or rejected?)

[Pieren]

On Wed, Mar 18, 2015 at 8:21 AM, Frederik Ramm  wrote:

I said few years ago that "vote" should be replaced by "opinion poll".
This hasn't change in my view,

> It is however not true that tagging votes are an important core element
> of how we work; we can do perfectly fine without.

Yes and no. It is not a core element but getting feedbacks before
formalising a new tag is better than nothing even locally (like
imports, no ?). But it is true that a tag "approved in the wiki"
doesn't avoid bad tags. See the endless discussions around
"smoothness" or  "highway=ford" on ways or the use of abstruse
abbreviations for the non-natives like "ngo", "aed" or "asl".

> Even if certain things
> were tagged differently in different parts of the word, that would not
> break OpenStreetMap.

Only a fraction of us is thinking like this. Using 2, 3 or 10
different tags for the exact same thing is surely providing a job for
OSM consultants but is creating unnecessarily complexity for
contributors and data consumers. Wikipedia wouldn't accept two
articles on the exact same topic. It is our responsibility to keep the
project usable, even for new data consumers.

> "The following 35 people think that this proposal is a good idea and
> would recommend using it"
> rather than
> "This proposal has been accepted"

True.

> So please, don't go over board here by trying to force-involve every
> mapper in tag votes; they're simply not important enough, and they
> *should not be*. Don't try to make them important, lasting, or binding.

But the wiki is currently giving the impression that the "vote
process" is formal and important. So something has to be changed.

Btw, I don't think that translations will help. Some proposals don't
have many feedbacks simply because the interest is not shared by a
large group.

Pieren

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

Re: [Tagging] Deleting private objects in private spaces

[Janko Mihelić]

So theoretically, we shouldn't ban anything from being mapped (or almost
anything). But practically, we don't want people being routed to the
nearest toilet that is actually inside a power plant. How do we fix this?

One way could be to add a prefix like "private:"
 to anything that is by default public. So, private:amenity=toilette, or
private:amenity=waste_disposal. Then, add an operator tag to it, like,
"operator=Massachusetts Electric Company". If you find yourself inside an
area that has "operator=Massachusetts Electric Company", then the router
can safely assume you can access anything with the "private:" prefix and a
"operator=Massachusetts Electric Company" tag.


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

Re: [Tagging] Deleting private objects in private spaces

[Martin Koppenhoefer]

2015-03-18 11:28 GMT+01:00 Janko Mihelić :

> So theoretically, we shouldn't ban anything from being mapped (or almost
> anything). But practically, we don't want people being routed to the
> nearest toilet that is actually inside a power plant. How do we fix this?



if that toilet is tagged with amenity=toilets it is a tagging error and the
tag should be fixed or the object completely removed. The toilets tag is
for "toilet[s] open to the public".


If you find yourself inside an area that has "operator=Massachusetts
> Electric Company", then the router can safely assume you can access
> anything with the "private:" prefix and a "operator=Massachusetts Electric
> Company" tag.
>
>

not at all. You can't assume it.
Also that scheme would require really a lot of tags to be added because it
seems it doesn't rely on inheritance from encompassing objects.

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

Re: [Tagging] Increasing voting participation (Was Accepted or rejected?)

[Martin Koppenhoefer]

2015-03-18 11:09 GMT+01:00 Pieren :

>  the use of abstruse
> abbreviations for the non-natives like "ngo", "aed" or "asl".
>


+1



>
> > Even if certain things
> > were tagged differently in different parts of the word, that would not
> > break OpenStreetMap.
>
> Only a fraction of us is thinking like this. Using 2, 3 or 10
> different tags for the exact same thing is surely providing a job for
> OSM consultants but is creating unnecessarily complexity for
> contributors and data consumers.
>


this is only true if they want to have coverage of different parts of the
world or map in different parts of the world, because it seems as if Fred
asumed that inside these "parts" the tags would have been used
consistently. Generally, having several tags meaning the same thing is not
a problem, using the same tag with different meanings is a problem.

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

Re: [Tagging] Accepted or rejected?

[Pieren]

On Tue, Mar 17, 2015 at 3:04 PM, Kotya Karapetyan  wrote:

> I propose to clarify it by changing the recommended number of votes in
> https://wiki.openstreetmap.org/wiki/Proposed_features#Approved_or_rejected
> from "...8 unanimous approval votes or 15 total votes with a majority
> approval..."
> to "...8 or more unanimous approval votes or 10 or more total votes with
> more than 74 % approval...".
> This will not change anything in terms of the ongoing discussion of how the
> approval influences other things. So the discussion can continue. But we'd
> introduce some mathematical logic in the process.

-1
The main criticism about "votes" is the "approved" status and the
small amount of participants, not percentage of approvals. So change
the status name and increase the quorum, not the opposite. It's also
not a problem to keep the "vote" open for a long time.

Pieren

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

Re: [Tagging] Deleting private objects in private spaces

[Janko Mihelić]

2015-03-18 11:38 GMT+01:00 Martin Koppenhoefer :

if that toilet is tagged with amenity=toilets it is a tagging error and the
> tag should be fixed or the object completely removed. The toilets tag is
> for "toilet[s] open to the public".
>

Well, it is a toilet, and it is an amenity, although a private one. So why
not private:amenity=* or maybe amenity:private=* ?

Also that scheme would require really a lot of tags to be added because it
> seems it doesn't rely on inheritance from encompassing objects.
>

What new tags do you speak of? I didn't quite understand. Did you mean we
should invent an access=* tag that is by it's nature inherited from
encompassing objects?

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

Re: [Tagging] Deleting private objects in private spaces

[Martin Koppenhoefer]

2015-03-18 11:52 GMT+01:00 Janko Mihelić :

> if that toilet is tagged with amenity=toilets it is a tagging error and
>> the tag should be fixed or the object completely removed. The toilets tag
>> is for "toilet[s] open to the public".
>>
>
> Well, it is a toilet, and it is an amenity, although a private one. So why
> not private:amenity=* or maybe amenity:private=* ?
>


yes, you could do that (I doubt it will be something a lot of mappers will
map, at least not around here), my comment was referring to your question
"we don't want people being routed to the nearest toilet that is actually
inside a power plant. How do we fix this?". If either approach is used (not
mapping at all, or prefixing "private"), than we will not have to fix
anything, I just wanted to point out that already at the status quo,
mapping a private toilet inside a power plant with amenity=toilets is an
error.



>
> Also that scheme would require really a lot of tags to be added because it
>> seems it doesn't rely on inheritance from encompassing objects.
>>
>
> What new tags do you speak of? I didn't quite understand. Did you mean we
> should invent an access=* tag that is by it's nature inherited from
> encompassing objects?
>


It would require us to add operator tags to every single object inside
another object with the same operator tag, if I got you right.

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

Re: [Tagging] Deleting private objects in private spaces

[Janko Mihelić]

2015-03-18 12:15 GMT+01:00 Martin Koppenhoefer :

>

> It would require us to add operator tags to every single object inside
> another object with the same operator tag, if I got you right.
>

Only to the ones that are by default used by public, so toilets,
waste_disposals, and so on.  But they are already mapped wrong, so
something has to be done. Adding a "private:" prefix and operator=* tag is
one idea, maybe there is a cleaner way.

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

Re: [Tagging] Increasing voting participation (Was Accepted or rejected?)

[Martin Vonwald]

2015-03-18 8:21 GMT+01:00 Frederik Ramm :

> "The following 35 people think that this proposal is a good idea and
> would recommend using it"
>
> rather than
>
> "This proposal has been accepted"
>

+1 (thousand)


I already decided some time ago, that I will not put any of my proposal up
for voting any more, but instead allow mappers to add themselves to a list
of "supporters". This feels much more osm-ish to me.

If you like a proposal, use it. If you don't like it, don't use it - and
preferable come up with something better.

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

Re: [Tagging] Deleting private objects in private spaces

[jonathan]

Am I missing something here?  What's the matter with the current schema? If it 
is essential that a toilet in a power plant is mapped then why not 
amenity=toilet and access=private? 


Or a better example, a toilet in a train station that is for staff only 
amenity=toilet access=private or access=official?


Where’s the problem you're trying to fix?






Jonathan

---
http://bigfatfrog67.me





From: Janko Mihelić
Sent: ‎Wednesday‎, ‎18‎ ‎March‎ ‎2015 ‎11‎:‎30
To: Tag discussion, strategy and related tools







2015-03-18 12:15 GMT+01:00 Martin Koppenhoefer :




 




It would require us to add operator tags to every single object inside another 
object with the same operator tag, if I got you right.





Only to the ones that are by default used by public, so toilets, 
waste_disposals, and so on.  But they are already mapped wrong, so something 
has to be done. Adding a "private:" prefix and operator=* tag is one idea, 
maybe there is a cleaner way.



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

Re: [Tagging] Increasing voting participation (Was Accepted or rejected?)

[Markus Lindholm]

On 18 March 2015 at 08:21, Frederik Ramm  wrote:
> So please, don't go over board here by trying to force-involve every
> mapper in tag votes; they're simply not important enough, and they
> *should not be*. Don't try to make them important, lasting, or binding.

+1

A thought, how difficult would it be to include in the wiki-page how
many different mappers have actually used a specific tag. Perhaps via
TagInfo.

/Markus

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

Re: [Tagging] Increasing voting participation (Was Accepted or rejected?)

[Martin Koppenhoefer]

2015-03-18 8:21 GMT+01:00 Frederik Ramm :

> Don't try to make them important, lasting, or binding.
>


somehow they are lasting. The definition that gets voted is typically the
same that will be in use for some time. Then there will be objects in the
database which are tagged according to that definition, and trying to
change the definition will likely provoke resistance by those that have
been using the old definition. Only in a few cases there will be so many
problems that people will happily change what is there.

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

Re: [Tagging] Increasing voting participation (Was Accepted or rejected?)

[Martin Vonwald]

2015-03-18 12:47 GMT+01:00 Markus Lindholm :

> A thought, how difficult would it be to include in the wiki-page how
> many different mappers have actually used a specific tag. Perhaps via
> TagInfo.
>


This in fact would be a very helpful information! Although - please
everyone correct me if I'm wrong - the numbers from taginfo are not what we
want: as far as I know, taginfo shows the number of mappers, that added or
changed(!) an object with a given tag. Much more meaningful would be the
number of mappers, that actually added a specific tag. This is much harder
to determine and even this number would be biased, because of way-splits.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Accepted or rejected?

[Kotya Karapetyan]

On Wed, Mar 18, 2015 at 11:51 AM, Pieren  wrote:

> -1
> The main criticism about "votes" is the "approved" status and the
> small amount of participants, not percentage of approvals. So change
> the status name and increase the quorum, not the opposite. It's also
> not a problem to keep the "vote" open for a long time.
>

The voting time is a separate discussion all together. In principle, we
could replace the approved/rejected status with supported/not-supported.
When a mapper is looking for a tag, he will see not only the amount of
uses, but also the level of support (and also for the negative votes—the
reasoning). This will make him able to decide whether or not he wants to
use that tag.

We can therefore do three things now:
- Leave everything as is and continue the discussion.
- Correct the math by voting for my proposal and then continue the
discussion
- Develop a new formula first.

The current situation is that there are open proposals, so in my opinion it
would help to at least resolve the unclarity we agreed on.

So just to repeat: I agree with the whole argument about the drawbacks of
the current discussion and voting system. But until we have a better one
let's at least make the current one not self-contradictory. The discussion
may take forever and not actually result in anything. Let's make the first
change for the better now, and then try to make it great.

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

Re: [Tagging] Deleting private objects in private spaces

[Martin Koppenhoefer]

2015-03-18 12:30 GMT+01:00 Janko Mihelić :

> It would require us to add operator tags to every single object inside
>> another object with the same operator tag, if I got you right.
>>
>
> Only to the ones that are by default used by public, so toilets,
> waste_disposals, and so on.
>


the operator doesn't tell you anything about access rights, property
structure, "publicness" etc.
It is about the entity _operating_ a feature / object / thing.

There are lots of public things that are operated by private companies,
even more if it is about "open to the public" like in the case of toilets.

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

Re: [Tagging] waterway=lock_gate - is it only for nodes?

[Richard Z.]

On Tue, Mar 17, 2015 at 04:31:12PM +, Malcolm Herring wrote:
> On 17/03/2015 16:06, Brad Neuhauser wrote:
> >Is there something I'm missing?
> 
> No, you have spotted the fact that (as always!) that the documentation is
> unfinished. I had done it on this page:
> http://wiki.openstreetmap.org/wiki/OpenSeaMap/INT-1_Cross_Reference but I
> need to add notes/links on the other pages to direct people to the
> appropriate tag:* and key:* Wiki pages.

so should for example the OpenSeaMap tagging for bridges become
deprecated?

Richard

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

Re: [Tagging] Deleting private objects in private spaces

[Martin Koppenhoefer]

2015-03-18 12:44 GMT+01:00 :

> Am I missing something here?  What's the matter with the current schema?
> If it is essential that a toilet in a power plant is mapped then why not
> amenity=toilet and access=private?




according to the current schema you cannot tag like this (and I don't want
to change it). amenity=toilets is for a toilet open to the public. point.
You cannot add a private=only or access=private or similar to change its
meaning. That's very similar to amenity=drinking_water drinkable=no, don't
do it. It's an oxymoron.

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

Re: [Tagging] Accepted or rejected?

[Martin Koppenhoefer]

2015-03-18 12:55 GMT+01:00 Kotya Karapetyan :

> - Develop a new formula first.
>


I'd prefer to require something like "not more than x percent negative
votes" rather than "at least y percent positive votes", because when
requiring a percentage of positive votes all abstentions count like
negative votes.

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

Re: [Tagging] Language - was Accepted or rejected?

[Kotya Karapetyan]

Having lived in Russia and Germany for quite a while, I can confirm that
the language barrier definitely plays a strong role. A lot of people in
Russia will never use the English-language internet at all. I think the
same holds for France, Spain and Italy, to a lesser extent for Germany. In
the Netherlands where I live now the average level of English is very good;
however a lot of people (even working in international companies) still
barely speak English and will definitely find it hard to participate in
non-Dutch discussions.

Regarding the culture, I don't think it makes participation difficult due
to understanding. However, each culture will have mapping-relevant
differences. In that respect, it would be difficult for people from other
cultures to follow.

A good example would be a Russian-OSM discussion of how to tag street names
in terms of the word order. It would be irrelevant in English or German,
but in Russian you can say "Улица Пушкина" and "Пушкина улица". Both are
perfectly understandable for a Russian speaker, the difference is also
clear and relevant for sorting and search. However both are translated the
same into English or German.

Besides that, some things probably only exist in some countries. Say,
discussing volcano tagging in German may be less relevant than doing the
same in Icelandic.

Note that now we are approaching the OSM internationalization consequences
rather than just the question of mailing list discussions.

Cheers,
Kotya


On Wed, Mar 18, 2015 at 7:54 AM, Marc Gemis  wrote:

>
> On Wed, Mar 18, 2015 at 7:44 AM, David Bannon 
> wrote:
>
>> Marc, do you find the English speakers here anything less than
>> supporting ?  What about use of expressions or references to popular
>> culture, does that make it harder do you think ?
>>
>
> No, I have no problems with the English speaking community myself, but I'm
> lucky to be rather fluent in English. And I learn new words as I follow the
> mailing lists :-).
> On the other hand, I also follow lists in German and French, but I am very
> reluctant to participate in those discussions, as my language skills are
> not good enough for that.
> So I imagine that this is the case for other people and English.
>
> | And thats a pretty good point. But to fork off each discussion onto a
> | new language list would fracture the discussion. We'd need a person
>
> totally agree with that. But right now, you also see that proposals are
> made in local communities that never make it to the general mailing list.
> The Lübeck bicycle tagging scheme comes to mind.
> and look at the wiki pages in German. I took a lot of historic or animal
> related tagging from there, because there is no English page for those
> topics.
>
> Unfortunately I have no solution for this, I can only regret that
> participation to the tagging mailing list is for some limited by language
> knowledge.
>
> regards
>
> m
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[moltonel 3x Combo]

On 18/03/2015, Frederik Ramm  wrote:
> So please, don't go over board here by trying to force-involve every
> mapper in tag votes; they're simply not important enough, and they
> *should not be*. Don't try to make them important, lasting, or binding.

+1 to all that. While I think that "voting" is very usefull, I think
the whole concept of "accepting" a proposal (all the related arguments
about voter thresholds) should be scraped entirely.

Instead, how about revisiting the purpose of proposals pages vs key/tag pages :
* key/tag pages would document the actual use (mainly observed via taginfo)
* proposal pages would document a desired use (and include the current
list of supporters/opponents)
* ideally both pages would reference each other (many to many), maybe
using a "used/encouraged/discouraged by " template
* key/tag pages could be kept up to date fairly objectively
* proposal voters should put the page on their watchlist, in case a
change in the proposal changes their opinion
* proposals should only be "end-of-lifed" if there is near-unanimous
opposition and near-zero actual usage

This should clarify the old question of whether the wiki does/should
document usage or intent. It'll allow competing proposals to coexist
more visibly. It keeps the interesting "opinion poll" use of voting,
while removing the obnoxious "proposal is ready ! vote now so that we
can start using it !" calls.

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

Re: [Tagging] Accepted or rejected?

[Friedrich Volkmann]

On 18.03.2015 07:29, David Bannon wrote:
>> And amazing how many people vote, compared to those that take part in
>> the discussion.
> 
> Indeed. I find that strange. I'd never vote on something I did not have
> an opinion on. And, as you lot know, if I have an opinion, I share it !
> 
> Maybe people just watch the chatter and make up their minds
> accordingly ?  Or do people who are not tagging list subscribers watch
> the wiki and vote when something interesting appears ?

Many people lack the time to watch the chatter, let alone participate.
Mailing lists such as this one demand a lot of time. How is someone who has
a daytime job and a family and who goes around mapping in his spare time
supposed to also spend 2 hours a day participating in mailing lists and web
forums? That's simply impossible!

For the same reason, I think that proposals should stay in "proposed" state
for at least 2 months, and that voting should also be extended to at least
one month, unless the topic of the proposal is urgent for some reason. Most
mappers don't read this mailing list, but they come across a proposal when
searching the wiki. E.g. when someone wishes to map a beehive he's seen this
morning, he'll search the wiki and he will find Proposed features/apiary.
This is a very good proposal, because it lists various possible tags so that
people can compare and make up their mind. A 2-week voting period after a
2-week discussion period obviously would have messed it up.

-- 
Friedrich K. Volkmann   http://www.volki.at/
Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria

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

Re: [Tagging] Increasing voting participation (Was Accepted or rejected?)

[fly]

Am 18.03.2015 um 12:55 schrieb Martin Vonwald:
> 2015-03-18 12:47 GMT+01:00 Markus Lindholm :
> 
>> A thought, how difficult would it be to include in the wiki-page how
>> many different mappers have actually used a specific tag. Perhaps via
>> TagInfo.
>>
> 
> 
> This in fact would be a very helpful information! Although - please
> everyone correct me if I'm wrong - the numbers from taginfo are not what we
> want: as far as I know, taginfo shows the number of mappers, that added or
> changed(!) an object with a given tag. Much more meaningful would be the
> number of mappers, that actually added a specific tag. This is much harder
> to determine and even this number would be biased, because of way-splits.

Exactly, you need to use more of the history, as how do you tread
replaced objects like node -> area ?

The first author of an object does not have to be the one who introduced
the tag.

Seems to be really complex.

Cheers fly


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

Re: [Tagging] Deleting private objects in private spaces

[Janko Mihelić]

2015-03-18 12:58 GMT+01:00 Martin Koppenhoefer :

>
> the operator doesn't tell you anything about access rights, property
> structure, "publicness" etc.
>
It is about the entity _operating_ a feature / object / thing.
>

It doesn't, but it tells you who decides on those things. That's as much
detail an average mapper is going to get. This is private
(private:amenity=*), but if you want to use it, ask the operator
(operator=*).

There are lots of public things that are operated by private companies,
> even more if it is about "open to the public" like in the case of toilets.
>

You can tag an operator on public items too, but it's not as useful as with
private objects because you don't care who operates it as long as you can
use it at will.

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

Re: [Tagging] Increasing voting participation (Was Accepted or rejected?)

[fly]

Am 18.03.2015 um 09:26 schrieb Warin:
> On 18/03/2015 5:02 PM, Marc Gemis wrote:
>>
>> On Tue, Mar 17, 2015 at 9:42 PM, Bryce Nesbitt > >wrote:
>>
>> A separate debate is how to increase voting participation.  making
>> pending votes more visible in the editing tools could help.
>>
>>
>> Just some idea:
>> Translate the proposal in German, French, Spanish and Russian, ...
>> (the largest communities outside the English speaking countries)
>> Let people vote and discuss in their own language. Sum up the votes
>> from the different pages.

-1

> It is a good idea.
> The main problem is that an issue in one place may have been resoled in
> another. So there may need to be some cross flow between the discussions
> when required/requested?
> 
> The secondary issue is the translation. I'm afraid I'd be using one of
> those computer translators to do it .. thus there will be some amusement
> .. not a bad thing .. it can be cleaned up once done.

+1

>> Not everyone is willing/capable to discuss in a foreign language.
> 
> Yep. And thus OSM misses out on probably some very good ideas.
> And this may well encourage others to make more tags.

So, we need some mediators to help to break the language barrier. People
willing to help with English or even take over ideas and make proposals.

I could understand if a proposal is first written in a language
different than English and later translated into English but the wiki
itself needs lots of work on much more important pages than translating
proposals in multiple languages.


One thing for creators of proposals which are not voted on and everybody
else would be to make the transfer to an official wiki page once the tag
is in major use. Then translation can start.

cu fly


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

Re: [Tagging] Deleting private objects in private spaces

[John Willis]

I agree with Martin on not changing the definition of tags where public access, 
or a subset of the public (customers) is inherent in the tags definition 
through tag modifiers. 

But everyone is envisioning a future where information about private facilities 
would eventually become part of OSM - either by those private entities or their 
employees officially or unofficially adding the data, a person or visitor from 
the public adding it because it is visible, or a mapper adding it in for 
completeness, such as for indoor space mapping. 

Although currently impractical for rendering, these kind of issues will pop up 
as long as there is no schema to handle these circumstances (beyond saying 
"no"), so we should try to at least come up with a tagging scheme for purely 
private objects if mappers insist on tagging them, as simply appending 
"private:" on existing public tags is not preferred, though the simplest to 
execute and avoids having to redefine everything in the world again. 

When it comes to visible facilities, especially commercial and industrial 
facilities of access, we can and do easily map and tag many things with the 
current tags that are absolutely private, so to speak - industrial facilities, 
private roads, etc - but there is no equivalent tags for certain "defined by 
public access" tags like toilets, water fountains, etc:   Maybe those amenities 
that are defined by their public access nature will eventually need a private 
counterpart. 

Javbw 

> On Mar 18, 2015, at 9:03 PM, Martin Koppenhoefer  
> wrote:
> 
> 
> 2015-03-18 12:44 GMT+01:00 :
>> Am I missing something here?  What's the matter with the current schema? If 
>> it is essential that a toilet in a power plant is mapped then why not 
>> amenity=toilet and access=private?
> 
> 
> 
> according to the current schema you cannot tag like this (and I don't want to 
> change it). amenity=toilets is for a toilet open to the public. point. You 
> cannot add a private=only or access=private or similar to change its meaning. 
> That's very similar to amenity=drinking_water drinkable=no, don't do it. It's 
> an oxymoron.
> 
> Cheers,
> Martin
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] waterway=lock_gate - is it only for nodes?

[Malcolm Herring]

On 18/03/2015 11:58, Richard Z. wrote:

so should for example the OpenSeaMap tagging for bridges become
deprecated?


Not deprecated, but considered on a case-by-case basis. It is a question 
of whether important navigation information would be deleted if the 
seamark tags were removed. In the case of bridges, the safe air draft 
and beam are important attributes that should be kept, but a bridge that 
is absent those seamark attribute tags need not carry the 
"seamark:type=bridge" tag.



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

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

[Martin Vonwald]

2015-03-18 14:14 GMT+01:00 moltonel 3x Combo :

> On 18/03/2015, Frederik Ramm  wrote:
> > So please, don't go over board here by trying to force-involve every
> > mapper in tag votes; they're simply not important enough, and they
> > *should not be*. Don't try to make them important, lasting, or binding.
>
> +1 to all that. While I think that "voting" is very usefull, I think
> the whole concept of "accepting" a proposal (all the related arguments
> about voter thresholds) should be scraped entirely.
>
> Instead, how about revisiting the purpose of proposals pages vs key/tag
> pages :
> * key/tag pages would document the actual use (mainly observed via taginfo)
> * proposal pages would document a desired use (and include the current
> list of supporters/opponents)
> * ideally both pages would reference each other (many to many), maybe
> using a "used/encouraged/discouraged by " template
> * key/tag pages could be kept up to date fairly objectively
> * proposal voters should put the page on their watchlist, in case a
> change in the proposal changes their opinion
> * proposals should only be "end-of-lifed" if there is near-unanimous
> opposition and near-zero actual usage
>
> This should clarify the old question of whether the wiki does/should
> document usage or intent. It'll allow competing proposals to coexist
> more visibly. It keeps the interesting "opinion poll" use of voting,
> while removing the obnoxious "proposal is ready ! vote now so that we
> can start using it !" calls.
>

Very good ideas and it would bring the original intention of OSM back into
the play: the numbers count and not the two-and-a-half people putting a
line starting with "yes" somewhere in the wiki.

Full support for this at least from my side.

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

Re: [Tagging] Language - was Accepted or rejected?

[Martin Koppenhoefer]

> Am 18.03.2015 um 13:17 schrieb Kotya Karapetyan :
> 
> Note that now we are approaching the OSM internationalization consequences 
> rather than just the question of mailing list discussions.


I believe it is generally difficult to decide on English tags when you don't 
speak English. 

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

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

[Martin Koppenhoefer]

> Am 18.03.2015 um 14:14 schrieb moltonel 3x Combo :
> 
> Instead, how about revisiting the purpose of proposals pages vs key/tag pages 
> :
> * 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



> * proposal pages would document a desired use (and include the current
> list of supporters/opponents)


+1



> * ideally both pages would reference each other (many to many), maybe
> using a "used/encouraged/discouraged by " template


+1


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

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?


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


see previous comment 
also, I'd probably have to spend all day checking tag definition pages then ;-)


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

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

Re: [Tagging] Accepted or rejected?

[Tobias Knerr]

On 17.03.2015 15:04, Kotya Karapetyan wrote:
> I propose to clarify it by changing the recommended number of votes
> in https://wiki.openstreetmap.org/wiki/Proposed_features#Approved_or_rejected
> from ".../8 unanimous approval votes/ /or //15 total votes with a
> majority approval.../"
> to "/...8 or more //unanimous approval votes or 10 or more total votes
> with more than 74 % approval...//"./
> This will not change anything in terms of the ongoing discussion of
> /how/ the approval influences other things. So the discussion can
> continue. But we'd introduce some mathematical logic in the process.

+1

I think it's not ideal that this would make it easier to accept
proposals with very few voters (e.g. a 8:2 majority), so I would prefer
a higher quorum (e.g. 15). But in my opinion it's still acceptable, and
better than no change.


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

Re: [Tagging] Deleting private objects in private spaces

[Martin Koppenhoefer]

> Am 18.03.2015 um 14:47 schrieb John Willis :
> 
> simply appending "private:" on existing public tags is not preferred, though 
> the simplest to execute and avoids having to redefine everything in the world 
> again. 


I think prefixing private: is a viable idea, it can be easily filtered out when 
you don't want these, and it avoids misinterpretations

cheers 
Martin 
___
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  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] Increasing voting participation (Was Accepted or rejected?)

[Friedrich Volkmann]

On 18.03.2015 14:36, fly wrote:
> Am 18.03.2015 um 12:55 schrieb Martin Vonwald:
>> 2015-03-18 12:47 GMT+01:00 Markus Lindholm :
>>
>>> A thought, how difficult would it be to include in the wiki-page how
>>> many different mappers have actually used a specific tag. Perhaps via
>>> TagInfo.
>>
>> This in fact would be a very helpful information! Although - please
>> everyone correct me if I'm wrong - the numbers from taginfo are not what we
>> want: as far as I know, taginfo shows the number of mappers, that added or
>> changed(!) an object with a given tag. Much more meaningful would be the
>> number of mappers, that actually added a specific tag. This is much harder
>> to determine and even this number would be biased, because of way-splits.
> 
> Exactly, you need to use more of the history, as how do you tread
> replaced objects like node -> area ?

That would be easy if editors had implemented the origin=* key as proposed
in http://wiki.openstreetmap.org/wiki/Proposed_features/origin.

-- 
Friedrich K. Volkmann   http://www.volki.at/
Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria

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

Re: [Tagging] relation type for raceways

[Werner Hoch]

Hi,

Am Montag, den 16.03.2015, 20:04 -0400 schrieb Richard Welty:
> as i go forward mapping raceways in north america, one of the
> issues is modeling multi configuration courses such as Watkins
> Glen and Lime Rock.
> 
> one solution is to use route relations, and add a new
> route type,
> 
> route=raceway


There is type=circuit
http://wiki.openstreetmap.org/wiki/Relations/Proposed/Circuit

example (Monaco)
http://www.openstreetmap.org/relation/148194

It is used about 60 times in OSM.


> in this model, i would use forward and backward roles where
> necessary. right now the best example of this i have is of
> my model of the Thompson road courses over the years at
> Thompson Speedway in Connecticut, which is in OHM. some
> sections of the raceway were used in different directions in
> different variations of the course, hence the need for
> forward & backward.

Is in the proposal, have a look at it.

Regards
Werner



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

Re: [Tagging] relation type for raceways

[Richard Welty]

On 3/18/15 2:20 PM, Werner Hoch wrote:

> There is type=circuit

> http://wiki.openstreetmap.org/wiki/Relations/Proposed/Circuit

> example (Monaco) http://www.openstreetmap.org/relation/148194 It is
> used about 60 times in OSM.
that's not bad. i'd probably want to add some other roles,
perhaps paddock & false_grid (or their UK equivalents as
i'm not sure if they use the same terms.) anyone know why this
proposal hasn't gone forward?

richard

-- 
rwe...@averillpark.net
 Averill Park Networking - GIS & IT Consulting
 OpenStreetMap - PostgreSQL - Linux
 Java - Web Applications - Search




signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Increasing voting participation (Was Accepted or rejected?)

[Bryce Nesbitt]

On Wed, Mar 18, 2015 at 12:21 AM, Frederik Ramm  wrote:
>
> It is however not true that tagging votes are an important core element
> of how we work; we can do perfectly fine without. Even if certain things
> were tagged differently in different parts of the word, that would not
> break OpenStreetMap.


-1

I disagree with the sentiment.  The value of the vote *itself* is minimal.

But the value of the voting *process* is very high.  Broad perspectives
during the draft/rfc and voting phase
can vastly improve tagging, and set a pattern others will follow.

---
Even really bad tagging ideas (such as denotation="cluster") get widely
copied. The initial patterns set matter, such as cow tracks lead to dirt
roads, lead to railways, then settlements and main streets.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Accepted or rejected?

[Kotya Karapetyan]

On Wed, Mar 18, 2015 at 1:13 PM, Martin Koppenhoefer  wrote:

> I'd prefer to require something like "not more than x percent negative
> votes" rather than "at least y percent positive votes", because when
> requiring a percentage of positive votes all abstentions count like
> negative votes.
>
>

Martin,

Do we have abstention possible at all? The voting system currently only
implements "yes" and "no": https://wiki.openstreetmap.org/wiki/Template:Vote
.
If we had abstention, I would have rather counted it as non-supporting. A
proposal where people don't care or object is not a good one IMO.

However, I wouldn't mind changing it, since, as it is, there would be no
difference. To not re-vote this change, let's accept it first, and then we
can improve it further.

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

Re: [Tagging] Language - was Accepted or rejected?

[Kotya Karapetyan]

On Wed, Mar 18, 2015 at 3:58 PM, Martin Koppenhoefer  wrote:

> I believe it is generally difficult to decide on English tags when you
> don't speak English.
>

I tend to disagree. A lot of people would be able to use the words
"temperature" or "reception desk". The same people however may not feel
comfortable following an extensive discussion let alone contributing to it.
Programmers use a lot of English words in their code, which doesn't mean
they can use the very same words in real life.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Accepted or rejected?

[Andreas Goss]

It is amazing to see how few people participate in this discussion and
vote compared to the number of mappers.


STOP USING MAILINGLISTS!!!

Those things might be nice for some tech savy people, but for everybody 
else it's just as mess and feels like spam.


We are 100x more productive in the German Forum than on this or the de 
list and have much more participation...


__
openstreetmap.org/user/AndiG88
wiki.openstreetmap.org/wiki/User:AndiG88‎


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

[Tagging] Revisiting proposal/voting scheme

[Kotya Karapetyan]

On Wed, Mar 18, 2015 at 3:06 PM, Martin Vonwald 
 wrote:

> Very good ideas and it would bring the original intention of OSM back into
> the play: the numbers count and not the two-and-a-half people putting a
> line starting with "yes" somewhere in the wiki.
>
>
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.


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.

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


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

Please comment.

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

Re: [Tagging] Revisiting proposal/voting scheme

[Kotya Karapetyan]

On Wed, Mar 18, 2015 at 9:46 PM, Bryce Nesbitt  wrote:

> +1 on showing the vote and discussion in the final page.
>
> And I guess +1 on the lack of a vote.  The ugly proposals DO look ugly.
>
> ---
> This works well for single proposals, but fails to capture *competing
> proposals *or* subsequent proposals.*
>

Can you explain how it fails to capture *competing proposals *or* subsequent
proposals*?

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

Re: [Tagging] Bridge Parapets

[Dudley Ibbett]

It would appear that the rendering for a bridge might include the parapet.  
Much of my local mapping however includes barriers along roads.  These are 
generally connected to the bridge parapet.  It would seem reasonable to 
therefore have a seperate way for each bridge paparet that links the barriers 
either side of the bridge.  Perhaps, barrier=wall, wall=parapet.   Parapet is 
however  used in more that one context http://en.wikipedia.org/wiki/Parapet   
If bridge parapets were to be mapped would they therefore need a more distinct 
name in this context "bridge_parapet" of should there be some sort of relation 
between the highway segment of the bridge and its associated parapets?  

At the moment I just leave the barriers "hanging" but it doesn't seem like a 
very satisfactory approach to mapping given they are attached to the bridge.

Regards

Dudley


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

Re: [Tagging] Accepted or rejected?

[jonathan]

What Forum?






Jonathan

---
http://bigfatfrog67.me





From: Andreas Goss
Sent: ‎Wednesday‎, ‎18‎ ‎March‎ ‎2015 ‎20‎:‎19
To: Tag discussion, strategy and related tools





> It is amazing to see how few people participate in this discussion and
> vote compared to the number of mappers.

STOP USING MAILINGLISTS!!!

Those things might be nice for some tech savy people, but for everybody 
else it's just as mess and feels like spam.

We are 100x more productive in the German Forum than on this or the de 
list and have much more participation...

__
openstreetmap.org/user/AndiG88
wiki.openstreetmap.org/wiki/User:AndiG88‎


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

Re: [Tagging] Accepted or rejected?

[David Bannon]

On Wed, 2015-03-18 at 21:19 +0100, Andreas Goss wrote:
> ...
> STOP USING MAILINGLISTS!!!
> 
> Those things might be nice for some tech savy people, but for everybody 
> else it's just as mess and feels like spam.

Andreas, I don't think email or mailing lists require "tech savy". My 87
year old mother copes fine with some she uses. I did need to warn her
about using all caps and after that, she was fine. You are unlikely to
meet a less tech savy person.

> We are 100x more productive in the German Forum ...

Fine, then why not suggest we move to a similar model ?  I'm personally
quite happy with the list but would be willing to consider alternatives.
As, I'm sure, would others. But we'd need to be convinced it has some
advantages for us...

David


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

Re: [Tagging] Accepted or rejected?

[Andreas Goss]

What Forum?


http://forum.openstreetmap.org/
__
openstreetmap.org/user/AndiG88
wiki.openstreetmap.org/wiki/User:AndiG88‎


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

Re: [Tagging] Accepted or rejected?

[Warin]

On 18/03/2015 11:13 PM, Martin Koppenhoefer wrote:


2015-03-18 12:55 GMT+01:00 Kotya Karapetyan >:


- Develop a new formula first.


 all abstentions count like negative votes.




Firstly I see no point in casting a vote of 'abstention'.. why vote at all?

Those casting 'abstention' once they realise it is the same as a no vote 
.. simply won't vote ... \


Then consider those that don't case a vote at all as abstentions.. as 
the vast majority don't cast a vote no proposal will be passed.


So leave it up to those that do cast a valid vote.

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

Re: [Tagging] Feature Proposal - RFC - Haul Channel

[Sam Dyck]

How about this:

A road with a private frequency of 154.635 and a squelch tone of 156.7
Frequency= 154.635 MHz
Frequency:squelch= 156.7 Hz
A road with that uses CB channel 5
Frequency= 27.015 MHz
Frequency:channel: CB 5
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Accepted or rejected?

[Warin]

On 19/03/2015 8:36 AM, Andreas Goss wrote:

What Forum?


http://forum.openstreetmap.org/
__


I agree that a 'forum' is far better at engaging a community ... keeps 
topics more organised as replies are localised (that are no isolated 
branches for instance), avoids the 'digest mode' problem, some even have 
a system of not viewing post by someone they don't like!
My experience suggests that mailing list that go to a forum find more 
activity than in the past. Getting 'good' activity remains a problem.


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

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

[Christopher Hoess]

On Wed, Mar 18, 2015 at 9:14 AM, moltonel 3x Combo 
wrote:

> On 18/03/2015, Frederik Ramm  wrote:
> > So please, don't go over board here by trying to force-involve every
> > mapper in tag votes; they're simply not important enough, and they
> > *should not be*. Don't try to make them important, lasting, or binding.
>
> +1 to all that. While I think that "voting" is very usefull, I think
> the whole concept of "accepting" a proposal (all the related arguments
> about voter thresholds) should be scraped entirely.
>
> Instead, how about revisiting the purpose of proposals pages vs key/tag
> pages :
> * key/tag pages would document the actual use (mainly observed via taginfo)
> * proposal pages would document a desired use (and include the current
> list of supporters/opponents)
> * ideally both pages would reference each other (many to many), maybe
> using a "used/encouraged/discouraged by " template
> * key/tag pages could be kept up to date fairly objectively
> * proposal voters should put the page on their watchlist, in case a
> change in the proposal changes their opinion
> * proposals should only be "end-of-lifed" if there is near-unanimous
> opposition and near-zero actual usage
>
> This should clarify the old question of whether the wiki does/should
> document usage or intent. It'll allow competing proposals to coexist
> more visibly. It keeps the interesting "opinion poll" use of voting,
> while removing the obnoxious "proposal is ready ! vote now so that we
> can start using it !" calls.
>
>
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.

I have a "modest proposal" to make on the tagging/approval workflow. (For
readers not familiar with the idiom, it's a proposal put forward to spur
discussion rather than a serious policy recommendation.) I feel that many
people's reaction is going to be "No! That's ludicrous and against the
spirit of OSM!" but I'd like to hear *why* you think that.

Let's start with a few principles. Tags are here to convey information
about objects being mapped. Because we map a wide variety of features and
serve many different interests, the process of tag creation needs to be
fairly egalitarian. No matter how intelligent or well-meaning, a small
central board can't design all necessary tags from scratch (wisdom of
crowds, etc.) However, in order to serve their purpose of conveying
information, tags also need to be documented. If only one person
understands what a tag means, it really hasn't conveyed information.
They're weakly self-documenting, but the meaning of a given key-value pair
may be ambiguous or obscure; it's vastly preferable to have written
documentation in the wiki, in whatever language, to clarify the mapper's
intentions.

Perhaps somewhat more controversially, while we want an egalitarian process
for tag creation, I would propose that we also want new tags to undergo
some form of peer review, if possible. Feedback from others can improve the
design of the original proposer.

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.

Essentially, this serves two purposes:
1) We have very strong social norms to avoid damaging other people's data.
However, these norms protect not only good data (where the meaning of the
data is shared and readily available) but data which is only understood by
the original mapper, if anyone (essentially, private mapping). (cf. this
recent message: <
https://lists.openstreetmap.org/pipermail/talk-us/2015-March/014445.html>)
The protection of data becomes part of a reciprocal contract: if you want
your data protected, you need to tell us what it means.
2) It leverages the rich toolset on wiki to let people keep track of how
tags are being expanded and redefined. MediaWiki has features like
Special:Newpages, watchlists, related changes, and so forth which would
make it easier to keep track of new ideas about tagging. It's much trickier
to do this if you have to monitor changesets on the map, even when
aggregated by tools of taginfo.

OK, flame away! What don't you like?

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

Re: [Tagging] Bridge Parapets

[Christopher Hoess]

This sounds like it would be connected to the "man_made=bridge" proposals
to map bridges as polygons. Maybe representing the parapets as lines that
share nodes with part of the "man_made=bridge" polygon?

-- 
Chris Hoess

On Wed, Mar 18, 2015 at 5:05 PM, Dudley Ibbett 
wrote:

> It would appear that the rendering for a bridge might include the
> parapet.  Much of my local mapping however includes barriers along roads.
> These are generally connected to the bridge parapet.  It would seem
> reasonable to therefore have a seperate way for each bridge paparet that
> links the barriers either side of the bridge.  Perhaps, barrier=wall,
> wall=parapet.   Parapet is however  used in more that one context
> http://en.wikipedia.org/wiki/Parapet   If bridge parapets were to be
> mapped would they therefore need a more distinct name in this context
> "bridge_parapet" of should there be some sort of relation between the
> highway segment of the bridge and its associated parapets?
>
> At the moment I just leave the barriers "hanging" but it doesn't seem like
> a very satisfactory approach to mapping given they are attached to the
> bridge.
>
> Regards
>
> Dudley
>
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Revisiting proposal/voting scheme

[moltonel 3x Combo]

On 18/03/2015, Kotya Karapetyan  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] Revisiting proposal/voting scheme

[David Bannon]

On Wed, 2015-03-18 at 21:40 +0100, Kotya Karapetyan wrote:

>  . would it make sense to change the current proposal/voting
> mechanism like follows?

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

No, I'm sorry but I don't see how an interested party can be expected to
objectively determine what the discussion concluded.  If we absolutely
must measure data in the database, how can we do otherwise in our
processes ?

About the only way would be to count up the emails for/against. And then
discount the early ones as they would apply to early drafts of the
proposal. Try and allow for the "fence sitters"

No, sorry, but a vote and an outcome may offend some politically correct
members but it is necessary. 


> - People can add their concerns later just by editing the page. 

At present, people wanting to edit (more then typo) test the list's
opinion first. Thats important.
> 
> 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; 

In my experience, a wiki that is 'unmoderated' very quickly becomes such
a mess its unusable. Fun for the few who know their way around it but a
mystery to everyone else. And thats many years of leading a technical
and very focused team using wiki as core documentation. 

The current system is not too bad. Lets correct the voting number
anomaly first. You did seem to me have consensus there but given what I
said above, does it need to be treated as a proposal ?

New users to OSM need to see the idea of 'approved' keys and values. Its
not enforced, we make that clear but a new user needs some initial
guidance.

Then maybe we look at the Forum idea ? 

David


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

Re: [Tagging] Accepted or rejected?

[Warin]

On 19/03/2015 12:27 AM, Friedrich Volkmann wrote:
Most mappers don't read this mailing list, but they come across a 
proposal when searching the wiki. E.g. when someone wishes to map a 
beehive he's seen this morning, he'll search the wiki and he will find 
Proposed features/apiary. This is a very good proposal, because it 
lists various possible tags so that people can compare and make up 
their mind. A 2-week voting period after a 2-week discussion period 
obviously would have messed it up. 


A person coming across something that they want to map and then finding 
it on the wiki .. If that person is not on the tagging group then they 
don't want to be concerned with making tags, they simply want to use 
them. Leaving comments and voting open for years won't change that .. it 
may simply confuse them as they want to use a tag .. if it is 'proposed' 
or 'voting' status wise they may be discouraged from using it.


I see no point in having a proposal open for voting over 1 year, those 
that want to vote have done so, the proposals voting should be closed 
and resolved.


The apiary proposal 
http://wiki.openstreetmap.org/wiki/Proposed_features/apiary
Promotes one tag and list other tags that could be used .. It has been 
in comments stage for a few years .. abandoned? Sorry but I see little 
point in leaving a proposal open for long periods of time .. all tags 
will evolve over time .. no mater what the status 'inuse', 'approved' 
etc still means they may change over time .. leaving them as proposed 
does little for that long term change process.



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

Re: [Tagging] Accepted or rejected?

[Friedrich Volkmann]

On 18.03.2015 22:50, Warin wrote:
> I agree that a 'forum' is far better at engaging a community ... keeps
> topics more organised as replies are localised (that are no isolated
> branches for instance), avoids the 'digest mode' problem, some even have a
> system of not viewing post by someone they don't like!

And it's easier to retrieve and reply to old threads.
And the e-mail addresses are not presented to spammers on a silver platter.
And you don't need to download messages you are not interested in.
And you can log in using any web browser on any computer. No need for a
tuned mailinglist-capable e-mail client, and no need to carry around a USB
stick with old messages.

Mailing lists are an obsolete technology. The may still be useful for topics
where immediate actions or decisions are required, though. E.g. for
discussing changeset reverts.

-- 
Friedrich K. Volkmann   http://www.volki.at/
Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria

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

Re: [Tagging] Revisiting proposal/voting scheme

[Dan S]

2015-03-18 21:58 GMT+00:00 David Bannon :
> On Wed, 2015-03-18 at 21:40 +0100, Kotya Karapetyan wrote:
>
>>  . would it make sense to change the current proposal/voting
>> mechanism like follows?
> 
>> - 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.
>
> No, I'm sorry but I don't see how an interested party can be expected to
> objectively determine what the discussion concluded.  If we absolutely
> must measure data in the database, how can we do otherwise in our
> processes ?
>
> About the only way would be to count up the emails for/against. And then
> discount the early ones as they would apply to early drafts of the
> proposal. Try and allow for the "fence sitters"
>
> No, sorry, but a vote and an outcome may offend some politically correct
> members but it is necessary.

It has nothing to do with "politically correct" - what a curious idea!
It's about designing the mechanism so that it does what we want it to
do. Lots of people repeatedly say that it doesn't. We don't all agree
what's broken about it...

I like the general approach Kotya proposes. It seems correct that we
want to keep the positive aspects of voting (discussion, refinement,
in one focal place, with some "straw poll" of community acceptance)
but the biggest issue people seem concerned about here is that
converting that straw poll into a blunt "approved/rejected" is not
helpful because it conflates some very different situations.

So here's how I would answer your question of how would "an interested
party [...] objectively determine what the discussion concluded":
instead of approved/rejected, some sort of visual widget on the wiki
page which summarised the {{yes}} and {{no}} with something like "76%
support [out of 98 opinions]". The poll would give a quick guide to
mappers, and encourage others to chip in with their opinion - any user
could add or remove their {{yes}}/{{no}} at any point.

Dan

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

Re: [Tagging] Accepted or rejected?

[David Bannon]

On Thu, 2015-03-19 at 09:09 +1100, Warin wrote:

> I see no point in having a proposal open for voting over 1 year, those 
> that want to vote have done so, the proposals voting should be closed 
> and resolved.

Hmm, I disagree. Just because the proposal did not get enough votes does
not mean it should disappear. Mappers looking for a suitable tag can see
it, decide after reviewing its flaws to use it. And it may well become a
widely used tag.

My guess is the proposer was disappointed in the initial RFC response
and decided he'd not get the votes.

Remember, being voted in is just one way a proposal becomes 'approved'.
Wide usage is the other (main one). Having that proposal listed gives
users firstly, some guidance and secondly, a chance to decide for
themselves.

It is not easy to get usage numbers for many unapproved tags, perhaps
thats worth addressing ?
 

David
> 
> The apiary proposal 
> http://wiki.openstreetmap.org/wiki/Proposed_features/apiary
> Promotes one tag and list other tags that could be used .. It has been 
> in comments stage for a few years .. abandoned? Sorry but I see little 
> point in leaving a proposal open for long periods of time .. all tags 
> will evolve over time .. no mater what the status 'inuse', 'approved' 
> etc still means they may change over time .. leaving them as proposed 
> does little for that long term change process.
> 
> 
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging



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

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

[moltonel 3x Combo]

On 18/03/2015, Christopher Hoess  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] Accepted or rejected?

[Friedrich Volkmann]

On 18.03.2015 22:40, Warin wrote:
> Firstly I see no point in casting a vote of 'abstention'.. why vote at all?

An abstention indicates that someone has neither a strong positive nor
negative feeling even after pondering. The world is not just black and white.

When you look at my abstention votes, you'll find that I always pointed out
my reasons for my abstention. That's what gives sense to these votes. The
same applies to negative votes. A plain "no" vote is not helpful in any way.

-- 
Friedrich K. Volkmann   http://www.volki.at/
Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria

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

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

[Warin]

On 19/03/2015 8:57 AM, Christopher Hoess wrote:


On Wed, Mar 18, 2015 at 9:14 AM, moltonel 3x Combo > wrote:


On 18/03/2015, Frederik Ramm mailto:frede...@remote.org>> wrote:
> So please, don't go over board here by trying to force-involve every
> mapper in tag votes; they're simply not important enough, and they
> *should not be*. Don't try to make them important, lasting, or
binding.

+1 to all that. While I think that "voting" is very usefull, I think
the whole concept of "accepting" a proposal (all the related arguments
about voter thresholds) should be scraped entirely.

Instead, how about revisiting the purpose of proposals pages vs
key/tag pages :
* key/tag pages would document the actual use (mainly observed via
taginfo)
* proposal pages would document a desired use (and include the current
list of supporters/opponents)
* ideally both pages would reference each other (many to many), maybe
using a "used/encouraged/discouraged by " template
* key/tag pages could be kept up to date fairly objectively
* proposal voters should put the page on their watchlist, in case a
change in the proposal changes their opinion
* proposals should only be "end-of-lifed" if there is near-unanimous
opposition and near-zero actual usage

This should clarify the old question of whether the wiki does/should
document usage or intent. It'll allow competing proposals to coexist
more visibly. It keeps the interesting "opinion poll" use of voting,
while removing the obnoxious "proposal is ready ! vote now so that we
can start using it !" calls.


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.


I have a "modest proposal" to make on the tagging/approval workflow. 
(For readers not familiar with the idiom, it's a proposal put forward 
to spur discussion rather than a serious policy recommendation.) I 
feel that many people's reaction is going to be "No! That's ludicrous 
and against the spirit of OSM!" but I'd like to hear *why* you think that.


Let's start with a few principles. Tags are here to convey information 
about objects being mapped. Because we map a wide variety of features 
and serve many different interests, the process of tag creation needs 
to be fairly egalitarian. No matter how intelligent or well-meaning, a 
small central board can't design all necessary tags from scratch 
(wisdom of crowds, etc.) However, in order to serve their purpose of 
conveying information, tags also need to be documented. If only one 
person understands what a tag means, it really hasn't conveyed 
information. They're weakly self-documenting, but the meaning of a 
given key-value pair may be ambiguous or obscure; it's vastly 
preferable to have written documentation in the wiki, in whatever 
language, to clarify the mapper's intentions.


Perhaps somewhat more controversially, while we want an egalitarian 
process for tag creation, I would propose that we also want new tags 
to undergo some form of peer review, if possible. Feedback from others 
can improve the design of the original proposer.


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.


Essentially, this serves two purposes:
1) We have very strong social norms to avoid damaging other people's 
data. However, these norms protect not only good data (where the 
meaning of the data is shared and readily available) but data which is 
only understood by the original mapper, if anyone (essentially, 
private mapping). (cf. this recent message: 
) 
The protection of data becomes part of a reciprocal contract: if you 
want your data protected, you need to tell us what it means.
2) It leverages the rich toolset on wiki to let people keep track of 
how tags are being expanded and redefined. MediaWiki has features like 
Special:Newpages, watchlists, related changes, and so forth which 
would make it easier to keep track of new ideas about tagging. It's 
much trickier to do this if you have to monitor changesets on the map, 
even when aggregated by tools of taginfo.


OK, flame away! What don't you like?


I like the incentive to document the use .. as undocumented tags can be 
removed .. maybe this could be automated ;-) Say 6 months of 
undocumented presence = automatic deletion. A warnin

Re: [Tagging] Revisiting proposal/voting scheme

[David Bannon]

On Wed, 2015-03-18 at 22:21 +, Dan S wrote:
>
> So here's how I would answer your question of how would "an interested
> party [...] objectively determine what the discussion concluded":
> instead of approved/rejected, some sort of visual widget on the wiki
> page which summarised the {{yes}} and {{no}} with something like "76%
> support [out of 98 opinions]". The poll would give a quick guide to
> mappers, and encourage others to chip in with their opinion - any user
> could add or remove their {{yes}}/{{no}} at any point.
> 

Certainly a different approach ! Quite a good one really. It meets my
criteria  of giving a new mapper some guidance on what he/she should
use.

Add in taginfo data.

And maybe a list of competing approaches so, again, its clear to a new
user what the options are.

I do think we'd need to have some (usage determined ?) end point
however. Who is going to register their approval of, eg, highway= this
far down the track ?  

I think data consumers also need a bit of certainty too. 

David




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

Re: [Tagging] Revisiting proposal/voting scheme

[Kotya Karapetyan]

To make it clear:

On Wed, Mar 18, 2015 at 11:00 PM, moltonel 3x Combo 
 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.


> A good proposal
>
should already be nicely usable as documentation of the desired
> tagging schema.


Fully agree.


> 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
>
>
Yes, and the combined pages can be linked just like that.


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

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

Re: [Tagging] Revisiting proposal/voting scheme

[Kotya Karapetyan]

On Wed, Mar 18, 2015 at 11:39 PM, David Bannon 
wrote:

> On Wed, 2015-03-18 at 22:21 +, Dan S wrote:
> >
> > So here's how I would answer your question of how would "an interested
> > party [...] objectively determine what the discussion concluded":
> > instead of approved/rejected, some sort of visual widget on the wiki
> > page which summarised the {{yes}} and {{no}} with something like "76%
> > support [out of 98 opinions]". The poll would give a quick guide to
> > mappers, and encourage others to chip in with their opinion - any user
> > could add or remove their {{yes}}/{{no}} at any point.
> >
>
> Certainly a different approach !



Ahhm, not sure how it is different, but never mind. I will be happy if we
all agree on a good solution, and I definitely don't claim the authorship
of all the good ideas that have popped up here over the last couple of
days. I just tried to summarize it in something that looked to me like a
working solution. Dan, thanks for making a good illustration :)


> Quite a good one really. It meets my
> criteria  of giving a new mapper some guidance on what he/she should
> use.
>
>
Good to hear :)


> Add in taginfo data.
>

Yes: "*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*"


> And maybe a list of competing approaches so, again, its clear to a new
> user what the options are.
>

It clearly belongs a "see also" section IMO.



> I do think we'd need to have some (usage determined ?) end point
> however. Who is going to register their approval of, eg, highway= this
> far down the track ?
>
> I think data consumers also need a bit of certainty too.
>

End of what?
Usage, as discussed in another thread, is a vague criterion. Two tags may
have a full support of the community, one having thousands of uses and
another (for a rare feature) ten.
For data consumers---definitely yes, and I suggest it being the moment when
we remove the "proposal" status, so the page becomes a feature page. The
moment can be "w*hen the discussion calms down (which can even be defined
mathematically if needed**)*".

Sorry guys, no more spamming today :) Hopefully we'll converge to something
good, so these discussions won't be in vain :)

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

Re: [Tagging] Accepted or rejected?

[Friedrich Volkmann]

On 18.03.2015 23:09, Warin wrote:
> A person coming across something that they want to map and then finding it
> on the wiki .. If that person is not on the tagging group then they don't
> want to be concerned with making tags, they simply want to use them.

Compare it to politics. Many people don't participate in politics, but have
clear political opinions, and they will tell their opinions whenever they
can do it without effort.

It's much easier to leave a comment in the wiki on the fly than to
continously participate in a maling list reading hundreds of messages every
week.

> Leaving
> comments and voting open for years won't change that .. it may simply
> confuse them as they want to use a tag

That's fine. People should be encouraged to use their brains.

> .. if it is 'proposed' or 'voting'
> status wise they may be discouraged from using it.

They use it unless they find better alternatives.

> I see no point in having a proposal open for voting over 1 year, those that
> want to vote have done so, the proposals voting should be closed and resolved.

There were some proposals where I wanted to vote, but I missed the short
voting timeframe.

> The apiary proposal 
> http://wiki.openstreetmap.org/wiki/Proposed_features/apiary
> Promotes one tag and list other tags that could be used .. It has been in
> comments stage for a few years .. abandoned?

I think that the "abandoned" status should be renamed, and that its colour
should be gray or yellow instead of red.

-- 
Friedrich K. Volkmann   http://www.volki.at/
Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria

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

Re: [Tagging] Revisiting proposal/voting scheme

[David Bannon]

Kotya, in no way was I criticising the leadership you have shown in this
matter !

Its just that I preferred Dan's approach. Key IMHO is -

* A proposal gets to wiki in much the same manner as now.

* Once on the wiki, instead of a formal vote period, users (eg) click a
"like" or "dislike" button and aggregate score is shown. For some time
(?). Obviously they can also edit content to say why.

Now, we don't have that content freeze when voting formally starts. Is
it a problem that I click 'like' and some important change is made to
content later ?

David

On Wed, 2015-03-18 at 23:57 +0100, Kotya Karapetyan wrote:


> Ahhm, not sure how it is different, but never mind. I will be happy if
> we all agree on a good solution, and I definitely don't claim the
> authorship of all the good ideas that have popped up here over the
> last couple of days. I just tried to summarize it in something that
> looked to me like a working solution. Dan, thanks for making a good
> illustration :)
>  
> Quite a good one really. It meets my
> criteria  of giving a new mapper some guidance on what he/she
> should
> use.
> 
> 
> 
> Good to hear :)
>  
> Add in taginfo data.
> 
> 
> Yes: "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"
>  
> 
> And maybe a list of competing approaches so, again, its clear
> to a new
> user what the options are.
> 
> 
> It clearly belongs a "see also" section IMO.  
> 
> 
> 
> 
> 
> I do think we'd need to have some (usage determined ?) end
> point
> however. Who is going to register their approval of, eg,
> highway= this
> far down the track ?
> 
> I think data consumers also need a bit of certainty too.
> 
> 
> End of what? 
> 
> Usage, as discussed in another thread, is a vague criterion. Two tags
> may have a full support of the community, one having thousands of uses
> and another (for a rare feature) ten. 
> For data consumers---definitely yes, and I suggest it being the moment
> when we remove the "proposal" status, so the page becomes a feature
> page. The moment can be "when the discussion calms down (which can
> even be defined mathematically if needed)".
> 
> 
> Sorry guys, no more spamming today :) Hopefully we'll converge to
> something good, so these discussions won't be in vain :)
> 
> 
> Cheers,
> Kotya
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging



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

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

[Christopher Hoess]

On Wed, Mar 18, 2015 at 6:39 PM, Warin <61sundow...@gmail.com> wrote:

>
> I like the incentive to document the use .. as undocumented tags can be
> removed .. maybe this could be automated  ;-)Say 6 months of
> undocumented presence = automatic deletion. A warning meassage to the user
> may provide documentation, ay after 3 months? Flames here...
>

I think that's carrying it a bit far, and too close to the "central
planning model". I think it would be sufficient to think of undocumented
tags as resembling unsupported APIs: yes, you can use them, and they'll
probably work most of the time, but they could break or change without
warning. If we had a culture where properly documenting tags was the rule
rather than the exception, and we had worked through most of the huge
backlog of undocumented tags that now exist, *AND* we were happy with the
state of affairs, maybe we could think about purging in that way, but I
think that would be premature to consider.



> The 'peer review' I currently see as the comments/voting process. I think
> it does help with improving tags provided suggestions for improvements are
> made rather than demands, commands and derogatory comments. Offering a
> problem is only one side of the coin .. there needs to be a solution too. I
> try to provide both.
>

Good point. I don't have a concrete process suggestion, but maintaining a
collegial and constructive tone in discussions is important. A lot of what
people have been saying on this list about resolving votes, abstentions,
coming to consensus and so forth could be applied to on-wiki discussions of
proposed changes. My proposal was aimed more at the fact that there are
very few social incentives to use the wiki right now; the approval process
is a mess because it's only used by people willing to take a lot of time
and energy for little concrete gain.


> Adding new values should be the same process as adding a new key, maybe it
> can be shorter in time? Simply adding things to the wiki does not get the
> attention of people .. notifying the group gets attention that may lead to
> improvement. And puting things to the group before going to the wiki is
> better as basic ideas may be discussed rather than going into a full detail
> ... things like this discussion don't fit well on the wiki.
>

I think it's important that editing the wiki to incorporate a new key or
value be very easy to do, otherwise we start sliding back towards a
"central planning" model. 90% of the documentation will probably be of
interest only to a few mappers and won't get changed much after being
created. We want to let people do that and go map without trouble. However,
if you're changing something important or popular, it's probably best to
change the wiki and see what people say before you start adding it to the
map.

Right now, we don't notice things on the wiki because we're socialized to
consider it unimportant. However, pages like <
http://wiki.openstreetmap.org/wiki/Special:NewPages>, maybe with a little
filtering, could easily be used to track new key creations; maybe a bot
could even monitor it and send a digest to a mailing list regularly.
Discussion could take place at the discussion/talk pages in the wiki: e.g.,
I could say at Talk:Railway "I think we should add new value xyz, this is
how it fits with the current scheme, what do you think?" If on-wiki
discussion was the norm, people interested in railroads would have that
page on their watchlist, they would see my change when I made it, and could
reply. Maybe we could also have a forum on-wiki where people could announce
"I have a new idea, comment on talk page ... if it interests you." I think
the talk pages work OK for that, but I admit that I have been brainwashed
by almost a decade of Wikipedia editing, maybe other people do not like to
discuss there.

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

Re: [Tagging] Deleting private objects in private spaces

[johnw]

> On Mar 19, 2015, at 12:25 AM, Martin Koppenhoefer  
> wrote:
> 
> 
> 
> 
> 
>> Am 18.03.2015 um 14:47 schrieb John Willis :
>> 
>> simply appending "private:" on existing public tags is not preferred, though 
>> the simplest to execute and avoids having to redefine everything in the 
>> world again. 
> 
> 
> I think prefixing private: is a viable idea, it can be easily filtered out 
> when you don't want these, and it avoids misinterpretations


Once again, I failed to read your email correctly. I somehow missed the 
distinction between private:*=* and an adding access=private.  ><

Yea, the private:*=* completely changes the definition of the tag (like 
construction: or abandoned:), rather than trying to add a new meaning on with 
access=private or private=yes onto an existing tag. 

I have been living in Japan for just 4 years, and seeing how my Japanese is 
crap, you’d think my English level would stay pretty high… but it is 
disappearing at an alarming rate… Maybe it’s just teaching the English 
equivalent of primary school classes every day….

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

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

[Christopher Hoess]

On Wed, Mar 18, 2015 at 6:30 PM, moltonel 3x Combo 
wrote:

> On 18/03/2015, Christopher Hoess  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...


Well, we should encourage people to try to reconcile proposals and agree on
tagging schemes, although there will be some cases where we "agree to
disagree" and document that. How hard we push from that is largely a
question of procedure, I suppose.


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


Yeah. We'd have to have a lengthy "amnesty" period (>= 1 year), with
targeted notifications, challenges to write documentation, etc., before
making a change in policy like this.


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

Is that because using the wiki is intrinsically terribly hard (admittedly,
having unified login for the wiki and the database proper would be nice),
or is this a side effect of the fact that there's very little incentive to
use it? People (hopefully) use tags more than once: slapping down a
sentence or two in the wiki on the occasions you need to invent one doesn't
strike me as an extraordinarily high bar.

I don't think we can get everyone who needs a new tag to submit
high-quality, well-thought-out proposals from the beginning. But making
their ideas publicly visible via the wiki should get more feedback on the
tags and sooner. As it stands today, bad or incomprehensible tagging can
fly under the radar until it's so widespread it can't readily be corrected.


>  * Suggesting that it's ok to undo somebody's work because he didn't
> document it is a recipe for nasty conflicts.
>
>
See my caveats above & my reply to Warin: I wouldn't want to launch
search-and-destroy missions against undocumented tagging. But if there's
really a serious conflict over how to use certain tags, it's going to
manifest *somehow*. Because, under this proposal, documentation on-wiki
provides a positional advantage, I would expect these conflicts to flow
away from the database towards the wiki, which IMO is more transparent than
having them buried in map changesets.

It seems like the best way to get your way under the current system is not
to waste energy on the wiki and tag as energetically as possible according
to whatever scheme suits you. That's not entirely a bad thing--in the big
picture, adding to the map is what's important--but it's a recipe for
perpetual semantic confusion and ambiguity within the database.

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

Re: [Tagging] [Imports] Mechanical Tagging Proposal - dump_station - conditional

[Bryce Nesbitt]

On Wed, Mar 18, 2015 at 2:43 PM, SomeoneElse  wrote:

> On 18/03/2015 20:21, Bryce Nesbitt wrote:
>
>> For your comment is the following proposal is to consolidate sanitary
>> dump station tagging semi-mechanically:
>> http://wiki.openstreetmap.org/wiki/Mechanical_Edits/Bryce_C_
>> Nesbitt#DISCUSSION_--_Sanitary_Station_Retagging
>>
>>
> Please don't do this.  No-one outside the tagging list is going to
> understand what on earth a "Sanitary Dump Station" is.
> Cheers,
> Andy


You are invited to participate in the discussion on
http://wiki.openstreetmap.org/wiki/Proposed_features/Sanitary_Dump_Station,
regarding the naming of this tag.

A long RFC period was used to try and collect the maximum number of views.
A long list of candidate names was tried, among them the one with the most
UK colour: Elsan Point.
Whilst there was no perfect answer to be found, consensus settled on the
tag name chosen.
Elsan Point was the most British of the options, in keeping with OSM's
history, but as a brand name there were objectors from
elsewhere on the planet.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] waterway=lock_gate - is it only for nodes?

[Bryce Nesbitt]

On Wed, Mar 18, 2015 at 6:49 AM, Malcolm Herring <
malcolm.herr...@btinternet.com> wrote:

> Not deprecated, but considered on a case-by-case basis. It is a question
> of whether important navigation information would be deleted if the seamark
> tags were removed. In the case of bridges, the safe air draft and beam are
> important attributes that should be kept, but a bridge that is absent those
> seamark attribute tags need not carry the "seamark:type=bridge" tag.
>
> Seamark tags could appear on otherwise OSM standard objects.
That would bring the two tagging systems closer together: and allow orderly
migration to a single set of tags.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging