[OSRM-talk] Beginner question: default car profile and tracktype/smoothness/surface
Fernando Trebien
fernando.trebien at gmail.com
Mon Mar 17 16:57:23 UTC 2014
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
<michal.palenik at freemap.sk> 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
>> <fernando.trebien at 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 <emil at 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.trebien at 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 <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)
>> >>
>> >>
>> >>
>> >> _______________________________________________
>> >> 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)
>>
>>
>>
>> --
>> 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
>
> --
> 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)
More information about the OSRM-talk
mailing list