Proposal talk:Surface unification

surface=

Paved/unpaved and material can really be combined in one tag, as cobblestone/asphalt/concret among other would indicate paved while dirt/sand/gravel among other would indicate unpaved. A discussion can then be if a bridge covered with planks are paved or unpaved, I would vote planks are paved. Evenness, quality, hardness and groundclearance are unnecessary IMO --Skippern 15:07, 3 December 2008 (UTC)

No, there are many unpaved asphalt ways and I have also seen some paved gravel ways. Your planks sounds very paved... We are in draft status, please improve! --Phobie 18:18, 3 December 2008 (UTC)

I am just trowing up balls here, I can clearly see the draft status, I will not do any editing on the status itself as I might have run without notice in the middle of an edit, since I only do this to fill in dead time at work. --Skippern 18:25, 3 December 2008 (UTC)

Better watch some youtube-videos if you are just boring! --Phobie 13:27, 5 December 2008 (UTC)

YouTube is blocked by firewall, but that is drifting off from topic. --Skippern 13:50, 5 December 2008 (UTC)

I agree with skippern. How is an asphalt road unpaved? Surely someone had to put the asphalt there, and that process is called "paving". --Hawke 19:25, 5 December 2008 (UTC)

There are roads without demarcation and broken / washed out asphalt they were once paved are but are not anymore. --Phobie 05:35, 6 December 2008 (UTC)

That is called lack of maintenance of a paved road, not unpaved. Lack of maintenance doesn't magically unpave a paved road, though it can be decided later to downgrade it, than the remaining bits of tarmac would just be there to erode away, and the road can be classified as unpaved (no more tarmac). --Skippern 03:18, 3 February 2009 (UTC)

I don't get it - I always thought that "paved" was analagous to "tarmac" (or bitumen/macadam/etc). So paved implies a properly constructed stone and tar road base. Concrete, I guess, is the one exception here (it's also a properly constructed road base, but different surface material. -- Gaffa 01:00, 6 December 2008 (UTC)

render

This should not have any impact on the rendering unless you are in extremely close zoom, on such detailed level you could for instance indicate cobblestones as a checkered pattern on the road in question. --Skippern 15:07, 3 December 2008 (UTC)

Yes, surface-keys are very usable for routing, useless for POI-searches and usable for rendering with scales lower than 1:10000. --Phobie 13:25, 5 December 2008 (UTC)

tracktype

You cannot write "tracktype=* has not been accepted." It is present 220,000 times in Europe (Tagwatch) ! -- Pieren 14:28, 5 December 2008 (UTC)

Maybe the text should have been "tracktype=* have not been accepted through a process on the wiki but seems to be in wide use by the community"? --Skippern 14:38, 5 December 2008 (UTC)

I don't meant the voting process! I mean that is hard to distinguish between different tracktypes. --Phobie 14:45, 5 December 2008 (UTC)

While it is used widely, tracktype has not been accepted as being good tagging praxis. The values are emotional like in smoothness. If smoothness is used 220000 times it will still not be accepted. Perhaps the text should be changed a bit. See Talk:Proposed_features/grade1-5 --Phobie 14:44, 5 December 2008 (UTC)

condition:road-only?

Please consider paths such as the above. I would describe that as "uneven" at worst, yet none of the surface:condition=* values would seem to apply to it. It's not rocky (those are roots, not rocks), and were it wide enough, most normal cars could handle it.--Hawke 19:17, 5 December 2008 (UTC)

I guess rocky can translate to bouncy/rocking as well as to the actual rocks. Same applies to rutted. If we are ending up arguing about the meaning of words, maybe we should have numerical values, but than we will return to a discussion about interpreting the numbers. --Skippern 19:48, 5 December 2008 (UTC)

Hmm...I would not expect a "rocky path" to have a surface which contained no rocks. My point was more that this is how the path is expected to be -- there's not going to be more maintenance than there already is on that path. (i.e. that path is (probably) surface:condition=maintained, but smoothness=very_bad.) --Hawke 19:53, 5 December 2008 (UTC)

The pic looks like a walking track, so uneven would be the best descriptor for that. If it was a standard road, I would have classed that road as "rutted/degraded". When I wrote up uneven in the smoothness talk page, I had in mind paved roads that had been heavily patched up (potholes filled in, cracks patched etc), providing an uneven surface (but not a surface that you would describe as rough). If you've ever been to Malta, pretty much all the main inter-town roads on the island of Gozo would be described as uneven. -- Gaffa 01:04, 6 December 2008 (UTC)

condition:subjectivity

The values are no less subjective than in the ones that it hopes to replace (smoothness, tracktype). So that doesn't seem to be a point in favor of this one over the others. (How often are "regularly" and "occasionally"? Is a road which is only maintained once every 15 years, yet is still in perfect shape after 20 considered "maintained" or "degraded"? Where's the line between "ruts" and "deep ruts"? Is something only considered "rutted" when the ruts pose a problem, or are any ordinary tire paths considered "ruts"? (see the example image for tracktype, grade 3).) Well done finding suitable value names though. --Hawke 19:17, 5 December 2008 (UTC)

I don't think we'll ever remove subjectivity from this, but any move towards lightly more definable terms, instead of "good", "very good" has to be an improvement IMO, however slight.

I think it would be possible to provide enough additional description for each tag value to limit the subjectivity. "Maintained" was just the best term I could think of - it's not really the time between maintainance periods, but the fact that the roads is in good condition (ie: looks like it did (within reason) when it was first laid down). All roads deteriorate over time, so the surface condition is expected to change over time as well. -- Gaffa 01:10, 6 December 2008 (UTC)

condition:corrugated

Is it really necessary to have a separate condition for this particular problem? IMO, it would simply be one of the possible problems that would lead to a road being classified as "uneven". --Hawke 19:44, 5 December 2008 (UTC)

Obviously you haven't traveled much in countries with many dirt roads and heavy rainfall. --Skippern 19:49, 5 December 2008 (UTC)

Trust me, I'm familiar with the phenomenon. Around here it's called a "washboard road" rather than "corrugated", but it's common enough. I admit that I am not clear on how it happens, but if I take as fact the statement "found on dirt roads that haven't been maintained" that suggests that it should be a criterion for surface:condition=uneven. --Hawke 19:57, 5 December 2008 (UTC)

You are kind to it, I can easily keep 60kmh on uneven, while this corrugated condition I have serious problems keeping 30kmh. At times I cannot go fast enough to enter 2nd gear on my car. Would probably help if I got that 4wd that I want though. --Skippern 20:00, 5 December 2008 (UTC)

Perhaps I am. I'd put it at 35kph as a reasonable speed. But even that's not so much a question of whether it can be done but instead whether it's comfortable -- and how much risk of damaging the car is posed by the vibrations. 4wd doesn't help much, better suspension does. --Hawke 20:18, 5 December 2008 (UTC)

By mentioning the 4wd that I want I implies that a Ford EcoSport have much better suspension, higher ground clearance and stronger engine than the Fiat Sienna I have been using, and all of this will increase the comfort and possible the comfort speed on roads with this condition. --Skippern 13:01, 6 December 2008 (UTC)

Anyway though -- this surface condition doesn't really cause a major problem for anything, just slows them down. Perhaps we need a value in between uneven and degraded? --Hawke 20:28, 5 December 2008 (UTC)

Corrugations are all about speed - forget 35km/h - blast through the corrugated roads at 80km/h and it will be much nicer (I'm actually being serious here rather than a smartarse - you'll find it much easier and smoother :-) . I added corrugations as a surface condition original;y, mostly because I think it's a specific surface condition, distinct from uneven or rutted. -- Gaffa 00:16, 6 December 2008 (UTC)

If you think it don't fit just use surface:condition=uneven surface:corrugated=yes! --Phobie 05:48, 6 December 2008 (UTC)

rocky and huge_rocks

I'm trying to find pictures in the real world to see if surface:condition=* can handle all cases. I came across this rather surface:condition=rocky. But it might no be what is supposed by "rocky". I suppose I would tag this as path for now, but since some extrem vehicles might use it, maybe find something "over" rocky ? ( For the story, the 4wd on the picture went stuck just later and people kept going on foot, but the track was marked as usable on a map )

• surface:condition=big_rocks ?

Sletuffe 01:11, 6 December 2008 (UTC)

I would say that the map in this case was outdated, wrong, or inaccurate. The road should probably been marked as a trail or path as it clearly is close to unpassable by cars. --Skippern 13:04, 6 December 2008 (UTC)

The picture here is clearly not passable by cars (even hardly passable by off road vehicle), my point is that it is still passable by special vehicle equipement. (see the first paragraph here concerning "off highways vehicles" off road vehicle). And I'd like to capture this with tags because I think it is not equal to a path or hiking trail. Sletuffe 15:07, 6 December 2008 (UTC)

So the definition of road we are to use is where Sletuffe can drive with his off-road vehicle? I feel that the use of extreme cases to push the scale are derailing the entire proposal. --Skippern 18:24, 6 December 2008 (UTC)

This is the extreme end of the scale, but does need a tag of some sort - rocky doesn't cut it for those type of rocks :-). Can't think of a good one off the top of my head, though. Perhaps "primitive"? -- Gaffa 01:14, 6 December 2008 (UTC)

Maybe "unformed" would be better... -- Gaffa 01:21, 6 December 2008 (UTC)

Just by that image: for that rocky part surface:material=boulders (Particle_size_(grain_size)) + surface:condition=degraded + barrier=scree? Foreground track then surface:material=dirt + surface:condition=uneven. Alv 12:44, 6 December 2008 (UTC)

Think of routing program

Keep also in mind that a routing program should take advantage of those values to help lead a car to it's destination while not destroying is under cariage. Something like if tagX+tagY+tagZ then it should be usable by a car. If at least tagA, then very risky for a car. Or else this tag will unusable by routing engines Sletuffe 20:04, 5 December 2008 (UTC)

deprecation objectiv too high

Ouch, you propose to deprecate : "This proposal should replace surface=* and abandon Proposed_features/Smoothness, Proposed_features/surface_values, Proposed_features/more_surface_values and Proposed_features/grade1-5!" ?

I fear you have set the bar too high, we might face too much objection. I belive this proposal should be use in conjonction or in "going futher" than other one (or just one you mentionned ;-)) Sletuffe 20:10, 5 December 2008 (UTC)

I wouldn't get rid of surface, but just expand it to include more values for the material (given that "paved" is a poor way of saying asphalt/tarmac). Unpaved is a bit useless, but I guarantee you could substitute in "dirt" for all values, and still be correct (it's really the base default surface type - everything else is a variation on the theme (but important variations nevertheless).

Abandoning smoothness wouldn't be a bad thing - I don't like the valus personally, and the surface values propsoals just need to be combined into a single improved proposal. TrackType is more problematic. It was a crap tag to start with (for one thing, if you use sequential numbers, you can't easily refine the set at a later stage, as you are unable to insert a new value between 2 and 3, without going into decimals. At least with actual words, you can insert more into the list without affecting the order), but it is heavily used. I guess it's a case of leaving it there, and going forward using a more defined and flexible structure -- Gaffa 01:19, 6 December 2008 (UTC)

Intentionally I do not use the surface-key itself so this proposal does not interfere with it. Later I want to suggest the new surface:*-keys above surface=* but we don't get into trouble if someone just keeps tagging surface=*. In a year or so we can look at the acceptance of the new keys and perhaps could try to convert some of the old values to the new keys. --Phobie 06:03, 6 December 2008 (UTC)

I fully agree with Phobie on this. First of all, get workable values to existing tags, and a new good base of values for whichever new tags we need, than if it works, and the tags we wish to replace are abandoned, a bot can later convert them to the new values. --Skippern 08:55, 8 December 2008 (UTC)

Corduroy (and other surface types)

Um, what's corduroy as a surface type? I always thought corduroy was a material used for making jackets for professors (ideally with elbow patches). Bitumen and asphalt are the same thing (apparently asphalt is the US term), and tarmac and macadam are for all intents and purpases the same (tarmac being tar based macadam). Lastly, is "ice" a valid surface? It's a bit outside my knowledge, given there aren't too many places where we get ice on roads in Australia. -- Gaffa 01:36, 6 December 2008 (UTC)

I took the values from Proposed_features/surface_values. IMHO corduroy, bitumen and tarmac can be removed. For ice I would use surface:iced=yes/no/winter/Dec-Feb. See Key:opening_hours! --Phobie 06:13, 6 December 2008 (UTC)

Updated the table to reflect that... --Phobie 07:40, 6 December 2008 (UTC)

Some roads are across frozen lakes in winter, so the ice isn't just a coating over some other surface. Ojw 15:31, 6 December 2008 (UTC)

Yes, see the updated table! --Phobie 16:15, 7 December 2008 (UTC)

IIRC, a corduroy road is where the surface of the road is made up completely of logs so that the road has a similar appearance to corduroy fabric. -- sadam 12:45, 1 May 2009 (UTC)

I fear we cannot capture every needed thing by objective analysis

Also while reading me and knowing my point about smoothness, you might feel bad faith from me. There might be a bit, so tell me, but I'd like to express my fear that such a sheme cannot clearly define usability by vehicle. It might well come close (if one use quite a few tags) but I'm a guy of mountain, and every time someone talk to me about a track, or by reading a map, there is a time when I have to answer, "can I go there with my passenger car, or do I need to go by foot"

Here is another picture to try to illustrate:

In the alps, such tracks are not uncommon, they are mostly used to bring wood logs, equipements, or food to alpine_hut to replace expensive helicopters transport. Also this track could be tagged :

• surface:condition=uneven (because it is badly maintained, but enough to stay passable 10 month per year)
• incline=40% (problem is that incline is not approved)
• surface:material=gravel (problem is that on the way it might change to grass or to dust or mud)
• width=2.5m
• groundclearance=no

The problem, I see, is : "what can I suppose from that ?" It rather look (except maybe because of the incline) that it is passable by passenger car. The truth is that no, it's not. Most passenger car's engine will fail in steep parts, not only because of the incline (if asphalt was there no problem) but because, there is mud in the part with 40% incline. 4wd is needed there. and sometimes a tractor is needed. My question is how could we construct a reasonable mapping between the objective information we have of the ground to the actual passability of the track ? And worst part I'm scared of, how will mappers understand the implications of their "objective ground tagging" ?

I repeat myself, I am not against such a sheme, my fear is that it is too complicate for pragmatic usage if it is intended to replace a way to tell the usage of a road.

Other have propose something like "scales for everything" here is my idea on : why or why not a scale for everything

Sletuffe 15:49, 6 December 2008 (UTC)

We can not cover everything with this proposal, but for sure it will improve mapping.

As said before, invent a new vehicle-specific scale like mtb:scale:sts and sac_scale for 4wd-motorcars! I'll comment on "usability" later.

To your examples: You should split the ways and tag different parts with different values.

--Phobie 16:27, 7 December 2008 (UTC)

Our goal isn't to capture everything. It's to capture things we can reasonably capture. I'm not sure about having the two subkeys for surface, but the core idea is good. Like tracktype=*, unlike smoothness=*, this tries to restrict the tags to facts that can be observed objectively. Either a surface is concrete or it isn't. I foresee some variation on the "condition" part (e.g. someone will probably enter "potholed" for a poor surface), but that's not all that bad. An important point working in its favour is that it doesn't redefine existing words, but rather uses them for things they already mean (for example, "rutted" vs. "bad"). Chriscf 12:00, 10 December 2008 (UTC)

The definitions of the scales doesn't have to be the same for all types of way/track/path, what is uneven on a motorway is excellent on a path, what is uneven on a horse-track is primitive on a motorway. The purpose of the road have to be taken into account when actually setting the value. But no matter how we turn this around, this will all come down to objectiveness. It is not good to set values with vague definitions in a spatial database such as OSM, but seeing the discussions around track and smoothness, maybe it is time to give in and make a system as clearly defined as possible. At least we are trying with this. Besides, for types of tracks where skill and equipment level is important, please get a proper scale to tag it with, don't let surface conditions be the scale. --Skippern 12:16, 10 December 2008 (UTC)

riding the horse, the other way round

Let me start a more philosophic approach:

most mappers seem to think in ways of 'true' or 'false'. I don't think 'correct' is a good term for a map. If you want to have a look at the most correct map, go out to the spot you are interested in and look by yourself. You can't get a better map!

Just keep in mind, that one thing is needed to use a map: brains. If you download a track to your GPSr, you see an abyss in front of your feet and the track says "go ahead", what would you do?

Maps are made to be interpreted by their user. That's the reason why there are so many kinds of maps.

Scaling ist always a problem. It has been for decades. I studied marketing research. The researchers have a solution for this problem but it does not fit our needs. It is far too complicated.

So why not take the pain and make a joy out of it?

Instead of arguing wether something is right or wrong, think of it as 'helpful' or 'misleading' instead. The reason for making a map is not a bored life, it is 'someone can benefit from what I do'.

The interesting point is the usability of the map. And as there are so many different uses of a map, there need to be different scales as well.

Be realistic, you will never find a perfect match for everyone's needs. You need to 'normalize' scales to a reasonable set of different use cases.

What's the interest for a map's user? It is 'should I go that way or shouldn't I? How much effort will that be?'

A hiker will need information over a way's hikability. A handicapped will need information about whether the way might be difficult. A sportscar driver will need information about whether his car will get damaged. An inlineskater will need some more than even that.

But you can get the info you need by being stuffed with brains. Riding a citybike on a track marked as 'tough' by a hiker will give you enough information for your decision.

That means, different scales can match certain needs, not only for the scaler's interpretation. And different ways can produce different results, even if the scale is tagged identically. (->object-oriented?)

'Never map for the renderers'

Writing a routing algorithm will as well be a decision of brains. A german programmer living in Munich will produce a different interpretation than a developer from Djanet, Algeria. If you choose the Algerian style routing, this also will be a decision of brains. I think most algerian citizens will not understand someone's need to hike through the desert at all.

'Never tag for the algorithm'

I would suggest several categories of scales for a small number of uses and fill them with a standard scheme. The category will decide by it's special user profile about how a way is tagged 'correctly'.

Let me make an example:

MTB:tough

Pedestrian:challenging

4x4:intermediate

citycar:impossible

skates:easy

handicapped:impossible (wheelchair=no is a different case)

enduro:challenging

sportscar:easy

(8 scales, 5 values)

Even if I don't have a sportscar, I can decide that a certain way is usable by such a vehicle and tag the way. If I can't, I just keep my hands off the keyboard. The default will depend on the way. A track will surely not be usable by a skater. But it will be easy for a 4x4 and intermediate for a citycar. A sportscar will scale a tertiary road 'intermediate' by default. And, no, we dont' make maps for a tank! :-)

Do not try to interpret the tag for the developer of a routing algorithm. Tag as to what you find reasonable. The scheme is simple and understandable. It does not cause lots of work and supplies useful, and standardized, information. It is not perfect, but perfect is only reality.

Let me add one thing: whether a way is usable under certain weather conditions does not fit into this category. Weather conditions are different in different places and post different problems. Extremely dry weather makes sand slippy whereas rain makes sand solid. Rain forest people will surely think different about that.

Tracktype is not such a bad idea. It describes the capability of a way to change it's face under certain conditions. In company with the usability scales a similar tag supplies the user with valuable basic infos. But it must be a cooperating tag.

Change the routing algorithm instead of the tagging. Interpretation of tags will always be the job of the user or the programmer. Interpretation of routes will always be the job of the user. --tmeller 22:47, 26 February 2009 (UTC)

I couldn't sumarize my thoughts better than you did ! Just two useless comment from me if you don't mind :

By tank, I suppose you are talking about smoothness, and that's me who wrote "tank" in the first place as a kind of joke, to show that the list requires some sort of "brain" rather than exhaustive listing of any possible vehicles

You said Interpretation of tags will always be the job of the user or the programmer : well yes, but if there are none, he cannot interpret anything. So a minimum of tags is needed, and not too vague. Sletuffe 09:25, 27 February 2009 (UTC)

Seems we share the same thought. I didn't read your writing or at least I don't remember.

What I suggest is a matrix of scale:value pairs instead of a scalar attribute. I just don't know how to best map this into OSM's data model. --tmeller 15:27, 28 February 2009 (UTC)

How to tag ?

How would you tag a railway platform with cobblestone or other uneven lines in it, used as wayfinders for visually impaired persons with a stick? --Lulu-Ann 16:50, 6 March 2009 (UTC)

I don't see a problem here: railway=platform + surface:material=cobblestone --Phobie 10:56, 4 April 2009 (UTC)

That probably isn't a problem anymore thanks to your tactile_paving=yes proposal? I generally wouldn't have liked using surface keys for that, as these features usually cover only a small part of the platform, so they aren't the prevalent surface type there. An additional key is superior. --Tordanik 16:37, 4 April 2009 (UTC)

Yes, I made up that proposal to solve this problem. Thanks for relinking. Lulu-Ann

Why not using the existing surface-values?

I don't see the reason for having surface:paved since this information can surely be derived from surface:material.

Also, why isn't the existing list of surfaces used for surface:material? The list on Key:surface is quite exhaustive already and it can always be amended. In my opinion it would bring the whole surface-tagging business a big step forward if well defined and easily understandable list of surface materials exists. This list should contain example pictures for the different surface values, clear descriptions which also explain the differences between similar values, and also synonyms and translations. Obviously, such a list can not be created with an armchair decision but by using it and constantly improving it until a good set of values emerged. Therefore, I think it is really important to improve the existing list instead of starting a new one. --Xoff 10:09, 1 May 2009 (UTC)

Is there anything preventing you from amending the lists? The important thing here is to unify the tagging of surfaces as we now have several tags covering similar values. I see it more important to get an approved set of tags and an agreed set of values, than what values are missing out. Missing values can always be amended later. --Skippern 12:55, 1 May 2009 (UTC)

Of course, I could amend the list here but that is not the point. I was wondering why you did not use the existing list which is already linked on map features and which just needs some care and more values. IMHO a unification would be much more successful if it builds on existing work instead of redefining everything from scratch. surface= is already available in editor presets, so it will be much easier to convince maintainers to just add a couple of more values to this tag rather than adding a complete new set of tags for something where already three tagging schemes exist. At the end of the day it is not approval what counts but what is in the editor presets and what is rendered. --Xoff 16:26, 1 May 2009 (UTC)

Exactly, we are trying to replace three different tagging schemes with one, since the three schemes are describing similar things, some of which (i.e. smoothness) are very lacking, have objective or emotional values, and such. Surface is the tag that was best made up to begin with of the tags that we are grouping in this proposal. --Skippern 18:08, 1 May 2009 (UTC)

Add "useful" keys like ground, earth, mud and dirt from Key:surface? Well defined and easily understandable would be nice. Please help! The idea behind this proposal is to separate (un)paved from the materials. So I would be able to mark a gravel road as paved or as unpaved. And the surface:condition key should give a hint about the usability of a road. --Phobie 11:42, 6 May 2009 (UTC)

Conditions for airport roads

The FAA uses a Pavement Condition Index (PCI) to describe runways, taxiways and aprons. PCI values range from 0 to 100, as shown below where 0 indicates failed pavement and 100 is new pavement:

PCI value	Condition
86-100	Excellent
71-85	Very Good
56-70	Good
41-55	Fair
26-40	Poor
11-25	Very Poor
0-10	Failed

--StudentinGear (talk) 04:22, 2 November 2018 (UTC)