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