Hi,
Ich antworte mal gesammelt:
zur /sdcard-Problematik: die Probleme entstehen mit Android-4, wo /mnt/sdcard in der Regel garkeine Karte mehr
ist, sondern fest eigebaut, aber trotzdem was anderes als der “interne Telefonspeicher”, wo die Apps selbst
installiert sind (und auch nochmal ein Arbeitsverzeichnis haben, wo sie Dateien ablegen können. Mein bisheriger
Ansatz, das Basisverzeichnis für die BRouter-Dateien und für die Suche nach den Wegpunkte-Datenbanken der Maptools
gleichzusetzen funktioniert bei Oruxmaps nicht mehr, weil Oruxmaps bzgl. der Datenbankfiles fest gegen die
eingebaute Karte (/mnt/sdcard) programmiert ist. Ich werde BRouter entsrechend flexibler machen.
Zur Geschwindigkeit: Das mit den 3 Durchgängen stimmt, und der erste entspricht dem, was sie
bei OsmAnd “Routing” nennen und der dritte dem, was sie bei OsmAnd “precice Routing” nennen. Ich mache
den ersten Durchgang aber nur, um eine obere Schätzung zu bekommen, die beim dritten Durchgang das
Suchgebiet besgrenzen soll und würde nicht auf die Idee kommen, das Ergebnis des ersten Durchgangs als
Routingergebnis zu verkaufen. Das ist nämlich keins.
Andere setzten auf contraction-hirachies, also vorberechnete Teil-Routen, aber dabei geht jede Konfigurierbarkeit verloren.
Was ich tatsächlich plane nenn ich “fast partial recalculations”, um speziell das Problem der Neuberechnung nach
Track-Abweichung zu lösen. Das kann man natürlich bisschen weiter spinnen, indem man nicht nur einen
“vorher berechneten Track” speichert, auf den man sich bei einer partiellen Neuberechnung bezieht, sondern
mehrere, und da wird der Übergang zu den contraction-hirarchies fliessend. mal sehen.
zu den paarweisen Radwegen ich denke, ich werd’s mal so probieren, dass ich mich mal auf die gemappte Richtung des Radweges beziehe und nur eine kleine Symmetriebrechung einbaue, (± 2% Kostendifferenz oder so), so dass in der Regel die richtige Seite genommen werden sollte. onway=yes für solche Wege halte ich für problematisch.
Gruss, Arndt