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

[Stefan Keller]

In the model I showed and I would use for such purposes a sample query would
look like this:

# select * from building'; -- was: where type='shop'
# select * from streets: -- where street type value can be anything

Where buildings get a building (= table = keyname) point symbol/style and
streets (= table = keyname) get a street line map symbol/style.

How would you do it in OSM better than with unicolored node and a line
symbols?

- S.
2008/2/15, Nick Black <nickblack1 at gmail.com>:
>
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/dev/attachments/20080215/5c94acea/attachment.html>