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 > <fernando.treb...@gmail.com> 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 <e...@tin.dk> 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 <fernando.treb...@gmail.com> > >> 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 <e...@tin.dk> 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 <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 > >> > >> > >> > >> > >> -- > >> 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) > > > > -- > 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 -- michal palenik www.freemap.sk www.oma.sk _______________________________________________ OSRM-talk mailing list OSRM-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/osrm-talk
