[OSM-dev] Restrict key names on order to retain reusability of OSM

Jochen Topf jochen at remote.org
Fri Feb 15 08:07:04 GMT 2008


On Fri, Feb 15, 2008 at 12:57:41AM +0100, Stefan Keller wrote:
> model and will never evolve or be re-imported from other databases. Users
> will be 'surprised' when they miss their data on the map like with 'Tunnel '
> instead 'Tunnel' or with things like that '¨name'='Südstrasse'. My proposal
> would eliminate that.

In OSM this problem is solved not by restricting what people can tag but
by having tools like the JOSM validator plugin and Maplint that will tell
you if there is data that "looks wrong" to the computer according to
some criteria. It is the job of a human then to decide whether it
actually is wrong in his opinion and fix it. I expect these tools to
improve over time and eventually find most cases where people have
accidentally used the wrong tag. With this solution we keep the
"default" openness: People who want to use unusual tags on purpose are
not restricted.

> Now obviously it's about "geographic data" as said in the OSM homepage and
> its about databases and it's hopefully not HTML. The model you choose it a
> sort of meta model which is ok for initial capturing but not optimal for
> post-processing and showing it in maps - and the difference (from your point
> of view) is just restricting key characters to some smaller set!

Thats exactly what we are doing and want to be doing: We are capturing
data in the most flexible way possible. Everybody who wants to *use* the
data for something has to pick the subset of the data he is interested
in and can convert it to any format he likes best and that is suited for
his needs. Of course there are ways to store subsets of the data in more
efficient forms and many people do that, but everybody has different needs
and so needs different subsets of the data and in different forms. The
needs for somebody drawing a map are very different from somebody doing
routing, for instance. The OSM data model is not designed to be
efficient, it is designed to be flexible.

Jochen
-- 
Jochen Topf  jochen at remote.org  http://www.remote.org/jochen/  +49-721-388298





More information about the dev mailing list