BRouter: offline Fahrrad-Routing für Android

Du solltest nochmal aufmerksam lesen in dem Test lese ich sun Java 1.4 und 1.5
zu Java 1.4: http://www.oracle.com/technetwork/java/javase/index-jsp-138567.html
und Java 1.5 entspricht wohl Java 5 welches laut Wikipedia auch schon im Jahr 2004 das Licht der Welt erblickte:
http://de.wikipedia.org/wiki/Java-Technologie#Version_5.0

Das entspricht dann in etwa den 10 Jahren die Nop hier ansprach.
Ach wenn man ganz ans Ende scrollt sieht man ja auch das Jahr 2004. Übrigens wenn du genau schaust unterscheiden sich g++ und Intel und es gibt Disziplinen das ist Java beiden überlegen.

Wenn Du 2km zum Bäcker fährst merkst Du das normalerweise auch nicht, aber bei längeren Strecken siehst Du schon den Effekt zwischen OsmAnds “ab durch die Mitte” und BRouters “vielleicht doch besser aussen rum”. Obwohl ich auch bei kurzen Strecken bei OsmAnd offline oft Effekte sehe, wo man sich denkt, warum, jetzt dieser Zacken durch die Wohngebiete, der direkte Weg geht eindeutig da lang.

Zu der C++ ↔ Java Diskussion, Die du da angestossen hast, äussere ich mich nicht als jemand, der mit Java sein Geld verdient, weil die Diskussion ist einfach sinnlos, in der Praxis machen die Daten-Modelle und die Algorithmen den Unterschied, die Technologie kann das nicht reissen, und insofern ist Victors Ansatz mit den nativen libs aus meiner Sicht ein Irrweg.

Nahmd,

Danke, oder auf neudeutsch: +1

Du hast mir die Worte aus dem Mund genommen.

Gruß Wolf

Frei nach Churchill: Ich glaube nur den Benchmarks, die ich selber gefälscht habe.
Es lassen sich immer Probleme finden, die sich mit einer Sprache besser lösen lassen wie in einer anderen.
Auf die Spitze treiben das die Grafikkarten-Hersteller, die den Micrcode für ihre Grafikprozessoren auf die momentan gängigen Benchmarks hin optimieren, auch wenn das im Normalbetrieb eher Nachteile bringt.

Generell ist Java eine interpretierte, C/C++ eine compilierte Sprache. Daher rührten die Laufzeitunterschiede zu Beginn vor allem her. Heute gibt es JIT-Compiler zu Java, die den Code zur Laufzeit zumindest lokal auch optimieren können. Da der meiste Rechenaufwand üblicherweise in engen Schleifen verbraten wird, hat sich der Unterschied damit drastisch verringert.
Global kann aber nur eine compilierte Sprache optimieren. Welchen Anteil das an der Rechenzeit hat und ob der C+±Compiler das auch tut, ist wieder eine andere Frage.
Wenn es um Bitfieseleien geht, ist Java klar unterlegen (dafür wurde es aber auch nicht entworfen).

Die meiste Zeit drehen die üblichen Anwendungen aber sowieso Däumchen und warten auf eine Reaktion des Benutzers. Der kann dann auch nicht unterscheiden, ob die Reaktion auf einen Klick in einer Hunderstel oder Tausendstel Sekunde erfolgt.

Zusatz: Einen lausigen Algorithmus rettet auch eine “schnellere” Sprache nicht. Beim selben Algorithmus kann es aber sehr wohl Unterschiede geben. Ob die aber so groß sind, dass sich der erheblich größere Aufwand für eine “Mischtechnologie” (Einbinden von native code) lohnt, ist fraglich.
Am schnellsten wäre sicher Assembler, aber das tut sich doch wohl keiner an.

Nop hatte halt den 2004er Benchmark zitiert, und der “revisited” Benchmark war die Antwort darauf.

Es ist halt schwierig mit Benchmarks zu argumentieren. In der Praxis kommt es noch auf viele andere Dinge an.
Der Android-Kernel ist nicht umsonst in C geschrieben. Jede Sprache hat eben so ihre Anwendungsdomäne.
Java ist für bestimmte Anwendungen auch gut geeignet, z.B. da wo es auf Betriebssicherheit ankommt.
Mit C sind viele systemnahe Tricks möglich, wird gerne mit Pointern operiert und der Speicher selbst
verwaltet. Das ist gut für die Performance (wenn man es richtig macht), birgt aber das Risiko bösartiger
Crashes. Man kann in C++ auch gut ohne Pointer sauber programmieren.
Es lässt einem die totale Freiheit, entweder systemnah mit Assembler-Inlines, Intrinsics
für SSE/AVX, oder ganz abstrakt mit Objekten und Templates.

Schön in C++ ist das Overloading der mathematischen Operatoren + - *, so dass man auch
mit komplexen Zahlen, Matrizen und Vektoren einfach rechnen kann. Komplizierte Formeln
sehen dann im Programmcode so übersichtlich aus wie im Lehrbuch. Der Code wird dadurch sehr
viel leserlicher als in Java oder C. Das hat mich bisher davon abgehalten, auf Java oder Python
umzusteigen, obwohl die natürlich auch viele Vorteile bieten.
Früher waren sie immer bei ihrer mächtigen Systembibliothek überlegen. Mit
BOOST hat C++ mittlerweile gut aufgeholt. Das ist schon eine sehr komfortable
Unterstützung für viele Dinge, die man früher noch mühsam selbst programmieren musste.

Aber natürlich kann der beste Compiler oder die beste Sprache nicht helfen, wenn der
Algorithmus oder die Programmlogik nicht optimiert wird.
Das wichtigste Optimierungsorgan ist immer noch das Gehirn des Programmierers.

Meinst du damit den Linux-Kernel? Klar ist der nicht in Java geschrieben, weil es Java damals noch nicht gab (1991 vs. 1995). Ausserdem bräuchte man für eine Java-VM erstmal ein Betriebssystem darunter…
Oder meinst du Dalvik? Die lässt sich auch schlecht in Java schreiben, weil sie notwendig ist um Java-Anwendungen auszuführen. Wenn sie selbst eine Java-VM bräuchte bräuchte man sie ja nicht mehr.

Und ob C++, C, Java, Assembler oder Brainfuck “lesbarer” ist hängt ja wohl von den Wünschen des Lesenden ab.

BTT: Könnte jemand dazu eine Seite im OSM-Wiki mit ein paar Infos und einer Kurzanleitung anlegen?

Dann probiere OsmAnd mal ohne die native Libs. Bei mir lief das elendig langsam.

Warum kein Assembler? In C++ kannst du in einer Hochsprache schreiben und für ein paar kritische
Dinge Inline-Assembler einschieben. Hab ich schon öfters gemacht. Nur so lassen sich inkompatible
Aufrufkonventionen fremder C++ DLLs handhaben. Besonders aufwendig ist das auch nicht.
Einige Bitschubsereien sind in Hochsprachen extrem ineffizient, selbst in C.
Außerdem, wozu hat man so tolle Prozessoren mit AVX und SSE-Vektoreinheiten, wenn
man sie brach liegen lässt? Was meinst du was da für Speedups verschenkt werden.
Das ist locker mal Faktor 10-20 drin für die schnelle Bildverarbeitung.
In C++ lässt sich das ad-hoc mit intrinsic functions einbetten. Die Möglichkeiten bietet Java nicht.

Nein, es geht auch ohne VM:
http://de.wikipedia.org/wiki/Java-Prozessor

Aber ich denke auch heute würde man den Kernel wieder in C schreiben, einfach weil die Sprache
dafür wie geschaffen ist. Es geht teilweise um sehr harte Echtzeitanforderungen, volle Kontrolle
über Speicher und System, Inline-Assembler. Womit soll denn das sonst gehen?

Wenn auf einen System-Interrupt in wenigen Taktzyklen geantwortet werden soll,
kann eine VM nicht zwischendurch gemütlich noch eine Garbage Collection machen.

So, ich glaube wird sind jetzt zu off-topic … für BRouter ist Java natürlich eine exzellente Wahl :slight_smile:

Zugegeben, auf längeren Touren (z.B. 70 km), habe ich noch keinen automatischen Router benutzt. Da stecken einfach zu viele persönliche Vorlieben drin, die eine Software nicht kennt und auch schlecht durch OSM-Tags ausgedrückt werden können. Nicht zu vergessen in der Routing-Metrik sind auch die Einkehrmöglichkeiten. Bisher hat mich noch keine Routing-App gefragt, ob ich lieber zum indischen Restaurant gehe oder doch zum Italiener (beide als OSM-POI im Kartenmaterial). Dazu kommen noch dynamische Probleme. Die Route und Einkehrmöglichkeiten werden soweit mit dem Regenradar verknüpft, dass man pünktlich zur großen Regenschauer im Lieblingsrestaurant sitzt und danach wieder trocken weiterfahren kann. Erstaunlich, aber es hatte im ersten Versuch funktioniert (auch dank der guten Regenradar-App von wetteronline). Als Routing-Engine habe ich dazu ein größeres neuronales Netz am laufen.

Meine längste geführte Radstrecke mit OsmAnd war ca. 30 km. An sich wäre die Strecke Ok gewesen, wenn es nicht wieder über die Berge gehen würde, die ich auf der Rücktour übers Tal vermeiden wollte.

Die von dir beschriebenen Zacken sind mir noch nicht aufgefallen. Aber manchmal kam es vor, dass partout ein bestimmter Weg verweigert wurde, auch als ich schon kurz davor stand. Einmal (pedestrian mode) habe ich versucht, in JOSM dafür eine Erklärung zu finden, aber es war alles richtig vernetzt, die Nodes verknüpft, der Weg als begehbarer Pfad getaggt. Keine Ahnung. Vielleicht habe ich die Verbots-Schemata nicht verstanden oder es war ein Bug in OsmAnd.

Kommt der Eindruck “vielleicht doch besser aussen rum” vielleicht durch eine andere Metrik zustande? Indem bestimmte Wege einfach bevorzugt werden? In BRouter war mir positiv aufgefallen, dass es einen langen ehemaligen Bahntrassenweg bevorzugt hatte, obwohl es ein tolerierbarer Umweg war. Eigentlich genau das, was man sich als Fahrradfahrer wünscht (wird doch in der Metrik stärker gewichtet, oder?).

Ich hab Dir auch drei konkrete Positiv-Beispiele genannt - die hast Du bloß untern Tisch fallen lassen. :slight_smile:

Bei der Grundgeschwindigkeit gibt es keinen nennenswerten Unterschied mehr. Das Problem sind nur die Programmierer, die es sich leicht machen und die teuersten Luxusklassen ohne Nachzudenken einsetzen. Java macht das einem leicht, weil es so viele schöne libs gibt. Aber in C kriegt man dasselbe z.B. mit Boost auch locker hin. Letztendlich entscheidet ob sich der Autor was dabei gedacht hat.

bye, Nop

So etwas hätte ich auch gerne.

Erst kürzlich gab es einen Blogeintrag zu externen Datenquellen in OSRM mit ähnlicher Thematik: Biking Directions With OSRM’s New External Data Support. Im Beispiel wird eine zusätzliche PostGIS Datenbank mit Imposm Schema verwendet, um Wege innerhalb oder in der Nähe eines Industriegebiets schlechter zu bewerten.

Dann noch Routing über Flächen und Arndt wird es im Winter nicht langweilig :wink:

Gruß,
Norbert

Ruhige Industriegebiete sind mir aber noch lieber als stark befahrene Hauptstraßen,
auch wenn da noch so ein toller “Radfernwanderweg” durch geht oder der Fahrradweg super ausgebaut ist.
Der Straßenlärm geht mir am meisten auf die Nerven.

Weiterhin mag ich ampelfreie Routen, z.B. am Fluß entlang, wo man mal so richtig
Gas geben kann und durch nichts aufgehalten wird.

Ein Rad-Router ist deutlich komplexer als ein Automobil-Router.

Eigentlich geht es nur mit “Persönlichkeitsprofilen”, also ein langes Interview
zu Beginn "fährst du gerne durch Wälder?, “wäre ein bisschen Matsch ein Problem für den Sonntagsrad?”,
“brauchst du Asphalt oder hast du richtige Reifen?”, “lieber die Strecke mit den hübschen Joggerinnen?” …

Und für jede Person kann man weiter differenzieren
Profil “will schnell nach Hause”, “habe Zeit für die Natur”, “heute mal sportlicher” …

Aber bei all den Fortschritten: es ist auch schön, mal ohne Karte und Navi rauszufahren
und sich überraschen zu lassen.

Ist ja auch nur ein Beispiel, wenn man technisch Industriegebiete vermeiden kann, kann man auch Nähe zu Hauptstraßen vermeiden und Wälder oder Nähe zu See/Fluß bevorzugen.

Deutlich einfacher umzusetzen wäre aber vermutlich ein Flag für Wanderrouten, analog zu longdistancecycleway/lcn. Zur Planung von kürzeren Touren halte ich Wanderrouten meist für einen besseren Hinweis auf schöne und ruhige Strecken als Radrouten. Sofern man geschotterte Feld- und Waldwege mag, Pfade kann man ja vermeiden.

Um schon jetzt Radwege an Hauptstraßen zu vermeiden, könnte man in einem BRouter Profil evtl. auch einfach generell track und residential gegenüber Radwegen (cycleway/bicycle) bevorzugen.

Da sehe ich ja eben die Stärke von BRouter, dass man sich seine persönlichen Profile definieren und auch spontan ändern kann. Das geht dann auch schon in Richtung automatische Tourenvorschläge wie bei komoot. Und ja, das ist alles auch ein bisschen nerdige Spielerei, aber halt eben ein spannendes Thema.

Gruß,
Norbert

Nein, OsmAnd kann keine verschachtelten access-regeln, es ist dieses Thema hier:

http://code.google.com/p/osmand/issues/detail?id=1380

ich kenne den Effekt gut, wenn ich am Rhein den R6 langfahre und am Kernkraftwerk Biblis vorbeikomme. Da ist der R6 als access=private, bicycle=yes getagged, was völlig korrekt ist (es ist ja ein Privatweg auf dem Kraftwerksgelände), aber OsmAnd schickt Dich einmal um das Kraftwerksgelände rum.

Bahntrassen-Radwege sind ja nicht speziell getagged, sondern sind einfach track/grade1 oder cycleway, aber hier hilft vielleicht auch die relative grosse “Winkelstrafe” in den BRouter-Profilen, die gerade Wege bevorzugt und zumindest bergab auf der Höhenterm, der sanfte Abfahrten bevorzugt.

Die Landuse-Polygone auszuwerten und als Pseudo-Tags für die Routing-Profile zugänglich zu machen (forest=yes) scheint mir jetzt tatsächlich nicht unmöglich.

Da bin ich dann aber wieder bei dem Thema des 64-bit limits im der “Way-Decsription-Bitmap” - ich hab da einfach keine Bits mehr frei und wüsste also nicht, wo ich das forest=yes bit hinschreiben sollte. Also noch ein Grund mehr, diese Datenstruktur umzubauen um dieses Limit aufzuheben, denn da fehlen ja noch ganz andere Infos, wie zum Beispiel die Wander-Relationen, die Turn-Restrictions oder die Wheelchair-Tags. Das reicht dann auch erstmal, soviel lange Winterabende gibts ja auch nicht…

Hmm, schade. Das sollte man ändern. Ein neues Tag/Attribut dafür?
Bahntrassen haben einen ganz besonderen Character, die sie von anderen Radwegen unterscheidet.
Die sind eben nicht entlang der Hauptstraßen, sondern mitten in der Landschaft.
Steigungen im Mittelgebirge werden durch Tunnel und Viadukte unterdrückt.

Die Attraktivität für Radfahrer ist also besonders hoch, gerade wenn man noch einen Kinderanhänger ziehen muss.

Meinst du den BRouter könnte man als Plugin in OsmAnd integrieren,
so dass er wie der eingebaute Router fungiert ?
Also incl. Routen-Neuberechnen, wenn man mit Absicht von der berechneten Route abweicht
(bei mir sehr typisch).

Damit kann man sich im Android-Market auch noch ein paar Euros dazuverdienen.
Du wirst schon reich, wenn nur ein Bruchteil der weltweiten Population (1 Mrd.?)
mit Android-Smartphone und Fahrrad jeweils ein paar Euros für das Plugin geben würden.
Sehr viel Konkurrenz hast du bei Profil “Rad” nicht. Man muss nur eben besser sein.
Fürs Auto ist mein kommerzielles Navi besser und darum nutze ich das dort exklusiv.

Genau das hab ich längst gemacht und so benutze ich das auch fast täglich:

Bei dem Pull-Request bin ich mir aber mittlerweile nicht mehr so sicher, ob Victors Bedenken wirklich technisch motiviert sind oder ob er einfach nicht will.

Hallo

ich habe den BRouter mit dem MapsforgeSwingMapviewer “verheiratet”. Ein Tester hat den Router jetzt mal in den Schweizer Alpen “vergewaltigt”. Routet man jetzt auf einer Bergstrecke in kurzen Abschnitten geht der Router irgenwann zurück auf eine “weit” abliegende Nebenstrasse…

Meine Frage ist nun: Läßt sich der BRouter auch so konfigurieren (vergewaltigen?) dass er auch auf Wanderpfaden (Bergpfaden) die kürzeste Route sucht. Egal welche Wege/Pfad Beschaffenheit vorhanden ist. Ich weiß, e soll ja ein Fahrradrouter sein. Ich bin in dieser Richtung auch zufrieden.

Zusammenfassung: Ist es möglich,den BRouter so zu konfiguriern dass er den kürzesten Wegt such unabhängig von Steigung und Wegbeschaffenheit ?
Hintergrund: WanderRouten in den Bergen…

Das sollte mit dem shortest Profil schon jetzt ohne weiteres funktionieren, wenn man nicht auch Privatwege und gesperrte Wege benutzen will.

Hallo schiki,

leider nicht! Hab ich schon probiert. Auf meinem Testpfad routet die ReitWanderKarte diesen Pfad problemlos…

Hallo womisa,

das wäre dann ein Fall für eine Rückmeldung im OSM-Android-Bike-Routing Forum bei Google. Evtl. sind auch nur die Routing-Daten veraltet.