[mkgmap-dev] RFC: Consider heightmeters for routing

Mon Apr 6 23:41:15 BST 2009

Thank you for your comments, it corrects some of my thoughts.

> And where do you intend to get your height information from????
> Outside of mountaineous regions SRTM is fit for use, in the mountains 
> where it matters it is useless. Even Jonathan de Ferrantis 1" files 
> are not really good (often 20-50m off).
I haven't digged that deep at the moment. I thought, SRTM would be a 
good start. It haven't known, that it is unusable in the mountain 
regions. :-(
>
> Rather penalise by using the inclination key.
Good idea, could be considered.
> I like the idea, but I don't think it will work on Garmin handhelds.
>
Exactly therefore I would try it by lengthen the roads. This is what 
garmin handhelds do. Calculate a route by its lengths.
> If you really want to lengthen the roads, do you think this is 
> possible CPU wise?
> 1. You would have to attach to every polyline highway=* a height 
> profile - which will take a very long time,
> 2. you will have to lengthen it (how do you want to do that? Insert 
> curves into straight lines? - that will not look good. You can't make 
> the curves to abrubt, otherwise the PNA thinks it has to turn (imagine 
> going a straight line and the routing popping up --> turn left...
I would not modify the ways, but simply change the routing tables. As 
far as i understand the img format, there is the NOD section, which 
contains the lines to draw on screen. This data should not be changed. 
And there is a NET section, which contains the routing data. This data 
contains is a length for each segment between two crossings. I would 
change this length by a factor depending on the height and incline data.

>
> Better put your efforts into decrypting the Garmin DEM so that we can 
> rebuilt it. Then after the route is calculated just have a look at the 
> profile and correct it at places where there is too much incline (You 
> could instead export it to another program and add height information 
> to it but inside Mapsource would be more comfortable). However having 
> other systems (I think there is even one webpage based on OSM which 
> does exactly what you want)  that do work, why not use them and omit 
> to try to implement it onto your PNA?
For me the DEM is useless, as my unit cant display it. But maybe i will 
buy a new one, if mkgmap learns DEM...
>
> Also steepness plays a part. A steady rise will be nicer for going up 
> than 100m at 30% and then 500m flat - while another street 600m long 
> with steady rise would be penalised the same (but much easier to cycle 
> up). I agree that you don't need to know whether it goes up or down, 
> but you need the incline.
> Now taking that into account will make calculating the penalty even 
> more CPU heavy (not only the difference, but also correlating the 
> incline). Is it better to push up 100m then go level or to go up 130m 
> at easy incline and then 30m back down?

Yeah, true.
I see, it needs more thinking about before starting this.