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 <[EMAIL PROTECTED]>: > > 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 > > dev@openstreetmap.org > > http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev > > > > > > > > -- > Nick Black > -------------------------------- > http://www.blacksworld.net >
_______________________________________________ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev