logo separator

[mkgmap-dev] Possible maxspeed patch

From MarkS OSM at redcake.co.uk on Fri Aug 28 10:13:04 BST 2009

Greg Troxel wrote:

> 
> This all makes sense, but it seems that the real problem needs to be
> solved at the database semantics level.  Patching it up in mkgmap
> certainly is useful, but other routing engines should have a consistent
> view.  I think we're really talking about "given a .osm file and a
> particular way, how do you decide what speed you should assume one can
> drive on that way". 
> 

I agree with the principle. However, I guess a limitation on mkgmap 
routing is that mkgmap doesn't do the routing it supplies that data to 
garmin who do the routing. We can affect the data going in but not the 
routing algorithms. I was testing yesterday and road speed doesn't seem 
to make much difference to mapsource routes. Mapsource seems to follow 
the road class (set in preferences) and only allows speed to affect the 
route if it makes a major difference.

However, this patch doesn't really attempt to provide a calculation of 
the correct speed. All it tries to do is make it more flexible to choose 
what method mkgmap uses to set the road speed attribute. In its current 
form it provides four options (which compares with the two we have 
available at the moment). If this patch were added we could add extra 
methods in the future. For example last night I added an extra option 
for a new method to calculate the speed which took 90% of maxspeed, 
unless it was a single track road in which case it took 60%. I could 
easily try this alternative method by using "maxspeed=MarkS". I don't 
pretend this new method is any good and I don't see much point in 
showing this extra code off. But what this method did show was that 
having "maxpseed=xxxx" allows extra methods to be added easily. If 
maxspeed patch is added then a future job is to come up with better 
speed algorithms.




More information about the mkgmap-dev mailing list