[OSM-talk] Instead of voting

Russ Nelson nelson at crynwr.com
Sat Oct 10 20:22:31 BST 2009

Note: this is a single reply to everyone who offered suggestions.  If
anyone has any more suggestions, please make them, otherwise I'll put
this into the wiki and modify the voting documentation to say "As an
alternative to voting, consider doing this instead."  My hope is that
people will simply stop offering proposed features, and simply map and
document how they mapped.  Not trying to force anybody not to vote!

First, the new and improved steps:

1) Just map.

2) Use existing keys if you can.  When you use a key, check to see if
there's an existing value that matches what you are mapping.  To go
looking, put your key into the following URL where it says "shop":

3) Use existing tags if you can.  When you use a tag (key=value),
check to see if an existing tag is already documented.  Don't use it
in a different way if it's already documented.  To go looking, change
this URL where it says "shop=car":

4) Never invent a tag which you don't have a concrete use for.  But if
you're using a tag, document your use of the tag, so that other people
won't use your tag to mean something else.  Define your tag so that it
is verifiable.

5) If you disagree with the definition of the key or value, then
create a new key or value with a different name, use it in your
editing, document it in the wiki, AND (this is important) edit the
page for the tag you disagree with so that it mentions your tag as an
alternative so that people understand that there is disagreement.
Link to tagwatch / osmdoc / tagstat so that people can find out which
is more often used in practice.

Matt Amos writes:
 > 1) tags don't need to be voted on in order to be used. > 
 > 2) tags shouldn't need to be voted on in order to be documented.
 > 3) the inclusion (or not) of a tag on map features may well be
 > something that it is worth voting on.


Martin Koppenhoefer writes:
 > This proposal includes the deletion of all voting-related stuff
 > including the casted votes of the past.

+1, because it's part of the documentation for how people have
currently mapped.

 > > 3) Use existing tags if you can.
 > the thing is that not everybody will write a documentation for every
 > key he uses, and in the end (we're already in some tags at this
 > stage), there will be many same tags with different intended meanings.

I agree with this.

 > By deleting the voting-process things will get worse.

This doesn't follow.  People haven't documented tags therefore voting
will create the documentation?

 > > 5) If you disagree with the definition of the key or value, then
 > > create a new key or value with a different name, use it in your
 > > editing, document it in the wiki, AND (this is important) put a link
 > > to it in the definition that you disagree with.
 > this would mean that footway/cycleway/path was just the beginning ;-)

Except that they mean different things.  It might help if
highway=cycleway and highway=footway said "consider using highway=path
if use is not restricted to cyclists or walkers."  (don't bother
looking -- I just this moment added that text).

 > > 6) The risk of this system is that people will not find tags that have
 > > the meaning they're looking for.  They'll then create a new tag which
 > > has an identical or similar meaning to an existing one.
 > +1

But the voting procedure doesn't stop anybody from doing this, because
you don't have to vote before using a tag or documenting it.

 > > If you find a
 > > pair of these tags which have similar meanings, you should edit the
 > > wiki pages for them, and include pointers to each other.
 > but won't this "edit" mean to change the definition for all already
 > present tags in the db? Or do you simply mean to add crossreference?

Yes, cross-reference.

Stephen Hope writes:
 > However, I have seen proposals which have improved considerably after
 > a little bit of feedback during the voting process.

We now have a tagging mailing list for that.

--my blog is at    http://blog.russnelson.com
Crynwr supports open source software
521 Pleasant Valley Rd. | +1 315-323-1241    
Potsdam, NY 13676-3213  |     Sheepdog       

More information about the talk mailing list