> From: bruno [mailto:br...@anche.no] > Subject: Re: [OSM-talk] Role of the Wiki > > On mer, 2012-12-05 at 05:49 +0100, Roland Olbricht wrote: > > - use tags or tag keys that have been used quite often > > http://taginfo.openstreetmap.org/ > > What if a new way of tagging something gets approved? The moment it > becomes "approved" there will be probably 0 objects with the new tags, > and if someone follows this principle (from what I see, this is exactly > what happens) the new tags won't be used, rendering useless the > discussion and approving of the new tags*.
It's important to remember that a tag that is "approved" is not approved for use in OSM. There are no tags approved for use in OSM. All an "approved" tag on the wiki means is that it is approved to be listed as an approved tag. The OSM tagging system has its flaws but by and large it works. It sometimes takes longer than desirable to reach a consensus on tagging but as long as no one stacks the deck by doing a mechanical edit or import where there isn't general agreement the voting on tags is done in the database, influenced by presets, renderer support and wiki documentation. If I had to pick the four issues I commonly see with wiki tag proposals it is that no consideration is given to 1. Support by renderers or data consumers. Anything that data consumers cannot parse will only ever be seen by other mappers editing the DB. People like to see the results of their mapping, schemas which cannot be used by consumers are unlikely to gain much traction. 2. Issues with complicated data models that cannot be tagged by people who don't have expertise in that particular sub-area. 3. The practicality of implementing presets. If you design some complicated relation-based tagging schema unlike anything else, it's not going to get added as a preset to the editors and won't end up used by most people. 4. Backwards compatibility. </rant> _______________________________________________ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
