On 9 May 2008, at 11:05, Dave Stubbs wrote: > > As far as I see it there is no difference between mapping 11=autobahn, > and mapping motorway=autobahn.
I think you missed the point. At present we have highway=motorway and I believe a German user would need to use these words. What I suggest is that if Potlatch is used on a German computer the user would be presented with a menu of road types starting with 'autobahn' while I would see a menu starting with 'motorway', both mapping to a database field of (hypothetically) 11. I can't see how 'motorway=autobahn' helps with anything. > > >> Places of worship could be mapped as cathedrals, >> churches, chapels, etc in Britain or as mosques, temples, shrines, >> whatever in the east. > > Um... except that Britain has quite a lot of mosques, temples and > shrines. These are different things, not the same things named > differently. Fair point - I didn't think that one through until I'd clicked SEND. Best not talk about religion, eh? >> > This is why we don't have (and have resisted) tags such as > highway=red. Point missed again! I'm saying separate rendering from tagging. highway=red is exactly the opposite of what I'm suggesting. > > People have done customised renderings... see Freemap Slovakia for > example: > http://www.freemap.sk/? > lang=en&zoom=8&lat=48.49281826990847&lon=18.326709281821315&layers=BF0 > FFFFFFFT > Yes. Anyone can put up their own viewer, but I imagine most use the one on the OSM site and that could (possibly) render the content differently according to the keyboard language or to some locale setting in its control panel > >> >> Another aspect of the base data structure is that of level-of-detail >> (LoD) filtering. ... >> > > If you consider something like the cycle map where we have ncn as > the things that should show up at zoom level 6 instead, then we have > to apply different rules. No problemo! Special viewers like the cycle map would simply apply their own filters. And with well-structured data a map viewer could even have settings (eg. cycle routes on/off) allowing it to be customised by the user, making a proliferation of specialist viewers unnecessary. > So we only really gain something if the LoD demands happen to coincide > with the data model you define. > > LoD is generally a more complicated problem that requires you to > actually define a whole array of features, and mechanisms for > simplification. I never said it was going to be easy :-) I do think that LoD demands are something that should be considered in designing the data structure. (I also think elevational data should be well integrated, too, but that's another topic.) _______________________________________________ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
