[OSM-talk] Edit war on the wiki "map features"

Ben Supnik bsupnik at xsquawkbox.net
Wed Nov 26 01:44:02 GMT 2008


Hi,

Slight tangent on the edit war (which has morphed into a discussion of 
what to do with the ever-growing list of map features on the wiki)...

We don't want to tag to the renderer, but knowing what clients utilize 
what tags is important.  In my experience with user-collected data in 
X-Plane I have found that there is a huge difference in data quality 
between data that is heavily validated by the tool-set while/soon after 
the user works and data that is collected for use much later or never.

Applying that to OSM, I would expect that the one-way information in OSM 
should be relatively good because users will see if they got their 
one-way or way-direction wrong as soon as mapnik or t at h rebuild the tile 
image.  By comparison, errors in the height of antennas/masts would be 
harder for users to detect because there isn't visual feedback of this 
(at least that I know of in the main map layers).

So in trying to answer the question about what are "good" and "bad" tags 
for the purpose of making a short listing of the "most important tags" 
and a longer listing of less important ones, I think that:

- renderer and toolset support is very important because it will impact 
data quality.

- use of data by a particular client projects (the main map or other 
efforts) are important because they naturally group tags and provide 
warm bodies to detect problems.

- frequency of tag usage on the actual map is probably a good indicator 
of how general a tag is.

To throw out a straw man for reorganizing the Wiki (and I think having 
good docs on tag schemes is important), perhaps it would make sense to have:

1. "core" tags, including tags drawn in the main map renderings, tags 
that are widely used, and tags that are subject to error checking.

2. "all" tags, a huge laundry list.

3. per-usage/client/project lists of used tags for a given application, 
so that map makers who are targeting that application can be sure they 
are doing "complete" work.  (E.g. if someone is working on an 
aeronautical map, not having the height of all masts is a completeness 
problem...but that's perhaps a lot more important to aero-map folks than 
the general community.)

I think we have to accept in a wide-spread crowd-sourced project that 
there is going to be a huge range of data quality and tag 
completeness...regarding the "smoothness" tag if most roads don't have 
smoothness data, that's a cost of the form of OSM...a sub-project cannot 
mandate that all map makers provide all possible information to all 
client efforts.  But conversely that doesn't make "smoothness" wrong - 
it just makes it of narrow interest.  (If there are problems with the 
actual proposed smoothness tag, that's a separate issue...)

(If someone working on a client project needs a particular tag, that 
person can gain leverage by adding tool support for the tag, making it 
easier to use and less error prone for everyone...)

cheers
Ben



-- 
Scenery Home Page: http://scenery.x-plane.com/
Scenery blog: http://xplanescenery.blogspot.com/
Plugin SDK: http://www.xsquawkbox.net/xpsdk/
X-Plane Wiki: http://wiki.x-plane.com/
Scenery mailing list: x-plane-scenery at yahoogroups.com
Developer mailing list: x-plane-dev at yahoogroups.com




More information about the talk mailing list