Und so wünsche ich mir das auch → automatisch und nicht manuell nach dem Laden der Route.
Aber was soll denn passieren wenn sich nicht nur die Geschwindigkeit geändert hat, sondern z.B. eine Brücke abgerissen wurde, eine Straße in eine Einbahnstraße geändert wurde etc. und Teile der Planung damit unbefahrbar werden?
Dann würde ich sehenden Auges in eine Sperrung fahren.
Und auch umgekehrt ist es gut wenn “neue” Daten in die Route einfließen. Wenn beispielsweise ein Segment mit “schnellste Route” geplant ist und zwischenzeitlich ein Stück Schnellstraße oder Autobahn eröffnet wurde.
Wie gesagt, gerne einstellbar über Planung eeinfrieren ( ja / nein ), glaube aber, dass mehrheitlich eine “Befahrbarkeit” nach Planung über WP und deren Kurvigkeit im Vordergrund sehen sollte.
Für mich sind das zwei Paar Schuhe.
Plötzlich auftretende Ereignisse werde ich wohl so schnell über OSM-Daten nicht abfangen können, selbst bei zügiger Pflege in OSM gibt es immer noch Laufzeiten von 2 - 3 Tagen.
Ein Route jedoch, die im Winter geplant wurde um im Sommer gefahren zu werden, kann und sollte mögliche Änderung auf Befahrbarkeit berücksichten. @Toffel 's Vorschlag ist doch ok, am Ende des Tages wär’s auch interssant mal zu sehen wie sich eine solche Einstellung auf die Anwender verteilt
Absolut richtig aber wenn es danach geht könnte man auch CarPlay und AA sofort einstellen, denn das wird nur ein Bruchteil der User nutzen.
Das würde ich nicht sagen denn es geht doch darum, dass sich etwas zur Planung geändert hat. Ich möchte in der Regel auch nicht, dass wegen einer “normalen” Baustelle die Route geändert wird. In 90% aller Fälle die ich erlebt habe, konnte ich immer die Baustelle passieren wenn auch nur geduldet oder weil es keiner sah
Ich möchte das auch nicht zu sehr strapazieren aber ich möchte nur daran erinnern, dass eines der USP bei Kurviger bisher war/ist, das eine .kurviger Datei immer dem Original entspricht und das tut es beim Laden aus der Cloud einfach nicht mehr.
Robin hat ja hier mehrfach geschrieben, dass man das ändern möchte und ich wollte nur nachfragen, da es ja schon wieder etwas her ist.
Für mich ist das sehr wichtig und für andere sind andere Dinge wichtig.
Es geht doch garnicht darum etwas einzustellen. Vielmehr ist doch wichtig, dass Funktionalität, die sehr häufig oder von der Mehrheit der User genutzt wird, den Default darstellen sollte.
Es könnte einfach sein ?
A. Importieren Sie die .kurviger-Datei als Overlay und als navigierbare Route. Das Overlay und die Route überschneiden sich genau.
B. Neuberechnen auslösen (aktualisieren!). Das Overlay bleibt an der alten Position, die navigierbare Route kann sich ändern.
Gefällt Ihnen das nicht? Was wollen Sie denn nun, alt(er) oder doch neu? Im Zweifel?
Wechseln Sie schnell zwischen alt und neu mittels Undo/Redo.
Dann erkläre mir doch bitte, wie du eine Route aus der Cloud ohne Neuberechnung als .kurviger Datei exportieren kannst. Das geht nicht, denn sonst würde es ja zu einfach sein.
Es geht auch nicht unbedingt um die Planung im Web, denn dort wird ja die Abweichung angezeigt und man könnte dann die Route wieder anpassen auch wenn das nicht schön ist.
Es geht aber um das Laden der Route in der App, wenn man seine geplante Routen im Urlaub fahren möchte und sich dann über Abweichungen wundert. Das sieht man mal nicht so schnell auf dem Display und man will dann schon überhaupt nicht die Route vor dem Tourstart nochmals anpassen.
Das Thema zeigt aber auch, dass das vielen nicht bewusst war, auch mir nicht.
Ich schliesse das für mich jetzt ab und hoffe, dass Kurviger bald eine Lösung dafür anbietet.
Eine einfache Undo/Redo Operation, die natürlich erst dann durchgeführt werden kann, wenn der bereits angeforderte .kurviger-Import ohne Änderung vorliegt.
Ich bin wieder dabei meine Norwegentour zu planen und ich bin leider echt genervt von dem was Kurviger mit meinen geplanten Routen ständig macht.
Diese Abweichungen und Eigendynamik stören mich sehr und wenn es da bald keine Lösung für geben sollte, kann ich Kurviger leider nicht mehr einsetzen und ich muss z.B. BaseCamp wieder bei mir aktivieren oder eine andere Lösung suchen.
Ich kann auf AA/CP und viele andere Dinge in Kurviger verzichten aber nicht, dass meine Touren nicht mehr 1:1 dargestellt bzw. gefahren werden.
Ich muss Hobbyfahrer recht geben. Ich kann nicht wieder zurück zu meiner ursprünglichen Planung, weil das sofort über den Haufen geworfen wird.
Die Änderung kann doch gar nicht so schwierig sein.
Einfach nur “nicht” neu berechnen.
Denn wenn ich das will muss ich nach dem drücken “Route laden” einfach nur einmal auf Neu berechnen klicken.
Wenn dan die alte Route durch die rote gestrichelte Linie bestehen bleibt, dann kann ich schauen was anders ist.
gefällt mit das nicht, dnn kann ich einfach wieder einmal auf den Pfeil zur+ck drücken und hab die alte Version wieder.
Aber so wie es ist ist das was der letzte Stand war einfach weg.
Und jetzt an die Programmierer: Wenn ihr mitten im coden seid und ihr könnt nicht wieder exakt auf dem letzten Stand weiter machen, wie wär das?
Vielleicht wird das Thema Planungsrelevanz dabei ersichtlicher.
Hallo Gerhard,
die Welt ist ja bekanntlich nicht schwarz oder weiß, daher haben wohl beide Seiten in ihrer Betrachtung Recht. Für mich ist die Planung halt das Setzten von WP um an’s Ziel zu kommen, die Strecke zwischen den WP überlasse ich dem Algorithmus von Kurviger. Und ich überlasse es auch Kurviger, die aktuelle Situation in OSM zu berücksichtigen, wenn es in den Segmenten über die Zeit neue Erkenntnisse gibt, wie Sperren oder gar neuen Strecken, die zwischenzeitlich gebaut wurden. Ich kann Kurviger natürlich beliebig einschränken durch das Setzen beliebig vieler WPs bis hin zum Niveau eines Tracks oder darüber hinaus, was letztlich wohl dem Bild der “Planung” entspricht. Mein Punkt ist eher: Was passiert wenn der “Track” 1:1 zurückgeholt wird und man nicht rekalkuliert? Dann laufe ich natürlich Gefahr u.U. in ungewollte Situationen zu laufen die es zum Zeitpunkt der Planung nicht gegeben hat. Und da ist es mir lieber wenn mich K3 über meine WP routet unter Berücksichtigung der aktuellen OSM Situation, automatisch.
Vielleicht bedarf es ja zweier Ladeknöpfe, bin nicht sicher welcher UseCase letzllich häufiger Anwendung findet…
Doch, das ist eine riesen Änderung. Wir müssen unser Format wie wir Daten in der Cloud speichern komplett überarbeiten und das muss so passieren, dass alte App-Versionen nicht kaputt gehen, weil die mit dem neuen Format nicht klar kommen. Das steckt mehr dahinter als man so annimmt.
Wenn das Feature mit der Version 3.5.0 kommen würde, dann alles < 3.5.0, also 3.4.3, 3.4.2,… - das ist leider das Problem mit App, du hast immer ein “Fenster” in dem mehrere Version gleichzeitig Serverseitig funktionieren müssen.
Oder es ist eine Eigenschaft der Route selbst, die man in der Planung festlegt und mit ihr abspeichert. Dann wäre man sehr variabel.
z.B.
No Recalculation
Eine neue Datenbankstruktur wäre trotzdem nötig.
Aber wenn dies dann ein anderer Zweig wäre in den gespeichert wird könnte das evtl. einfacher werden. Quasi parallel angelegt.
Alte Apps könnten dann auf die alte Datenbasis und nicht auf die, wo das Häckchen gesetzt wurde, zugreifen.
Vielleicht wäre das ein Lösungsansatz.
