[mkgmap-dev] avg speed on roads

Fri Apr 23 17:31:42 BST 2010

I think there are currently some tools in mkgmap to get a better time 
estimation. I have the lines below in my points style file, which 
certainly improve the arrival time estimation:
highway=traffic_signals { add mkgmap:road-speed = '-2'; add 
mkgmap:road-speed-min = '1' }
highway=crossing { add mkgmap:road-speed = '-1'; add 
mkgmap:road-speed-min = '1' }
highway=stop { add mkgmap:road-speed = '-2'; add mkgmap:road-speed-min = 
'1' }
traffic_calming=* { add mkgmap:road-speed = '-2'; add 
mkgmap:road-speed-min = '1' }
barrier=toll_booth { add mkgmap:road-speed = '-2'; add 
mkgmap:road-speed-min = '1' }

 --ignore-maxspeeds also helps to get better time.

WanMil escribió:
>>    Measuring the avg. speed for sections of 10-20km on primarys is
>>    something low like 35km/h on some parts and something like 55km/h on
>>    fast parts. The max speed on these sections is mostly 80km/h but in
>>    the end nobody gets that fast.
>>
>> In Mass the speed limits are on most ways from the MassGIS import.  I
>> believe mkgmap can look at speeds and turn that into a speed bin for
>> garmin, separately from primary/secondary.
>>
>> There has been discussion of this before, but AFAIK no real resolution.
>> It seems that almost everyone agrees that having a tag that describes
>> the typical speeds would be sensible.  The problem is that typical
>> speeds are time dependent, and that's too complicated.
>>
>> I'm not sure if there are formal tagging proposals.  I would go with
>>
>> typical_speeed=
>>
>> to represent the travel speeds that are normally obtainable during
>> day/evening *outside* of "rush hour".  This is a single number, useful
>> for a lot of circumstances.
>>     
>
> The OSM wiki (http://wiki.openstreetmap.org/wiki/Maxspeed) points to 
> maxspeed:practical but this is a proposal only with lots of opponents.
>
>   
>> Then, having a more complicated tag that gives a transform from type of
>> day and time of day to speed could be done - but it's a slippery slope
>> and pretty soon you want real-time data.  But garmin maps don't support
>> time-dependent data.
>>
>>
>> Another question is why you want accurate time estimates.  If you want
>> the user to know when they'll arrive, you need an accurate estimate.
>> But a weaker, still useful condition, is that calculated routes be
>> fairly close to the best route.  Hence my notion of ignoring rush hour
>> in typical_speed - everything gets jammed up becuase everyone else is
>> optimizing.  And, humans know that they have to apply a rush hour
>> penalty.
>>     
>
> I would also like to have accurate time estimates :-) So I think it's 
> good to think about their improvement. Anyhow they will never be 100% 
> accurate unless you have an algorithm that calculates the future (which 
> I would use to calculate the lottery numbers).
>
>   
>> This discussion really belongs on tagging@, becuase the mkgmap part is
>> easy once there is agreement on a typical_speed tag and the db is
>> populated.
>>
>>     
>
> I aggree. Generally there's nothing to do for mkgmap at the moment. The 
> maxspeed tag is used to speed-classify the roads.
> Only two things for the future:
> * Support of the increasing DE:urban, DE:motorway etc. maxspeed values.
> * Get more knowledge of the Garmin map format to be able to support 
> other speed information.
>
> WanMil
> _______________________________________________
> mkgmap-dev mailing list
> mkgmap-dev at lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>
>