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

Nick Black nickblack1 at gmail.com
Fri Feb 15 08:48:34 GMT 2008


2008/2/15 Stefan Keller <sfkeller at gmail.com>:
> 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?

How do you make a map of China without being able to use Mandarin characters?

>
>
>
> 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
> >
> >
>
>
> _______________________________________________
>  dev mailing list
>  dev at openstreetmap.org
>  http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev
>
>



-- 
Nick Black
--------------------------------
http://www.blacksworld.net




More information about the dev mailing list