Ob BRouter das macht, weiß ich nicht. Auf cycle.travel gibt es explizit die Option "Round-trip".

Die dürfte aber nur sowas wie "Startpunkt=Endpunkt" setzen; bereits gefahrene Abschnitte vermeidet der sehr wahrscheinlich nicht.

Ich weiß echt nicht, wie genau man diese Vermeidung schon gefahrener Abschnitte implementieren will. Mir ist kein bekannter "optimaler Pfad"-Suchalgorithmus bekannt, der das tun würde. Natürlich kann man da "ad hoc" irgendwas implementieren - aber alles was mir spontan so einfällt, lässt ziemlich fix Beispiele konstruieren, wo ein Ergebnis raus kommt, was man sicher so nicht will.

das dürfte sehr häufig zutreffend sein. Ich bin eh etwas verwundert, wie häufig allem Anschein nach die Wegeplanung an irgendwelche Algorithmen ausgelagert wird. Ich benutze zwar schon seit mehr als 20 Jahren digitale Karten, mir passend erscheinende Software und Navigationsgeräte um mir die Karten und evt. die vorher festgelegten Wegelinien anzeigen zu lassen. Aber was ich denn unterwegs wirklich mache, ob ich der vorgeplanten Linie folge oder spontan andere Wege nutze, bleibt bei mir stets offen und wird situationsabhängig entschieden.

Darf ich die Aussage etwas schärfen? Man muss nur eine zusätzlich "Regel" in den Algorithmus einbauen: Befahrene Abschnitte werden beim nochmaligen Befahren unabhängig von der Richtung mit maximal hohen Kosten belegt. Ich kenne aber auch keine Software, die dieses Feature hat.
Gruß
Uli

In die Formulierung eines "optimalen Weges" kann man das so natürlich aufnehmen. Nur ist die Problemstellung dann nicht mehr so, dass du den Dijkstra-Algorithmus zum Finden des optimalen Weges verwenden kannst. Grundvoraussetzung für den ist, dass die Kosten eines Wegabschnitts vorher feststehen. Die Kosten von A nach B dürfen dabei andere sein als von B nach A (z.B. bergauf oder bergab).
Bei deiner Variante hängen die Kosten von Wegabschnitten jedoch von dem gewählten Weg selbst ab, stehen also nicht a priori fest. Das Problem ist damit nicht mehr lokal, sprich auf Teilabschnitten ist die gefunde Lösung die mehr zwingenderweise ebenso die optimale Lösung. Numerisch wird das aus vielfältiger Sicht deutlich komplizierter, vor allem ist es nicht mehr so ohne weiteres Parallelisierbar.

Um mal so ein Beispiel aufzuzeigen, was das für Konsequenzen hat: Wir suchen einen Weg von A über B und C nach D. Zwischen A und B finden wir einen vermeintlich optimalen Weg der z.B. eine Hauptroute benutzt. Wir gehen außerdem mal davon aus, dass man naiv auch zwischen B und C und C und D kurz über die Hauptroute fahren würde, wegen der Strafkosten aus dem ersten Wegsegment dies dann aber nicht tut und große Umwege fährt. Die so gefundene Lösung ist dann aber nicht optimal, weil ein günstigerer Weg womöglich zwar zwischen A und B länger wäre, aber nicht die Hauptroute nutzt und so der Wegabschnitt zwischen B über C nach D so wesentlich kürzer hätte ausfallen können (weil da die Strafkosten wegfallen).

Ja, da hast du natürlich Recht. Bei einer wirklich automatischen Berechnung kann das nicht funktionieren, da muss "man" manuell eingreifen.
Gruß
Uli

cycle.travel macht das ganz einfach. Dort gibt es auch eine Funktion "Finde Alternativen". Der "Rundkurs" wird offensichtlich aus der Originalstrecke vom Start zum Ziel und der ersten Alternative für die Fahrt vom Ziel zum Start zusammengesetzt. In vielen Fällen ist das Ergebnis ganz brauchbar. Man könnte dasselbe natürlich auch mit BRouter machen, indem man das Original der Hinfahrt und eine der Alternativen der Rückfahrt zusammensetzt.

Interessant ist auch die Möglichkeit, sich Rundtouren einer bestimmten Länge von einem Startpunkt aus vorschlagen zu lassen. Auch da kommen ganz passable Ergebnisse zustande.