Oh - actually there is one thing that could be done - but I'm not sure
if it is possible and even if might lead to big fuckups..
That is - display the road as is, but manipulate the counters so it
appears shorter on calculations. Maybe this is possible. I mean there
must be a way to make it longer - to account for altitude - so is it
possible to shorten the road but display it longer?
That would of course give you wrong kilometers and distances on every
possible setting...
On 03.07.2014 20:32, Felix Hartmann wrote:
You are missing a big big point here!
The higher you put the speed, the bigger the time penalties for sharp
turns.
So the only thing reasonable to do is ramp up the road_class, and keep
or back down the road-speed..
But best give it some tries yourself by creating a sample map where
you increase speed for some curvy roads based on name filters. You
will likely notice that the result is rather the opposite. Especially
if there are crossings...
Felix
On 03.07.2014 19:49, Manfred Brenneisen wrote:
Hi all,
Gesendet: Mittwoch, 02. Juli 2014 um 08:46 Uhr
Von: "Felix Hartmann" <[email protected]>
An: [email protected]
Betreff: Re: [mkgmap-dev] Curvy routing support: new function?
Well I have thought about this too - also new Basecamp has a curvy
roads
preference - but what should mkgmap do about it?
You can calculate if a road is curvy or not, but what then? The only
thing you can do until mkgmap knows NT format maps which I think has a
special "tag" for this, is to increase the road-class.
Increasing the road-speed would be against your intentions - as the
higher the road-speed - the more garmin algo will punish you for curvy
roads...
So until we know how Garmin maps tell Basecamp/the GPS Unit to
exclude a
road from curvyness punishment - the only thing you can do is to
increase the road-class...
I'm 100% sure the prefer curvy roads switch, works like avoidance -
looking for the curvy road indicator inside the map. There is
absolutely
no change in routing in Basecamp if I set it or not with non NT maps...
I devised myself a day to think about it. To be not too enthusiastic
or conservative, as the future will be NT maps as you state
correctly. Finally, I think:
mkgmap could translate the physical shape of a road into different
categories, e.g. by setting mkgmap:road-speed parameters. This is
more analog than digital "curvy" or "not curvy" setting by just
setting single bits (which are not widespread yet, NT only).
One might want to differentiate between this way:
http://www.openstreetmap.org/way/186500650 and that way:
http://www.openstreetmap.org/way/106597772
Which one is faster? Would you like to add the (highly unwanted!)
maxspeed:practical tag to OSM data?
Car map designers might want to lower speeds for curvy roads,
motorcycle map makers would go the other way (knowing that the
calculated travel time is incorrect)
Adding style rules like
highway=primary & curviness() > 50 {add mkgmap:road-speed-max=5}
would not influence the map, only curvy roads are affected.
Nobody is forced to use the new function (knowing that it slows down
map generation if used). But as it is not a really big thing you
might give it a try. I'll test, and report when it works correctly
(for me :-))
Cheers
Manfred
On 01.07.2014 22:02, Manfred Brenneisen wrote:
Hi all,
Garmin offers "curvy roads" preferences for their zümo 390 and 590
devices.
--
keep on biking and discovering new trails
Felix
openmtbmap.org & www.velomap.org
_______________________________________________
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
_______________________________________________
mkgmap-dev mailing list
[email protected]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
