[mkgmap-dev] avg speed on roads

Fri Apr 23 14:24:46 BST 2010


On 23.04.2010 15:04, Greg Troxel wrote:
>    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.
>
> 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.
>
>    
Garmin maps do, at least NT type maps do. However we don't know how to 
encode it.

at least NT type maps support time dependant restrictions, they also 
support maxspeed, but we don't know how to encode it. There are plenty 
other things, like junction view, lane assist, and so on, which we don't 
know how to encode (or maybe only possible in NT format).
> 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.
>
>
> 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.
>    
>
>
> _______________________________________________
> mkgmap-dev mailing list
> mkgmap-dev at lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.mkgmap.org.uk/pipermail/mkgmap-dev/attachments/20100423/0e3f84c6/attachment.html