Douglas Furlong wrote: > 2008/12/1 Matt White <[EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]>> > > Douglas Furlong wrote: > > > > This makes is pretty straightforward to tag for all vehicle > types > > easily > > - a tertiary road that has a fair few potholes could be > > smoothness=bumpy (given that car is the primary vehicle for the > > tertiary > > highway type) > > smoothness:mtb=bumpy > > smoothness:racing_bicycle=rough (or unsuitable) > > smoothness:tank=normal (or even "glass like" :-) > > smoothness:rollerblade=unsuitable > > > > the bumpy/rough/unsuitable are just examples, and of course would need > further clarification. > > But more importantly, they could be dependant on the leading values. Agreed. That was what I was trying to get to on the Smoothness talk page - a horse for courses approach. Probably not very clearly given my propensity for prolixia > I.E. skate:inline, could have totally different values to bicycle:mtb, > which could be specified by the enthusiasts that use that form of > transport. > > I'm not certain why you want smoothness first, ultimately the end user > should never REALLY have to know about the order these values per tag, > we should be relying on the editors, to have reasonable graphical > interfaces to allow for an easy way of ticking boxing and selecting > drop downs of relevant values. > More just in keeping with existing tag/sub tag keys like name= and name:en= than anything else. Given a lot of the keys that are currently in use, it's getting close to almost requiring a more explicit key/sub key structure (which just leads us to needing key:subkey: subsubkey structure :-) ) > > and renders to render the maps depending on these values. > > > > > > I don't personally like the term "smoothness" either, but > I've yet to > > find a decent alternative ("surface" would be nice, but 'tis > taken). > > > > > If it is the latter as opposed to the former, then I'd rather > see some > > thing along the lines of vehicle:4WD, as opposed to an access tag, > > which to date I believe is being used to indicate permissibility, as > > opposed to suitability, which are not the same thing at all. > It is the latter (it is a recommendation) rather than a legal > restriction. The point of such an explict tag is so that when I'm out > driving, the map actually shows the 4WD state as text (given that > I dont > think the Garmin I have really has any other way of visually > distinguishing the road state/vehicle requirement) > > > This sounds a bit like tagging for the render, which I believe is > frowned upon. > Having vehicle:4wd=suitable (or what ever), could just as easily be > rendered, as a 4wd access tag, however it would fall in to the whole > suitableness kinda argument that is going on. It sort of is tagging for the renderer, although I was only going to mark roads that are physically sign posted as 4WD only (thus removing a large chunk of subjectivity). It's borderline, and I'll just modify the mkgmap script I use for generation of garmin maps for the moment. But given that there's a solid barney going on over the smoothness tag, and the rack tpye and surface tags both suck and don't really convey the meaning... well, who knows. Until then, I guess I have to use something.
I have found some tags kicking around where equipment= was used with reference to diff lockers, mud tyres etc. There's only about 10 4WD tags in the system so far. In the long run, it does sound like the 4WD requirement might be a fairly specific Australian thing, so it might be more useful if us AU mappers agree to something useful and move on from there (note that I'm not a big fan of this regional key stuff, but we are stuck with a lot of UK-centric tags and icons, so maybe it's a chance to get our own back :-P ) > We need to separate visual representation of features, from how that > feature is tagged, as they are not the same thing. > > I'd be curious to know from a maintainer of one of the visualisation > projects, which they would find easier to work with. Ditto. Matt _______________________________________________ talk mailing list [email protected] http://lists.openstreetmap.org/listinfo/talk
