[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