[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
- Previous message: [mkgmap-dev] avg speed on roads
- Next message: [mkgmap-dev] avg speed on roads
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the mkgmap-dev mailing list