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
mappers...
Not exactly, but a big catalogue of explicit defaults IMHO does not make
anything easier.
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
the default.
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
identify automatically.
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
NOT.
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
defaults".
regards
Peter
_______________________________________________
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging
