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@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Reply via email to