[OSRM-talk] Beginner question: default car profile and tracktype/smoothness/surface
Fernando Trebien
fernando.trebien at gmail.com
Mon Mar 10 16:30:04 UTC 2014
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 <emil at 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.trebien at 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 <ZF0F at 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 zf0f at tmf.kk.dk
> EAN 5798009493149
> -----Oprindelig meddelelse-----
> Fra: Fernando Trebien [mailto:fernando.trebien at 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 <ZF0F at 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 ZF0F at tmf.kk.dk
> EAN 5798009493149
>
>
> -----Oprindelig meddelelse-----
> Fra: Hans Gregers Petersen [mailto:gregers at septima.dk]
> Sendt: 28. februar 2014 09:16
> Til: osrm-talk at 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 at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/osrm-talk
>
> _______________________________________________
> OSRM-talk mailing list
> OSRM-talk at 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 at 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 at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/osrm-talk
>
>
>
> _______________________________________________
> OSRM-talk mailing list
> OSRM-talk at 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)
More information about the OSRM-talk
mailing list