[mkgmap-dev] RFC: Consider heightmeters for routing

Mon Apr 6 23:13:00 BST 2009

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).

Rather penalise by using the inclination key.
I like the idea, but I don't think it will work on Garmin handhelds.

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...

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?

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?

Johann Gail wrote:
>
>
> Mark Burton schrieb:
>> Hi Johann,
>>
>>  
>>> So my idea is, to virutally lengthen the roads by the height 
>>> distance. This is, if a road has 1km and goes straight then it gets 
>>> an entry of 1 km in the routing data.. If another road has a length 
>>> of 1km and a height difference of 10m, then it gets a length entry 
>>> of 1.1km. And a really hilly road with a length of 1km and a height 
>>> of 100m will get an entry of 2km.
>>> In other words, I would add a percentage of the height to the 
>>> lenght. This should made the etrex choose the flater roads.
>>>     
>>
>> What happens when you go downhill, does it make the roads shorter?
>>   
> No, it doesn't matter, which direction the road goes. It has an height 
> difference an gots therefore an penalty.
>
> See the following example:
>
> Start at height 500m
> Destination at height 520m
>
> Maybe there are four alternatives, how I can get to the destination
>
> 1. +20m
> 2. +100m, -80m
> 3. -80m, +100m
> 4. +30m, -15m, +5m
>
> All height differences get a positive penalty, no matter which 
> direction. So the route with the least 'up and down' gets the least 
> penalty and should be prefered. If I would consider the direction 
> (which is impossible at gmapsupp creation time) then the resulting 
> penalty would always sum up to the real height difference and there 
> will be no difference.
>
>> Personally, I like the hills when I am cycling so I don't think I would
>> use such a feature.
>>
>>   
> In general I agree with you. I like the hills too. For my recreation 
> cycling I choose the ways, which looks best to me at the moment, not 
> the ones which tells my etrex me to take. :-)
>
> But sometimes I do really long rides (>140km), and then I don't want 
> to waste my condition on some hilly routes, if I can reach the 
> destination on a flat alternative, maybe alongside a river.
>
> I expect, for the 'short range' routing there will be not much effect, 
> as there are to less alternatives to choose from. But on the 'long 
> range' routing it may be the difference between a route over hilly 
> region or alongside a river.
>
> As I have said in my first mail, this is only a idea, how it could be 
> work. I have not written a single line code for this, and as the 
> summer is comming, I think I will go more cycling than sitting in 
> front of my computer. :-)
>
> Greetings
> Johann
>
>
>
>
>
> _______________________________________________
> mkgmap-dev mailing list
> mkgmap-dev at lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>