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
> [email protected]
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>
>
_______________________________________________
mkgmap-dev mailing list
[email protected]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
