My personal point of view is: they mostly do, but in a needlessly complicated way. I think you'd be surprised at how far the discussion went (over 150 messages, many of which were quite long) to reach a simple agreement: deciding which tags/values to use in order to decide which roads are possibly in poor state, as to deserve special rendering. In this agreement, we settled on 3 tags (tracktype, smoothness and surface) to make such a decision. So it is clear that the community views the 3 tags as "necessary" for reasonable routing choices when reading the map visually. Trying to take any of the 3 out caused strong disagreement from certain people during that discussion.
I tried to condensate my line of thought below, but it yielded a long text anyway. To encourage your reading, below is a link to the result at which I arrived after brainstorming. It establishes similarities with current tags and associating a subjective level of preference to each. This level was called "trafficability" during the other debate, but since then this name may be inadequate (it was used in a tag proposal). http://i.imgur.com/HUoE1iD.png In the beginning, I was almost convinced that the "surface" tag would be sufficient, but as other opinions came in, I was convinced that some of its values are too imprecise. "surface=unpaved", for instance, may refer to roads in excellent condition (specially if they'd be better described as "surface=compacted"), but also to roads likely in poor state (such as in "surface=dirt"). The Australian community seems to be recommending the use of "tracktype" for any road type besides highway=track which is what it was originally intended for, particularly within the German community. But then, many people use the "smoothness" tag for very similar reasons. It's easy to establish some rough correspondence between the two tags by reading the description of their values. It's easy to notice that smoothness provides more granularity at the "good" end of the spectrum (3 values representing the best conditions roughly correspond to a single value of tracktype) whereas tracktype has better precision at the other end (all of its other values correspond to a single value of smoothness). At the same time, the Australian community was trying to introduce new values for "tracktype" that correspond to other values of smoothness at the "bad" end of the spectrum. If these would not be accepted, they would pursue a new tag, "4wd_only=yes/no", that would correspond to those values and would be used for special rendering. Nobody seemed to be thinking of various transport modes, but some existing tags seemed to be doing this: mtb:scale for bikes, sac_scale for pedestrians, wheelchair for disabled people. So I thought: "if there was a single tag to represent all of this, would I be able to associate a level of preference to its values, with little doubt?" In other words, would the new classification system leave less, if any, doubts at all? Would it be sufficiently descriptive? It would in my experience, which includes: driving, cycling, walking and public transport in Brazil; driving, walking and public transport in North America; walking and public transport in Australia/NZ; cycling, walking and public transport in various places in Europe (England, France, Germany, Netherlands, Austria, Spain). I tested myself by associating such values comparatively, after having assigned each of the other tags a "class", producing the result I provided in the beginning. The question that I asked myself was: if I had to travel from A to B and there were two choices, a 100km-long perfectly flat asphalt road, and a shortcut with [surface characteristics here], how many km could this shortcut have at maximum to still look like a better choice? This measure would essentially mean a level of preference and directly translate into a coefficient multiplied to velocity in OSRM and other routers. Its inverse (1/value) would represent the level of effort. The obvious problem with this result: these values are my own opinion. For a public routing app (such as OSRM), one would have to sample more opinions, from people of different nations. But this is easier when you have a single tag than with various tag combinations. A single tag is also easier to teach and to map (which would encourage more people to describe the surface). And it solves well the rendering issues. It seems like a win for all involved sides: app developers, mappers, and users. Another little problem: only for class "5-grade2-pebblestone", I've forced the value up for thin-wheeled vehicles (bikes and wheelchair). The change was less than 10%, but still significant. I did this because I believed it would make more sense to have the preference curves asymptotically decrease for all vehicle types from one class to the next. (This actually suggests that thin-wheeled vehicles might require some slightly different classification system.) Of course I am open to suggestions on how these observations can be synthesized into a simpler tagging system. On Wed, Mar 5, 2014 at 5:17 AM, Emil Tin <[email protected]> wrote: > DO you mean a new osm tag? Doesn't the existing tags you mention cover > surface quality? > > Med venlig hilsen > > Emil Tin > IT- og Processpecialist > Trafik > _______________________________ > KØBENHAVNS KOMMUNE > Teknik- og Miljøforvaltningen > Byens Anvendelse > > Njalsgade 13 Vær. 118 > Postboks 380 > 2300 København S > > Direkte 2369 5986 > Mobil 2369 5986 > Email [email protected] > EAN 5798009493149 > -----Oprindelig meddelelse----- > Fra: Fernando Trebien [mailto:[email protected]] > Sendt: 28. februar 2014 17:35 > Til: Emil Tin > Cc: osrm-talk > Emne: Re: [OSRM-talk] Beginner question: default car profile and > tracktype/smoothness/surface > > Thank you Emil and Hans. I didn't know about the biking profile. Even though > I'm a cyclist as well, I've been using the website mostly for car routing, > and that's what OSRM is most known for here in Brazil. > > A while ago, I participated in a debate about making OSM-Carto use a > different visual style to display roads in "worse than usually expected" > state. As the debate developed, I made up a surface classification system > that captures similarities among tags that represent "transit effort" > (tracktype, smoothness, mtb:scale, sac_scale, wheelchair, 4wd_only, and > surface) for various modes of transportation. I wonder if you'd be interested > in something along this line, then I would go ahead and propose an official > tag for it. > > On Fri, Feb 28, 2014 at 5:26 AM, Emil Tin <[email protected]> wrote: >> >> >> Surface is already taken into account for bicycles in the OSRM main repo: >> >> https://github.com/DennisOSRM/Project-OSRM/blob/master/profiles/bicycl >> e.lua >> >> However, instead of multiplying, I found it more realistic to simply use the >> surface speed, instead of multiplying: >> >> surface_speeds = { >> ["asphalt"] = default_speed, >> ["cobblestone:flattened"] = 10, >> ["paving_stones"] = 10, >> ["compacted"] = 10, >> ["cobblestone"] = 6, >> ["unpaved"] = 6, >> ["fine_gravel"] = 6, >> ["gravel"] = 6, >> ["fine_gravel"] = 6, >> ["pebbelstone"] = 6, >> ["ground"] = 6, >> ["dirt"] = 6, >> ["earth"] = 6, >> ["grass"] = 6, >> ["mud"] = 3, >> ["sand"] = 3 >> } >> >> >> -- surfaces >> if surface then >> surface_speed = surface_speeds[surface] >> if surface_speed then >> if way.speed > 0 then >> way.speed = surface_speed >> end >> if way.backward_speed > 0 then >> way.backward_speed = surface_speed >> end >> end >> end >> >> Both approaches might have merit. >> >> >> >> Kind regards, >> >> Emil Tin >> IT- and Process Specialist >> Traffic Design >> ________________________________ >> CITY OF COPENHAGEN >> The Technical and Environmental Administration Traffic Department >> >> Islands Brygge 37 Vær. 118 >> Postboks 450 >> 2300 København S >> >> Telefon +45 2369 5986 >> Email [email protected] >> EAN 5798009493149 >> >> >> -----Oprindelig meddelelse----- >> Fra: Hans Gregers Petersen [mailto:[email protected]] >> Sendt: 28. februar 2014 09:16 >> Til: [email protected] >> Emne: Re: [OSRM-talk] Beginner question: default car profile and >> tracktype/smoothness/surface >> >> Hi Fernando, >> >>> I've always wondered if there are any plans taking surface >>> type/quality into account in the default profiles. I live in a >>> developing country (Brazil) with poorly maintained roads and these >>> conditions make a big difference at the beginning and at the end of >>> many routes if ignored. >> >> I do not know about the plans regarding the default profile, but I >> successfully used a simple "factor approach" to surfaces when doing our >> routing on bicycle paths here in Denmark. >> For instance setting the following in the LUA profile: >> >> -- How much does speed depreciate by surface surface_factors = { >> ["unpaved"] = 0.8, ["gravel"] = 0.8, ["cobblestone"] = 0.8, ["dirt"] = >> 0.8, ["earth"] = 0.8, ["sand"] = 0.8, ["cobblestone:flattened"] = 0.9, >> ["compacted"] = 0.9, ["fine_gravel"] = 0.9, ["wood"] = 0.9 } >> >> and then later adjuste the speed accordingly: >> >> -- Surface tag >> local surfacetag = way.tags:Find("surface") >> >> -- Surface factor >> if surface_factors[surfacetag] then >> way.speed = way.speed * surface_factors[surfacetag] way.backward_speed >> = way.backward_speed * surface_factors[surfacetag] end >> >> >> >> Best regards, >> >> Greg >> >> >> >> Hans Gregers Petersen >> Partner, Senior Consultant >> www.septima.dk >> >> _______________________________________________ >> OSRM-talk mailing list >> [email protected] >> https://lists.openstreetmap.org/listinfo/osrm-talk >> >> _______________________________________________ >> OSRM-talk mailing list >> [email protected] >> https://lists.openstreetmap.org/listinfo/osrm-talk > > > > -- > 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) > > _______________________________________________ > OSRM-talk mailing list > [email protected] > https://lists.openstreetmap.org/listinfo/osrm-talk -- 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) _______________________________________________ OSRM-talk mailing list [email protected] https://lists.openstreetmap.org/listinfo/osrm-talk
