2008/2/15 Stefan Keller <[EMAIL PROTECTED]>: > 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 <[EMAIL PROTECTED]>: > > > > 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 [EMAIL PROTECTED] http://www.remote.org/jochen/ > +49-721-388298 > > > > > > > _______________________________________________ > dev mailing list > [email protected] > http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev > > -- Nick Black -------------------------------- http://www.blacksworld.net _______________________________________________ dev mailing list [email protected] http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev
