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

Stefan Keller sfkeller at gmail.com
Fri Feb 15 08:32:17 GMT 2008


Look: It seems to be debate about unstructured, semi-structured and
structured data. What you're celebrating is something around semi-structured
data.

Marcus reminded my that OSM allows for a building to be more than just a
shop, but a gas-station a fuel-station, lit, car-wash, etc. That's right,
but keep in mind, that I *don't* propose to change the current internal OSM
schema and I *won't* restrict the number of key on your side. I propose only
to restict the character set of keys. I'm showing a use case where parts of
the OSM data gets out into a usual application environment and I hope OSM
was'nt meant to stick in it's free but "closed world".

So let's say for my application I'm happy with one attribute (type="shop")
or two. You know that in a more application oriented environment you do
stick to a schema with a distinct number of attributes and take care of each
of them.

Having said that, if you want multivalued attributes and lossless data
exchange there are many possibilities in my example schema to either sync'
back based on the ID or store all the additional key/values you may receive
from the users (e.g. in a attribute). This again to the prize that there is
no usable index in the application schema (except for the ).

Rob wrote:
> You use building=shop in your examples but there is absolutely nothing
> to stop someone using (apologies in advance for my lack of language
> skills) construcción=almacén or ??????=?????.

Good example: How to make a map of more than one country when you an me
can't interpret "construcción" and "??????" being buildings?



2008/2/15, Jochen Topf <jochen at remote.org>:
>
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/dev/attachments/20080215/1a71c883/attachment.html>


More information about the dev mailing list