OSRM focuses on tags that are already in widespread use. From tag info: surface 8077811 tracktype 3212051 smoothness 208379
Even if a new tagging scheme is agreed on (by whom?) it would probably take quite a while before it's in common use worldwide. So for now I think the question is how OSRM should handle these 3 tags. On 10 Mar 2014, at 14:41 , Fernando Trebien <fernando.treb...@gmail.com> wrote: > 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 <z...@tmf.kk.dk> 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 z...@tmf.kk.dk >> EAN 5798009493149 >> -----Oprindelig meddelelse----- >> Fra: Fernando Trebien [mailto:fernando.treb...@gmail.com] >> 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 <z...@tmf.kk.dk> 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 z...@tmf.kk.dk >>> EAN 5798009493149 >>> >>> >>> -----Oprindelig meddelelse----- >>> Fra: Hans Gregers Petersen [mailto:greg...@septima.dk] >>> Sendt: 28. februar 2014 09:16 >>> Til: osrm-talk@openstreetmap.org >>> 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 >>> OSRM-talk@openstreetmap.org >>> https://lists.openstreetmap.org/listinfo/osrm-talk >>> >>> _______________________________________________ >>> OSRM-talk mailing list >>> OSRM-talk@openstreetmap.org >>> 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 >> OSRM-talk@openstreetmap.org >> 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 > OSRM-talk@openstreetmap.org > https://lists.openstreetmap.org/listinfo/osrm-talk
_______________________________________________ OSRM-talk mailing list OSRM-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/osrm-talk
