logo separator

[mkgmap-dev] avg speed on roads

From WanMil wmgcnfg at web.de on Fri Apr 23 17:03:41 BST 2010

>
>    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



More information about the mkgmap-dev mailing list