[Tagging] sidewalks and tagging for the renderer
wendorff at uni-paderborn.de
Fri Apr 13 11:20:04 BST 2012
Am 13.04.2012 08:55, schrieb Colin Smale:
> On 13/04/2012 08:20, Peter Wendorff wrote:
>> -10 for adding defaults as a hint for mappers!!!
> You sure know how to lower the barriers to entry and attract new
Not exactly, but a big catalogue of explicit defaults IMHO does not make
>> Every application using OSM data has to make assumptions about data
>> not present in the database, sure, but reliable data has to be
>> present in the database, as a missing tag in general can be both:
>> missing/unknown, or "default", whatever "default" means.
> And that's exactly the problem. The alternative to documented
> defaults, is explicit tagging for absolutely everything. No way will
> we ever get mappers to accept that they have to enter all that stuff a
> million times. And undocumented defaults make the data unreliable as
> you say.
We don't have to force mappers to tag everything. But to clearly state
that a fact is the default it is definitively not sufficient to count on
There are many many mappers who mainly draw streets from aerials, and in
most cases there is no way to identify a maxspeed.
Germany has a "default"/implicit maxspeed in urban areas of 50km/h, but
in fact many cities reduce that explicitely to 30 for big parts of the city.
A documented default of 50 for cities in Germany would lead to exactly
the opposite of what we want: applications don't identify streets as
"unknown speed limit" if they want to, they assume 50 exactly as they (I
think) do today, but mappers don't explicitly state that 50 is the
correct assumption any more, because it's a default.
In this case it's not in any way possible to identify missing maxspeed
attributes that differ from the default any more, as long as there's no
fixme or sth. like that, but then we have in contrast MORE tags (here
fixme) to do the same as we can do now, and these are more difficult to
>> If we would define a set of defaults and mappers follow that set,
>> nobody will add "default" values again, and it's not possible to
>> distinguish between default and unknown any more.
> If there is no default value, don't define it. For very many
> important, everyday things, there are valid defaults, i.e. it is not
> "unknown" or even "unknowable", just not written down. If I'm on a
> normal road in a built-up area in the UK and there is no traffic sign
> to say otherwise, the speed limit IS 30mph.
Sure, but if there's no tag, you don't know if the default is true or
the tag is missing, it's just a guess.
With "mapper defaults" you will have to guess more often than today.
>> Yes, sure: Applications should have these default values, and
>> probably it is useful to define some kind of "common defaults" in a
>> file that can be used and parsed by applications, but this should not
>> be part of the osm mapping work, but part of the software development
>> around OSM (not in the osm core).
> If common applications publish their built-in assumptions, I expect
> they would tend to converge over time. If the mappers can be sure of
> how data consumers handle missing tags, there is no longer a necessity
> to tag everything so explicitly, thus saving time on mapping and lots
> of discussions, not to mention terabytes of data.
Counter-argument see above.
> Surely we are not going to add a tag for everything that an object is
I agree here and I usually don't add (all) defaults either, but I don't
want to do that as a RULE as I see where it's necessary, and if I am
interested in a particular topic (e.g. lit=yes/no) I would add even
lit=yes in cities and lit=no outside (what I would see as the default in
Germany for lit), just to keep track of where this attribute is checked
and proven, and where it's not.
> I see this not just as a theoretical issue, but one of real
> practicality. Given that data consumers have a need for good data
> quality, one way of achieving that is by full explicit tagging. I just
> don't see that happening. A more heuristic approach involving
> documenting assumptions/defaults would allow the data's usability
> dramatically to be improved without full explicit tagging.
Sure, but that's the data consumer/software side, it's not the mapper part.
And a common set of "interpretation in software-defaults" allows to give
mapper tools to identify issues, where missing attributes are wrongly
interpreted due to missing tags. But these issues are only more
important than others, "matching" defaults are only by chance
interpreted correctly - even if the defaults are documented as "mapper
More information about the Tagging