Am 13.04.2012 12:47, schrieb Pieren:
On Fri, Apr 13, 2012 at 12:25 PM, Peter Wendorff
<wendo...@uni-paderborn.de> wrote:
I would keep it, but make a big hint that these are defaults, that SOFTWARE
can assume.
It should IMHO not be a rule for mapper, that motivates to delete or
willingly omitt these values.
Point is that editors should support these default values and inform
contributors about what can be implied.
What's the benefit of these information?
Nobody will add more precise information because of the hint, but some
people will add less precise information by omitting tags they would
have added otherwise.
Information about "what can be implied" could easily be exchanged to tag
suggestions (you are adding a highway. do you want to add maxspeed
too?), as long as the user has to explicitely agree with that particular
tag.
Pure implicit tag additions don't help as they produce wrong data by
suggesting that a particular tag may be necessary(!) and that it may be
better to add it with a wrong value than omitting it completely.
I think this is the best compromise between GIS people or data
consumers who want explicite tags
Data consumers prefer explicite, but CORRECT tags over implicite/unknown
tags over explicit and UNCORRECT tags.
Forcing mappers to add more tags just for the "completeness" produces
more uncorrect tags and makes quality assurance and error tracking more
difficult.
and average contributors who want to minimize the efforts for edition.
...which creates less, but correct tags, second best option for data
consumers, not more work for editors.
Presets can help but look how the
oneway tag works in Potlatch2. The result is that many "oneway=no" are
unnecessarily added in the db
oneway=no is not necessary, but it does not harm, as long as it's correct.
Quality research in OSM states, that in particular this kind of
attributes is often missing in osm. But why?
One reason is, that it's impossible to check a particular area for
completeness of e.g. oneway tagging.
Here the explicit oneway=no is not primarily directed to the data
consumers - they should use it as a default, it is directed to mappers,
who can check if others took care about that tag already or not.
Presets, that always add all attributes are IMHO a design error of the
editor software. A preset for a bench should add amenity=bench, and
suggest to add more tags - but not enforce that.
It should be a "hey, do you know, if that bench has a backrest, too? If
so, you may want to add it." instead of "has it a backrest or not?"
and data consumers will ask the same for
maxspeed, width, surface, lanes, sidewalks, lit, and so on...
Usually we (at least I, and I guess many others, too) would response to
that question, that consuming applications should expect to have
fallback values, that OSM is a living system without guaranteed
completeness and that nobody can ask for complete tagging - in no way
and for no attribute or data type.
But if a company would like to have complete maxspeed tagging, they are
allowed to collect the data and even add it explicitely everywhere they
know it.
And I think, that's fine.
And this
is for sure not lowering the barrier entry for new contributors which
is one of the key issues for the future of this project, (see what's
happening to wikipedia).
As I said: Noone - neither other mappers nor "consumers" are able,
allowed or ignored when enforcing other mappers to add a fixed set of
attributes.
Presets user interface should be designed in a way that allows and makes
it easy to omitt values, that are unknown.
When you leave the assumptions to the software level, you can be sure
that you will end up with different results on different softwares.
The best way to keep consistency is to fix the rules in the database.
IMHO the best way is to agree on rules across data consuming
applications (and their developers), but to not include these default
rules in the editors.
regards
Peter
_______________________________________________
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging
