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.