<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div>The tags are not used so often together (from <a href="http://taginfo.openstreetmap.org/keys/surface#combinations">http://taginfo.openstreetmap.org/keys/surface#combinations</a>): </div><div><div><br></div><div>Surface (8 077 811 occurences) combinations:</div><div>1 087 838<span class="Apple-tab-span" style="white-space: pre;"> </span>13.47%<span class="Apple-tab-span" style="white-space: pre;"> </span>tracktype</div><div>175 011<span class="Apple-tab-span" style="white-space: pre;"> </span>2.17%<span class="Apple-tab-span" style="white-space: pre;"> </span>smoothness</div><div><br></div><div>Tracktype combinations:</div><div>46 144<span class="Apple-tab-span" style="white-space:pre"> </span>1.44%<span class="Apple-tab-span" style="white-space:pre"> </span>smoothness</div><div><br></div><div>But if we do want to handle combinations, maybe use surface (the most used tag), multiplied by a factor if tracktype or smoothness is set as well?</div><div><br></div><div>In essense, take minimium of:</div></div><div>- default speed</div><div>- max speed</div><div>- surface speed * tracktype or smoothness factor</div><div>- other things that lower the speed</div><div><br></div><div><br></div><div><br></div><div><div>On 10 Mar 2014, at 17:30 , Fernando Trebien <<a href="mailto:fernando.trebien@gmail.com">fernando.trebien@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">For each tag+value combination, we could assign:<br>- a preference value<br>- a weight value or a priority value<br><br>When using weights, the final preference value would be a weighed<br>average of the preference values corresponding to each tag.<br><br>When using priorities, the final preference would be that of the<br>highest priority tag+value combination.<br><br>Contradictions are an issue, for example:<br>- tracktype=grade1 + smoothness=very_horrible: is it good or is it bad?<br>- tracktype=grade5 + surface=asphalt: is it paved or not?<br>- smoothness=impassable + surface=concrete: maybe the concrete path<br>was very badly built, or maybe we just had an earthquake<br><br>Weighting would "blur" the contradiction, opting for an average<br>preference of the conflicting values. The greater the contradiction,<br>the greater the risk of poor routing decisions.<br><br>A pessimist approach (probably "safer" for the user) is to select the<br>lowest preference value assigned for tag+value combinations present in<br>a way. But then, we lose the ability to use one tag as a refinement<br>for the other (for example: tracktype=grade2/3/4/5 when<br>smoothness=bad).<br><br>A remedy would be a more complex approach which practically encodes<br>the class system that I proposed:<br>- given 3 tag+value combinations, pick the combination with lowest<br>preference value (let's call this tag A)<br>- for the remaining 2 combinations, select those that are considered<br>similar to A (according to some equivalence table) and discard the<br>others<br>- if there are 2 left, also pick the one with lowest preference value (tag B)<br>- possibly pick tag C if it's similar to both A and B<br><br>The result would be from 1 to 3 tags (A,B,C) from which you'd choose<br>the one with highest priority. That's the most accurate preference<br>value within pessimist choices.<br><br>A single classification system would eliminate these problems, and it<br>can be introduced in the community (not necessarily in OSRM)<br>simultaneously with a more temporary solution in OSRM using multiple<br>tags and some sort of contradiction handling. I just wouldn't go ahead<br>and propose it if there's no interest in adopting such a thing in the<br>long term.<br><br>On Mon, Mar 10, 2014 at 11:19 AM, Emil Tin <<a href="mailto:emil@tin.dk">emil@tin.dk</a>> wrote:<br><blockquote type="cite"><br>OSRM focuses on tags that are already in widespread use. From tag info:<br><br>surface 8077811<br>tracktype 3212051<br>smoothness 208379<br><br>Even if a new tagging scheme is agreed on (by whom?) it would probably take<br>quite a while before it's in common use worldwide. So for now I think the<br>question is how OSRM should handle these 3 tags.<br><br><br><br>On 10 Mar 2014, at 14:41 , Fernando Trebien <<a href="mailto:fernando.trebien@gmail.com">fernando.trebien@gmail.com</a>><br>wrote:<br><br>My personal point of view is: they mostly do, but in a needlessly<br>complicated way. I think you'd be surprised at how far the discussion<br>went (over 150 messages, many of which were quite long) to reach a<br>simple agreement: deciding which tags/values to use in order to decide<br>which roads are possibly in poor state, as to deserve special<br>rendering. In this agreement, we settled on 3 tags (tracktype,<br>smoothness and surface) to make such a decision. So it is clear that<br>the community views the 3 tags as "necessary" for reasonable routing<br>choices when reading the map visually. Trying to take any of the 3 out<br>caused strong disagreement from certain people during that discussion.<br><br>I tried to condensate my line of thought below, but it yielded a long<br>text anyway. To encourage your reading, below is a link to the result<br>at which I arrived after brainstorming. It establishes similarities<br>with current tags and associating a subjective level of preference to<br>each. This level was called "trafficability" during the other debate,<br>but since then this name may be inadequate (it was used in a tag<br>proposal).<br><br><a href="http://i.imgur.com/HUoE1iD.png">http://i.imgur.com/HUoE1iD.png</a><br><br>In the beginning, I was almost convinced that the "surface" tag would<br>be sufficient, but as other opinions came in, I was convinced that<br>some of its values are too imprecise. "surface=unpaved", for instance,<br>may refer to roads in excellent condition (specially if they'd be<br>better described as "surface=compacted"), but also to roads likely in<br>poor state (such as in "surface=dirt").<br><br>The Australian community seems to be recommending the use of<br>"tracktype" for any road type besides highway=track which is what it<br>was originally intended for, particularly within the German community.<br>But then, many people use the "smoothness" tag for very similar<br>reasons. It's easy to establish some rough correspondence between the<br>two tags by reading the description of their values. It's easy to<br>notice that smoothness provides more granularity at the "good" end of<br>the spectrum (3 values representing the best conditions roughly<br>correspond to a single value of tracktype) whereas tracktype has<br>better precision at the other end (all of its other values correspond<br>to a single value of smoothness).<br><br>At the same time, the Australian community was trying to introduce new<br>values for "tracktype" that correspond to other values of smoothness<br>at the "bad" end of the spectrum. If these would not be accepted, they<br>would pursue a new tag, "4wd_only=yes/no", that would correspond to<br>those values and would be used for special rendering. Nobody seemed to<br>be thinking of various transport modes, but some existing tags seemed<br>to be doing this: mtb:scale for bikes, sac_scale for pedestrians,<br>wheelchair for disabled people.<br><br>So I thought: "if there was a single tag to represent all of this,<br>would I be able to associate a level of preference to its values, with<br>little doubt?" In other words, would the new classification system<br>leave less, if any, doubts at all? Would it be sufficiently<br>descriptive? It would in my experience, which includes: driving,<br>cycling, walking and public transport in Brazil; driving, walking and<br>public transport in North America; walking and public transport in<br>Australia/NZ; cycling, walking and public transport in various places<br>in Europe (England, France, Germany, Netherlands, Austria, Spain). I<br>tested myself by associating such values comparatively, after having<br>assigned each of the other tags a "class", producing the result I<br>provided in the beginning.<br><br>The question that I asked myself was: if I had to travel from A to B<br>and there were two choices, a 100km-long perfectly flat asphalt road,<br>and a shortcut with [surface characteristics here], how many km could<br>this shortcut have at maximum to still look like a better choice?<br><br>This measure would essentially mean a level of preference and directly<br>translate into a coefficient multiplied to velocity in OSRM and other<br>routers. Its inverse (1/value) would represent the level of effort.<br><br>The obvious problem with this result: these values are my own opinion.<br>For a public routing app (such as OSRM), one would have to sample more<br>opinions, from people of different nations. But this is easier when<br>you have a single tag than with various tag combinations. A single tag<br>is also easier to teach and to map (which would encourage more people<br>to describe the surface). And it solves well the rendering issues. It<br>seems like a win for all involved sides: app developers, mappers, and<br>users.<br><br>Another little problem: only for class "5-grade2-pebblestone", I've<br>forced the value up for thin-wheeled vehicles (bikes and wheelchair).<br>The change was less than 10%, but still significant. I did this<br>because I believed it would make more sense to have the preference<br>curves asymptotically decrease for all vehicle types from one class to<br>the next. (This actually suggests that thin-wheeled vehicles might<br>require some slightly different classification system.)<br><br>Of course I am open to suggestions on how these observations can be<br>synthesized into a simpler tagging system.<br><br>On Wed, Mar 5, 2014 at 5:17 AM, Emil Tin <ZF0F@tmf.kk.dk> wrote:<br><br>DO you mean a new osm tag? Doesn't the existing tags you mention cover<br>surface quality?<br><br>Med venlig hilsen<br><br>Emil Tin<br>IT- og Processpecialist<br>Trafik<br>_______________________________<br>KØBENHAVNS KOMMUNE<br>Teknik- og Miljøforvaltningen<br>Byens Anvendelse<br><br>Njalsgade 13 Vær. 118<br>Postboks 380<br>2300 København S<br><br>Direkte 2369 5986<br>Mobil 2369 5986<br>Email zf0f@tmf.kk.dk<br>EAN 5798009493149<br>-----Oprindelig meddelelse-----<br>Fra: Fernando Trebien [mailto:fernando.trebien@gmail.com]<br>Sendt: 28. februar 2014 17:35<br>Til: Emil Tin<br>Cc: osrm-talk<br>Emne: Re: [OSRM-talk] Beginner question: default car profile and<br>tracktype/smoothness/surface<br><br>Thank you Emil and Hans. I didn't know about the biking profile. Even though<br>I'm a cyclist as well, I've been using the website mostly for car routing,<br>and that's what OSRM is most known for here in Brazil.<br><br>A while ago, I participated in a debate about making OSM-Carto use a<br>different visual style to display roads in "worse than usually expected"<br>state. As the debate developed, I made up a surface classification system<br>that captures similarities among tags that represent "transit effort"<br>(tracktype, smoothness, mtb:scale, sac_scale, wheelchair, 4wd_only, and<br>surface) for various modes of transportation. I wonder if you'd be<br>interested in something along this line, then I would go ahead and propose<br>an official tag for it.<br><br>On Fri, Feb 28, 2014 at 5:26 AM, Emil Tin <ZF0F@tmf.kk.dk> wrote:<br><br><br><br>Surface is already taken into account for bicycles in the OSRM main repo:<br><br>https://github.com/DennisOSRM/Project-OSRM/blob/master/profiles/bicycl<br>e.lua<br><br>However, instead of multiplying, I found it more realistic to simply use the<br>surface speed, instead of multiplying:<br><br>surface_speeds = {<br> ["asphalt"] = default_speed,<br> ["cobblestone:flattened"] = 10,<br> ["paving_stones"] = 10,<br> ["compacted"] = 10,<br> ["cobblestone"] = 6,<br> ["unpaved"] = 6,<br> ["fine_gravel"] = 6,<br> ["gravel"] = 6,<br> ["fine_gravel"] = 6,<br> ["pebbelstone"] = 6,<br> ["ground"] = 6,<br> ["dirt"] = 6,<br> ["earth"] = 6,<br> ["grass"] = 6,<br> ["mud"] = 3,<br> ["sand"] = 3<br>}<br><br><br> -- surfaces<br> if surface then<br> surface_speed = surface_speeds[surface]<br> if surface_speed then<br> if way.speed > 0 then<br> way.speed = surface_speed<br> end<br> if way.backward_speed > 0 then<br> way.backward_speed = surface_speed<br> end<br> end<br> end<br><br>Both approaches might have merit.<br><br><br><br>Kind regards,<br><br>Emil Tin<br>IT- and Process Specialist<br>Traffic Design<br>________________________________<br>CITY OF COPENHAGEN<br>The Technical and Environmental Administration Traffic Department<br><br>Islands Brygge 37 Vær. 118<br>Postboks 450<br>2300 København S<br><br>Telefon +45 2369 5986<br>Email ZF0F@tmf.kk.dk<br>EAN 5798009493149<br><br><br>-----Oprindelig meddelelse-----<br>Fra: Hans Gregers Petersen [mailto:gregers@septima.dk]<br>Sendt: 28. februar 2014 09:16<br>Til: osrm-talk@openstreetmap.org<br>Emne: Re: [OSRM-talk] Beginner question: default car profile and<br>tracktype/smoothness/surface<br><br>Hi Fernando,<br><br>I've always wondered if there are any plans taking surface<br>type/quality into account in the default profiles. I live in a<br>developing country (Brazil) with poorly maintained roads and these<br>conditions make a big difference at the beginning and at the end of<br>many routes if ignored.<br><br><br>I do not know about the plans regarding the default profile, but I<br>successfully used a simple "factor approach" to surfaces when doing our<br>routing on bicycle paths here in Denmark.<br>For instance setting the following in the LUA profile:<br><br>-- How much does speed depreciate by surface surface_factors = {<br>["unpaved"] = 0.8, ["gravel"] = 0.8, ["cobblestone"] = 0.8, ["dirt"] =<br>0.8, ["earth"] = 0.8, ["sand"] = 0.8, ["cobblestone:flattened"] = 0.9,<br>["compacted"] = 0.9, ["fine_gravel"] = 0.9, ["wood"] = 0.9 }<br><br>and then later adjuste the speed accordingly:<br><br>-- Surface tag<br>local surfacetag = way.tags:Find("surface")<br><br>-- Surface factor<br>if surface_factors[surfacetag] then<br>way.speed = way.speed * surface_factors[surfacetag] way.backward_speed<br>= way.backward_speed * surface_factors[surfacetag] end<br><br><br><br>Best regards,<br><br>Greg<br><br><br><br>Hans Gregers Petersen<br>Partner, Senior Consultant<br>www.septima.dk<br><br>_______________________________________________<br>OSRM-talk mailing list<br>OSRM-talk@openstreetmap.org<br>https://lists.openstreetmap.org/listinfo/osrm-talk<br><br>_______________________________________________<br>OSRM-talk mailing list<br>OSRM-talk@openstreetmap.org<br>https://lists.openstreetmap.org/listinfo/osrm-talk<br><br><br><br><br>--<br>Fernando Trebien<br>+55 (51) 9962-5409<br><br>"The speed of computer chips doubles every 18 months." (Moore's law)<br>"The speed of software halves every 18 months." (Gates' law)<br><br>_______________________________________________<br>OSRM-talk mailing list<br>OSRM-talk@openstreetmap.org<br>https://lists.openstreetmap.org/listinfo/osrm-talk<br><br><br><br><br>--<br>Fernando Trebien<br>+55 (51) 9962-5409<br><br>"The speed of computer chips doubles every 18 months." (Moore's law)<br>"The speed of software halves every 18 months." (Gates' law)<br><br>_______________________________________________<br>OSRM-talk mailing list<br>OSRM-talk@openstreetmap.org<br>https://lists.openstreetmap.org/listinfo/osrm-talk<br><br><br><br>_______________________________________________<br>OSRM-talk mailing list<br>OSRM-talk@openstreetmap.org<br>https://lists.openstreetmap.org/listinfo/osrm-talk<br><br></blockquote><br><br><br>-- <br>Fernando Trebien<br>+55 (51) 9962-5409<br><br>"The speed of computer chips doubles every 18 months." (Moore's law)<br>"The speed of software halves every 18 months." (Gates' law)<br></blockquote></div><br></body></html>