I meant "rendered as paved" in these situations indeed. I believe you may prefer 3 different renderings: one for the absence of the surface tag (same as the current default style), one for paved-like surfaces (perhaps some darker solid outline - but we need to distinguish that from bridges and viaducts), and then yet another one for unpaved-like surfaces.
It seems quite subjective whether we should adopt 3 different styles, or only 2, and which to choose as the default style (paved or unpaved). Let me try to throw in some thoughts. Perhaps statistics can help. How many highways do we have in OSM today? 69,750,051. How many have a surface tag? 11% of them (7,383,161 ways). When used, how often does the surface tag contain a "paved" or an "unpaved" value (for the interests of rendering)? Considering the top 50 values (which amount to over 99.5% of all uses of the tag), we have 56% on the paved side and 46% on the unpaved side (see my listings at the end). Among these, we have 18 paved surface types, 26 unpaved types and 6 unknown types. The top 95% most common paved surface types are asphalt, paved, concrete and paving_stones (only 4 values), and the top 99% includes cobblestone and wood (6 values so far). The top 95% most common unpaved surface types are unpaved, gravel, ground, dirt, grass and sand (6 values), and the top 99% includes compacted, pebblestone and fine_gravel (a total of 9 values). In favour of adopting 3 different renderings (or no specific rendering) is the fact that the vast majority of roads lack the surface tag. (Note: even less of them, only 4%, include the tracktype tag.) In favour of unpaved as default, one could argue that mappers seem more concerned with specifying a surface when the surface is paved. This could result from OSM communities being more active in paved areas. You could also say that pavement correlates with economic development, as does participation in OSM, so choosing the unpaved style as default would be more often correct in places that more likely lack this tag. However, I imagine that paved as default would please most active communities. They wouldn't feel a push towards completing that information where it would seem "redundant" (because everything around them is paved almost by default). Ethically, I think unpaved as default would be best. It would put strain on the side that has the mapping workforce to handle it (Brazil included). The fact that there's greater diversity of unpaved surface types could favour both a choice towards easier maintenance (defining what's paved and considering everything else, including new values, as unpaved) or against diversification (defining what's unpaved and considering everything else as paved would discourage the creation of new values on the side that already has most values). Maybe diversification is desirable, even though it's not always best for applications. --- Listing 1: way count of paved ways 2193896 asphalt 1479671 paved 195633 concrete 174309 paving_stones 111608 cobblestone 22176 wood 3623 concrete:plates 3609 grass_paver 3171 paving_stones:30 2731 metal 2342 concrete:lanes 1871 bricks 1685 sett 1664 tartan 1605 cobblestone:flattened 1605 interlock 1389 cement 295 tarmac 4202883 TOTAL Listing 2: way count of unpaved ways 1388766 unpaved 632416 gravel 504667 ground 280709 dirt 242492 grass 100910 sand 84121 compacted 20050 pebblestone 10129 fine_gravel 6396 earth 4249 mud 2869 dirt/sand 1965 clay 1126 grass;earth 1083 ground;grass 885 artificial_turf 669 gravel;ground 554 grass;ground 456 pebbles 365 grass;sand 353 trail 330 gravel;grass 316 no␣data 303 hard 274 ash 270 soil 3286723 TOTAL Listing 3: way count of unknown surface type ways 1517 stone 1067 rocky 918 rock 611 limerock 286 unspecified 282 laterite 4681 TOTAL On Wed, Jan 1, 2014 at 4:02 PM, Peter Wendorff <wendo...@uni-paderborn.de> wrote: > Am 01.01.2014 17:28, schrieb Fernando Trebien: >> A combined approach makes sense to me. Then people can choose if they want >> to use the tracktype tag or continue using just the surface tag (either may >> make sense in different communities; I'd guess the German community will >> prefer to use tracktype only with highway=track). I think the following >> values of the surface tag could be considered paved: [none] (no surface tag >> present), paved, asphalt, concrete, concrete:lanes, concrete:plates, >> paving_stones, sett, grass_paver, cobblestone, metal, wood, tartan. > I only partly agree on none for your wording to "be considered paved". > If you mean "rendered as paved", I agree, but no information is no > information here, and what's the default heavily depends on where you are. > In many parts of Africa "none" should be considered unpaved by default, > in many parts of Western Europe for highway=residential and above it > would be paved. > Therefore there should NOT be a rendered default assumption in the > Mapnik Rendering where there is nothing. > Leave it as it is no (undecorated) where no value is given. > >> All >> other values, including new and undocumented values, could be unpaved by >> default. > Why should all other values be unpaved, if you don't know about what it > is? You simply don't know if a new value could be counted as paved or > not without investigating that exact value. > I could imagine new values for both, and if you propose rendering stuff > with an assumption that is decided to be wrong for some values, this > will lead to mappers not using correct tags or even tagging wrong to > prevent "the map" to show what they would call wrong. > >> How about this? Moreover, TagInfo ( >> http://taginfo.openstreetmap.org/keys/?key=surface) lists a few other >> undocumented values that may be considered paved, such as >> cobblestone:flattened (same as sett? to be discouraged?), bricks and >> interlock (both similar to paving_stones?), cement (quite similar to >> concrete?), stone and rocky and rock and limerock and granite (similar in >> practice to sett or cobblestone?). > You see: There's quite a lot, so don't use defaults here when applying > rules to the default map rendering. > The Mapnik Map IMHO should show what's in OSM, not what one could > estimate out of it. > > regards > Peter > > > _______________________________________________ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging -- Fernando Trebien +55 (51) 9962-5409 "The speed of computer chips doubles every 18 months." (Moore's law) "The speed of software halves every 18 months." (Gates' law) _______________________________________________ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
