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...
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.
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.
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).
I don't make a distinction between the "OSM Core" and the software
development. The two have to work together. What one writes, the other
must be able to read and understand. Neither is truly autonomous as
failing to understand and react to the needs of your stakeholders is a
recipe for suicide.
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. Surely we are not going
to add a tag for everything that an object is 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.
regards
Peter
Am 13.04.2012 08:11, schrieb Colin Smale:
Yes please!
I was also thinking on the lines of documenting implicit tagging:
* to save mappers time
* to save space in the database
* to avoid confusion
* to allow a single point of maintenance
At a generic "territory" level with some kind of hierarchy please, so
for example cities can override counties which can override states
which can override national rules. As traffic rules are made by some
kind of government, I am sure the current boundary/admin_level stuff
can be used as a base as long as a true hierarchy can be found (no
multiple inheritance!)
<defaults territory="uk">
<defaultentry>
<match>
<tag k="highway" v="motorway" />
</match>
<implies>
<tag k="foot" v="no" />
<tag k="maxspeed" v="70 mph" />
<tag k="bicycle" v="no" />
</implies>
</defaultentry>
</defaults>
Technically it doesn't seem that difficult.
Colin
On 13/04/2012 07:27, Stephen Hope wrote:
The problem with this, is many mappers are not even aware of what
implicit assumptions they are making, and hence won't map them.
Saying that they should map them won't help.
Do we need a database* of explicit default settings for different
areas, to be used by renderers, routers and other tools as
appropriate? Rules like "In Germany, motorway implies foot=no if
there is no foot tag on the way". This could also help give sane
guesses of defaults for roads that haven't been tagged at all yet.
* either a separate database, or polygons inside OSM with tags,
whatever. That's not the point at the moment
Stephen
_______________________________________________
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging
_______________________________________________
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging
_______________________________________________
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging
