Hm I don't know of a place to go to obtain this information. Anyway, these rules would apply a safe speed limit regardless of the value of highway=*, such that tracktype=grade2 would mean the same when on highway=track and on highway=service and on highway=tertiary and so on.
I'm following the descriptions in the wiki when thinking of those speed limits. I'm absolutely open to change the speeds. But I don't think we can easily implement different interpretations of the tags on a per-country basis. On Mon, Mar 17, 2014 at 12:49 PM, Michal Palenik <[email protected]> wrote: > hi, please beware of osm dialects... > > at least in slovakia (and probably czech republic) highway=track is > considered to have motor_vehicle=private (or motor_vehicle=no) implicit tag. > > which opens the question of country/region wide default values for eg > maxspeed, ... > > michal > On Sun, Mar 16, 2014 at 09:13:57PM -0300, Fernando Trebien wrote: >> I investigated on this idea a bit further. I tried to arrive at >> numbers that when multiplied would make sense to me, but in the end >> your suggestion of speed limits for each tag made more sense. So, >> instead I would now agree with taking the minimum of the following >> speeds: default, max, tracktype limit, smoothness limit, and other >> things. And I have a new suggestion: we can try to guess tracktype and >> smoothness from surface, but only do so when these tags are missing. >> >> I've come to this conclusion after learning what tracktype means >> exactly: >> https://lists.openstreetmap.org/pipermail/tagging/2014-March/016904.html >> >> I've also asked the opinion of the community on this idea: >> https://lists.openstreetmap.org/pipermail/tagging/2014-March/016935.html >> >> I'd like to hear your opinion about adding the following code to >> https://github.com/DennisOSRM/Project-OSRM/blob/master/profiles/car.lua: >> >> >> 1. Just after the definition of speed_profile (line 34): >> >> ----- >> tracktype_profile = { >> ["grade1"] = math.huge, >> ["grade2"] = 45, >> ["grade3"] = 30, >> ["grade4"] = 20, >> ["grade5"] = 15, >> ["grade6"] = 9, >> ["grade7"] = 6, >> ["grade8"] = 3 >> } >> >> surface_tracktype_profile = { >> ["asphalt"] = tracktype_profile["grade1"], >> ["concrete"] = tracktype_profile["grade1"], >> ["tartan"] = tracktype_profile["grade1"], >> ["paved"] = tracktype_profile["grade1"], >> ["paving_stones"] = tracktype_profile["grade1"], >> ["concrete:plates"] = tracktype_profile["grade1"], >> ["metal"] = tracktype_profile["grade1"], >> ["compacted"] = tracktype_profile["grade1"], >> ["sett"] = tracktype_profile["grade1"], >> ["concrete:lanes"] = tracktype_profile["grade1"], >> ["bricks"] = tracktype_profile["grade1"], >> ["cement"] = tracktype_profile["grade1"], >> ["cobblestone"] = tracktype_profile["grade1"], >> ["wood"] = tracktype_profile["grade1"], >> ["stone"] = tracktype_profile["grade1"], >> ["rocky"] = tracktype_profile["grade1"], >> ["gravel"] = tracktype_profile["grade2"], >> ["fine_gravel"] = tracktype_profile["grade2"], >> ["grass_paver"] = tracktype_profile["grade2"], >> ["unpaved"] = tracktype_profile["grade3"], >> ["ground"] = tracktype_profile["grade3"], >> ["dirt"] = tracktype_profile["grade3"], >> ["grass"] = tracktype_profile["grade3"], >> ["pebblestone"] = tracktype_profile["grade3"], >> ["clay"] = tracktype_profile["grade4"], >> ["sand"] = tracktype_profile["grade5"], >> ["earth"] = tracktype_profile["grade5"], >> ["mud"] = tracktype_profile["grade5"] >> } >> >> smoothness_profile = { >> ["excellent"] = math.huge, >> ["thin_rollers"] = math.huge, >> ["good"] = 60, >> ["thin_wheels"] = 60, >> ["intermediate"] = 45, >> ["wheels"] = 45, >> ["bad"] = 30, >> ["robust_wheels"] = 30, >> ["very_bad"] = 15, >> ["high_clearance"] = 15, >> ["horrible"] = 3, >> ["off_road_wheels"] = 3 >> } >> >> surface_smoothness_profile = { >> ["asphalt"] = smoothness_profile["excellent"], >> ["concrete"] = smoothness_profile["excellent"], >> ["tartan"] = smoothness_profile["excellent"], >> ["paved"] = smoothness_profile["good"], >> ["paving_stones"] = smoothness_profile["good"], >> ["concrete:plates"] = smoothness_profile["good"], >> ["metal"] = smoothness_profile["good"], >> ["compacted"] = smoothness_profile["intermediate"], >> ["sett"] = smoothness_profile["intermediate"], >> ["concrete:lanes"] = smoothness_profile["intermediate"], >> ["bricks"] = smoothness_profile["intermediate"], >> ["cement"] = smoothness_profile["intermediate"], >> ["grass_paver"] = smoothness_profile["intermediate"], >> ["cobblestone"] = smoothness_profile["bad"], >> ["wood"] = smoothness_profile["bad"], >> ["stone"] = smoothness_profile["bad"], >> ["rocky"] = smoothness_profile["bad"], >> ["gravel"] = smoothness_profile["bad"], >> ["fine_gravel"] = smoothness_profile["bad"], >> ["unpaved"] = smoothness_profile["bad"], >> ["ground"] = smoothness_profile["bad"], >> ["dirt"] = smoothness_profile["bad"], >> ["grass"] = smoothness_profile["bad"], >> ["pebblestone"] = smoothness_profile["bad"], >> ["clay"] = smoothness_profile["bad"], >> ["sand"] = smoothness_profile["bad"], >> ["earth"] = smoothness_profile["bad"], >> ["mud"] = smoothness_profile["very_bad"] >> } >> ----- >> >> >> 2. At the beginning of way_function(), just after checking for access >> (line 119): >> >> >> ----- >> -- we dont route over extremely difficult surfaces >> local surface = way.tags:Find("surface") >> local tracktype = way.tags:Find("tracktype") >> local smoothness = way.tags:Find("smoothness") >> >> -- accept only widely used tracktype values (typos result in inaccessible >> ways) >> if tracktype ~= "" then >> if tracktype_profile[tracktype] == nil then >> return >> end >> end >> >> -- accept only widely used smoothness values (typos result in inaccessible >> ways) >> if smoothness ~= "" then >> if smoothness_profile[tracktype] == nil then >> return >> end >> end >> ----- >> >> >> 3. Just before handling forward/backward maxpeeds (line 206): >> >> >> ----- >> -- Set the avg speed on ways with difficult surfaces >> if tracktype ~= "" then >> way.speed = math.min(way.speed, tracktype_profile[tracktype]) >> else >> if surface ~= "" then >> if surface_tracktype_profile[surface] ~= nil then >> way.speed = math.min(way.speed, surface_tracktype_profile[surface]) >> end >> end >> end >> >> if smoothness ~= "" then >> way.speed = math.min(way.speed, smoothness_profile[smoothness]) >> else >> if surface ~= "" then >> if surface_smoothness_profile[surface] ~= nil then >> way.speed = math.min(way.speed, surface_smoothness_profile[surface]) >> end >> end >> end >> ----- >> >> On Mon, Mar 10, 2014 at 11:11 PM, Fernando Trebien >> <[email protected]> wrote: >> > "But if we do want to handle combinations" >> > >> > Shouldn't we handle them if the community thinks that surface is only >> > fully described after adding the 3 tags? Nowhere it is said "use one >> > or the other but not both". >> > >> > The very fact that people don't often combine them means to me that >> > one is simply a rough copy of the other and each is adopted by a >> > different community. >> > >> > "maybe use surface (the most used tag), multiplied by a factor if >> > tracktype or smoothness is set as well?" >> > >> > What if both are present? If we multiply by both factors, the final >> > result would be lower than expected. In that case, at least averaging >> > them would be better (if you're looking for a very simple method). >> > >> > "In essense, take minimium of: >> > - default speed >> > - max speed >> > - surface speed * tracktype or smoothness factor >> > - other things that lower the speed" >> > >> > Makes sense to me. >> > >> > On Mon, Mar 10, 2014 at 3:10 PM, Emil Tin <[email protected]> wrote: >> >> The tags are not used so often together (from >> >> http://taginfo.openstreetmap.org/keys/surface#combinations): >> >> >> >> Surface (8 077 811 occurences) combinations: >> >> 1 087 838 13.47% tracktype >> >> 175 011 2.17% smoothness >> >> >> >> Tracktype combinations: >> >> 46 144 1.44% smoothness >> >> >> >> 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? >> >> >> >> In essense, take minimium of: >> >> - default speed >> >> - max speed >> >> - surface speed * tracktype or smoothness factor >> >> - other things that lower the speed >> >> >> >> >> >> >> >> On 10 Mar 2014, at 17:30 , Fernando Trebien <[email protected]> >> >> wrote: >> >> >> >> For each tag+value combination, we could assign: >> >> - a preference value >> >> - a weight value or a priority value >> >> >> >> When using weights, the final preference value would be a weighed >> >> average of the preference values corresponding to each tag. >> >> >> >> When using priorities, the final preference would be that of the >> >> highest priority tag+value combination. >> >> >> >> Contradictions are an issue, for example: >> >> - tracktype=grade1 + smoothness=very_horrible: is it good or is it bad? >> >> - tracktype=grade5 + surface=asphalt: is it paved or not? >> >> - smoothness=impassable + surface=concrete: maybe the concrete path >> >> was very badly built, or maybe we just had an earthquake >> >> >> >> Weighting would "blur" the contradiction, opting for an average >> >> preference of the conflicting values. The greater the contradiction, >> >> the greater the risk of poor routing decisions. >> >> >> >> A pessimist approach (probably "safer" for the user) is to select the >> >> lowest preference value assigned for tag+value combinations present in >> >> a way. But then, we lose the ability to use one tag as a refinement >> >> for the other (for example: tracktype=grade2/3/4/5 when >> >> smoothness=bad). >> >> >> >> A remedy would be a more complex approach which practically encodes >> >> the class system that I proposed: >> >> - given 3 tag+value combinations, pick the combination with lowest >> >> preference value (let's call this tag A) >> >> - for the remaining 2 combinations, select those that are considered >> >> similar to A (according to some equivalence table) and discard the >> >> others >> >> - if there are 2 left, also pick the one with lowest preference value (tag >> >> B) >> >> - possibly pick tag C if it's similar to both A and B >> >> >> >> The result would be from 1 to 3 tags (A,B,C) from which you'd choose >> >> the one with highest priority. That's the most accurate preference >> >> value within pessimist choices. >> >> >> >> A single classification system would eliminate these problems, and it >> >> can be introduced in the community (not necessarily in OSRM) >> >> simultaneously with a more temporary solution in OSRM using multiple >> >> tags and some sort of contradiction handling. I just wouldn't go ahead >> >> and propose it if there's no interest in adopting such a thing in the >> >> long term. >> >> >> >> On Mon, Mar 10, 2014 at 11:19 AM, Emil Tin <[email protected]> wrote: >> >> >> >> >> >> 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 <[email protected]> >> >> 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 <[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 >> >> >> >> >> >> >> >> _______________________________________________ >> >> 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) >> >> >> >> -- >> 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 > > -- > michal palenik > www.freemap.sk > www.oma.sk -- 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
