Ich habe mir eben nochmal das die Textform des Trekking Profils angeschaut. Dort taucht "smoothness" leider gar nicht in der Definition der Costfunction auf
Es wird eher nach dem "highway" und "tracktype" bewertet. Aber komplett verstehe ich den Syntax noch nicht. Aber immerhin kann man über das Profil einigermassen abschätzen, warum die Cost hier kleiner ist.
In dem Beispiel von mir, könnte es an folgendem Code im Profil liegen:
Rich (BBCode):
assign badoneway =
if reversedirection=yes then
if oneway:bicycle=yes then true
else if oneway= then junction=roundabout
else oneway=yes|true|1
else oneway=-1
assign onewaypenalty =
if ( badoneway ) then
(
if ( cycleway=opposite|opposite_lane|opposite_track ) then 0
else if ( oneway:bicycle=no ) then 0
else if ( highway=primary|primary_link ) then 50
else if ( highway=secondary|secondary_link ) then 30
else if ( highway=tertiary|tertiary_link ) then 20
else 4.0
)
else 0.0
Evtl wird "badoneway" auf "true" gesetzt, weil "else if oneway= then junction=roundabout" und dann bekommt es einen "onewaypenalty" von "4.0" weil es ein "highway=unclassified" ist?
Das ist mir aber relativ viel Spekulation
edit:
Okay ich konnte mich etwas einlesen und verstehe jetzt den Grund. Zum Debuggen kann die "costfunction" im Profil angepasst werden und in der Datentabelle sieht man die Aufschlüsselung der Cost. Diese habe ich zuvor falsch interprätiert. Zur Vollständigkeit hier der Grund für das obige Problem:
Wie erwähnt, wird die smoothness im Standard-Trekkinprofil nicht berücksichtigt. Es liegt auch nicht an der "reversedirection". Es liegt ganz einfach an dem Höhenprofil. Auf diesem Abschnitt hat die OSM Karte wohl eine relativ starken Höhenunterschied und mit den Einstellungen "downhillcost=60" und "uphillcost=0", bekommt dieses Teilstück in eine Richtung eine hohe Cost (Spalte "elev$" in der Datentabelle) und in die andere nicht. Simpler als gedacht. Aber immerhin weis ich nun, dass die smoothness nicht verwendet wird und kann diese in ein eigenes Profil einbauen
