--UrSuS 12:46, 29 May 2009 (UTC)
Values in addition to paved/unpaved
If the surface key is to be used, I would like to use the cobblestone/gravel values in addition to paved and unpaved. --spaetz 19:57, 12 June 2007 (BST)
- I agree. I've been using surface=gravel and surface=dirt as one means of distinguishing between classes of tracks. Robx 10:36, 25 February 2008 (UTC)
- People are using the surface key with all kinds of values actually. gravel, cobbles, cobbled, grass, tarmac, unsurfaced, sets, mud, hard, cobble, asphalt, cobblestones, sand, concrete, paving, loose, muddy, boardwalk, tar mac, none, sealed, dirt, woodchip See the Tagwatch stats.
- Out of all we've chosen to add cobblestones in addition to the paved/unpaved values originally on here.
- I don't necessarily disagree with the addition of cobblestones, but there's a couple of confusing things.
- "Paved/unpaved", the original values, actually encompassed any kind of man-made surfacing including cobblestones and tar mac actually. Am I understanding that correctly? It says "surface=paved - A highway feature is predominantly sealed along its length, i.e. it is covered with paving stones, concrete or bitumen.". I wouldn't normally describe a tar mac surface as "paved", and where does that leave all these other values people are using? and how does the addition cobblestones fit it?
- The word "Cobblestones" is often misused to describe "setts". see wikipedia:Talk:Cobblestone#Cobbles and Setts. This distinction might be important if you want to know for example how easy will it be to cycle/skate over a surface (or how slow you'll have to drive) Now a #cobblestone:flattened vs sett below
- -- Harry Wood 00:16, 2 May 2008 (UTC)
So lots of those values have been added in now in a table. It's still not clear when you would use paved/unpaved though -- Harry Wood 15:41, 28 November 2008 (UTC)
Shouldn't the default be paved for everything except track? not everything except unclassified? Kpalsson 17:46, 15 September 2007 (BST)
I suppose everything except track and footway would be the way to go.--Guenter 16:18, 18 December 2008 (UTC)
This is currently not affecting rendering, secondary, and secondary+unpaved are being shown exactly the same way. This makes this tag fairly useless at present? Kpalsson 13:56, 25 September 2007 (BST)
Actually, if improved, this key could be very useful for roller skating. But this would be very important to distinguish the roads that are "covered with paving stones" and the ones with "concrete or bitumen". That's a BIG difference for roller skating.
The picture of ice road must be there mistakenly? I think it only makes sense to tag roads on iced water as ice roads, for example, roads across lakes and rivers when the ice is thick enough. Every other usage would easily lead us double tagging surface values. Practically every surface could become iced in right condition. Repetitive combinations like surface=asphalt + surface=ice_road would not be very useful. Lazzko 10:20, 19 September 2008 (UTC)
- Looks like a wrong picture (depicting winter road, not ice road) has been imported from Wikipedia article. Lazzko 23:54, 19 September 2008 (UTC)
Imported a proper ice road picture from Wikimedia. Case closed? Joosep-Georg 20:53, 30 January 2010 (UTC)
- Looks good! lazzko 14:12, 6 March 2010 (UTC)
using paved everywhere
this page says "The term paved/unpaved road is used in the UK, the term sealed/unsealed road may be used elsewhere".
i believe this is a very bad idea, as it would require every editor/renderer/navigator etc to implement several values for the same thing. it might also open the way for some sort of nationalised tag values/tags, which would be a disaster. i'd suggest deciding on a single definition for a single feature. i've been using 'paved' so far.
This tag makes it quite difficult to have a clear hierarchy for routing purposes. Could someone who claims to understand the purpose of this tag update the hierarchy at http://wiki.openstreetmap.org/wiki/Highway_tag_usage?--Guenter 16:16, 18 December 2008 (UTC)
metal / wood
I'm missing this surface... Both used for smaller bridges (mainly for pedestrians and bicycles wihout asphalt), wood also for swampy areas http://en.wikipedia.org/wiki/Corduroy_road --Mueck 21:47, 17 April 2009 (UTC)
- +1 for using surface=metal or surface=wood for bridges with those sorts of surfaces. Not sure about corduroy roads: those would seem to be something different: more than one material, for one thing. --achadwick 21:53, 23 April 2009 (UTC)
- What about raised plank walkways for foot traffic through swampy areas? I think I've used surface=wood for those too, even though they're more of a construction than a simple surface. --achadwick 21:53, 23 April 2009 (UTC)
- I also add metal an wood. Yes, I also now see, that corduroy has an additional surface above the wood, that's the difference to wood-only? I meant the plank walkways... --Mueck 21:39, 24 May 2009 (UTC)
Combining different surface values
I think it should be emphasized that multiple surface values can be combined (i.e. editors should not only allow the selection of one value). This would be handy to describe roads which are in a bad condition. E.g. an old tarmac road with potholes filled with gravel and grass could be tagged as surface=tarmac;gravel;grass to indicate that the road is mostly tarmac but parts of it are gravel or even grass. The values should be ordered based on their occurrence on the ground with the main surface listed first. -- Xoff 21:42, 25 April 2009 (UTC)
- Separate stretches consisting of single materials should ideally be tagged using separate segments with differing values for surface=*. However, what you've described could be beneficial, I've no objection to it provided you write it up fairly formally and understandably. In your update to the main page, perhaps you could stress that this is for distinct, sizeable and frequent patches of different surfaces which affect ease of traversal and not for: a) aggregates of materials all mixed in together, b) really big continuous sections which warrant ways being split and the split segments being tagged separately? --achadwick 01:37, 26 April 2009 (UTC)
- BTW, multiple surface values cannot be combined now. Or at least, if you do nobody else will know what you mean. Generally, you can't just use semicolons to separate tag values in OSM. It need to be specifically written down that you can do this in the proposal or the tag description page at the very least, and ideally you need support for it from all software that matters. --01:37, 26 April 2009 (UTC)
- Also: "editors should...". You want to be talking to the JOSM people directly about that: it's a new capability for presets.xml: a zero-or-more flag for a selection dropdown, perhaps. Other editors make use of JOSM's presets.xml for their own presets and autocompletes, so that would be the place to start. Could you suggest it via the JOSM trac, and refer them back to this section? Thanks. --achadwick 01:37, 26 April 2009 (UTC)