[OSM-talk] Edit war on the wiki "map features"

Matt White mattwhite at iinet.net.au
Mon Dec 1 11:53:25 GMT 2008

Douglas Furlong wrote:
> 2008/12/1 Matt White <mattwhite at iinet.net.au 
> <mailto:mattwhite at iinet.net.au>>
>     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.


More information about the talk mailing list