[Tagging] sidewalks and tagging for the renderer

Peter Wendorff wendorff at uni-paderborn.de
Fri Apr 13 12:47:05 BST 2012

Am 13.04.2012 12:47, schrieb Pieren:
> On Fri, Apr 13, 2012 at 12:25 PM, Peter Wendorff
> <wendorff at 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 
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 
> 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 
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.


More information about the Tagging mailing list