Ah, Richard, its very hard to argue with someone who uses XKCD to illustrate their point, unfair !
But, "no official tags" ? truish. But when I am speaking to someone, I am free to make up new words and grammar, but should not expect to be understood. Better to agree in advance. And yes, bike riders have a different view of whats paved. At the risk of incurring an horrendous attack from the lycra clad, when it comes to looking at maps before travelling to new destinations, they are a subset. Maybe not where you live. A subset that should use surface=, should be allowed to and supported doing so. I'll keep using surface= Thirdly, a bit more philosophical, do you think that all OSM keys are locked in stone ? Should we never have the chance to review whats happening, decide we got it a bit wrong, try again ? The sins of the father shall be visited upon the son..... The truth is the paved/unpaved state of a road is being widely ignored or incorrectly interpreted. The map at osm.org illustrates my point, perhaps as well as an XKCD cartoon :-) Zoom in a bit at OSM and pop out the Key, it shows how unsurfaced roads are rendered. But you don't see that on the map. Current model does not work ! We can continue to argue is OK anyway or we can fix it. Choose. David On Mon, 2014-09-22 at 01:13 -0700, Richard Fairhurst wrote: > Tomasz Kaźmierczak wrote: > > I would like to suggest making the paved key for highways > > (and probably other types of elements) official. > > First of all, this is OSM: there are no "official" or "unofficial" tags. Use > what you like as long as it accords with core OSM tagging principles such as > verifiability. > > Secondly, however, as someone who parses surface tagging for both routing > and rendering at http://cycle.travel/map, this proposal is unnecessary. > (cycle.travel renders paved cycleways, firm unpaved and rough unpaved > tracks/cycleways differently, and applies different routing penalties based > on surface.) > > Your use case is that the new tag would make it easier for data consumers to > tell whether a road is paved or not. It wouldn't. It's already very easy. > You simply have a list of the surface= values that your application counts > as paved (and this isn't as universal as you might think: are cobblestones > "paved"? They're fine if slow in a car, but torture on a thin-tyred road > bike). > > This is literally just two lines of code in an osm2pgsql Lua tag transform > script, and thus available to anyone using the standard rendering toolchain. > If you don't want to do it this way, you can run a Postgres query > post-import, or just some extra conditions in your Mapnik/Carto .mml file. > It's really not hard. > > Please, please, please don't fall into the trap of trying to optimise for > data consumers when you're not a data consumer. OSM has far too much of this > and it's resulted in a lot of nonsense tags over the years. Since you'd > never reach 100% coverage for paved=, the data consumer would need to > continue to parse the surface= tag. So the main effect would be to make life > _harder_ for data consumers, who would now have to check not just three > surface-type tags (surface=, tracktype=, smoothness=) but four. Or in other > words: > > http://xkcd.com/927/ > > cheers > Richard > > > > > > -- > View this message in context: > http://gis.19327.n5.nabble.com/New-key-proposal-paved-yes-no-tp5817998p5818124.html > Sent from the Tagging mailing list archive at Nabble.com. > > _______________________________________________ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging _______________________________________________ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
