Also es gibt da auch andere Einschränkungen, die zu solchen Problemen führen können:
- Sperrung der Straße für Räder (z.B. bestimmte Bundesstraßen)
- falscher Straßenbelag für Rennrad (nicht geteert)
- Einbahnstr.
- ...
Kann aber auch leicht sein, dass da eben früher ein Fehler im Datenmaterial war, der bei unserem Routing erst beim nächsten Planeten-Update behoben wird.
Ja, die Punkte sind verbunden, und zwar im OSM, als auch beim Routenplaner von Euch. Zumindest sieht es so aus. Deswegen bin auch verwundert.
Allerdings, wenn man bei OSM routed, dann ist alles i.O.
Wenn man bei Euch auf dem Routenplaner das gleiche tested, macht er den unten angegebenen Umweg.
Wir haben eine Kopie des gesamten OpenStreetMap-Planeten auf unserem Server. Der Stand der aktuellen Version ist ca. 1/2 Jahr alt. Möglicherweise war zu diesem Zeitpunkt noch ein Fehler im Kartenmaterial. Die Umwandlung des Planeten ist eine extrem zeitaufwändige Prozedur (ca. 10 Tage), daher wird das nicht so oft gemacht :-)
Stünde aber bald mal wieder auf der Agenda.
Hast du im OpenStreetMap-Editor geschaut, ob die Punkte wirklich verbunden sind?
http://www.gps-sport.net/routes/RoutingProblem001_170077
Obwohl es so aussieht als ob die Wege durchverbunden sind.... beim Strecke-Routen wird hier immer ein Umweg gemacht.
Was ist denn da los?
Ich wollte in Openstreetmap checken ob da ein Fehler in der Karte ist, kann aber keinen finden...
@admin: Die Bugfixes waren in den genannten Punkten zwar erfolgreich, aber leider gibt es einen neuen Bug. Wenn die Routenplanung mit dem Rennrad auf einem Track vom grade1 endet, hängt sich der Routenplaner auf.
Beispiel (hier mit der Einstellung "Radfahren" geplant):
29.05.2013 16:11:30 UTCgeändert am 31.05.2013 12:42:17 UTC
Update Routing-Engine
So, wir haben heute die neue Version des Routenplaners eingespielt mit folgenden Verbesserungen:
1) Rennrad-Routing (carpe_diem): das Tag "bicycle=no" wird nun auch für Schnellstraßen ausgelesen und beachtet (siehe Screenshot unten) - Du wirst damit nicht mehr über die B3 bei Dorteweil geleitet
2) es wurden mehrere Bugs behoben, welche zu einer fehlerhaften Positionierung der Endpunkte mit den genannten Effekten geführt haben (lars_jena) - die Berechnung der Zielpunkte arbeitet jetzt wieder korrekt (siehe 2. Screenshot unten)
3) durch fehlerhaft umgerechnetes Datenmaterial (global, 72 GB) war die Performanz wieder sehr schlecht geworden, die Routen-Berechnungen haben oft 12 sec und manchmal auch deutlich mehr benötigt; - Fehler behoben, die meisten Routenberechnungen laufen jetzt in ca. 0,1 - 0,7 sec ab
4) beim Aneinanderstückeln von mehreren Teilrouten kam es oft zu unschönen Überschneidungen, was dann bei der Routenführung in Run.GPS zu verwirrenden Sprachausgaben geführt hat (z.B. "abbiegen scharf rechts, dann abbiegen scharf links" statt einfach "geradeaus"); - das Problem ist jetzt mit folgender Logik gelöst:
Angenommen man klickt mit der Maus Anfangspunkt A und Endpunkt B an so werden daraus z.B. 7 Zwischenpunkte berechnet, also:
A - 1 - 2 - 3 - 4 - 5 - 6 - 7 - B
Punkte 1 bis 7 sind Knotenpunkte aus der OpenStreetMap. Die Logik ist jetzt einfach so: liegt Endpunkt B auf der Route A - 7, dann wird der Punkt B nicht übernommen, da er eine Rückwärtsbewegung darstellen würde. Liegt B dagegen nicht auf der bisherigen Route, so wird er als neuer Routenpunkt übernommen.
Damit ist ein zuverlässiges Aneinanderstückeln möglich. Dass der Endpunkt nicht in jedem Fall genau dort landet, wo man geklickt hat, ist nicht weiter tragisch.
Noch ein TIPP: das Aneinanderstückeln von Routen klappt am besten, wenn man immer auf Weg-Kreuzungen klickt und nicht einfach irgendwo auf dem Weg (denn an den Kreuzungen befinden sich auch die OpenStreetMap-Nodes).