You are not logged in.

#201 2013-11-05 19:12:14

rayquaza
Member
From: DE-BW
Registered: 2012-11-18
Posts: 2,007

Re: BRouter: offline Fahrrad-Routing für Android

openzzz wrote:

Ist es nicht auch bei Android so, dass wenn das RAM nicht reicht, Speicherseiten auf die SD-Karte geswappt werden?

Nur wenn die SD-Karte eine Swap-Partition hat und diese aktiviert ist (also wie bei einen normalen Linux). Dafür muss man allerdings fast immer das Gerät erst rooten…

openzzz wrote:

OsmAnd bevorzugt Fahrradwege entlang viel befahrener Straßen. Kann man machen für die Rennradler unter uns

Rennrad-Fahrer bevorzugen vermutlich eher radwegfreie Strassen, aber das ist ein anderes Thema…

Offline

#202 2013-11-05 20:05:30

openzzz
Member
Registered: 2013-10-03
Posts: 215

Re: BRouter: offline Fahrrad-Routing für Android

Nop wrote:
openzzz wrote:

Aber Java ist auch i.d.R. langsamer als C++.

Diese Annahme ist etwa 10 Jahre veraltet. Sieh z.B. die Benchmarks hier: http://scribblethink.org/Computer/javaCbenchmark.html

Nein, gilt eigentlich immer noch, auch wenn die VMs besser geworden sind.

"There are lies, damn lies and Benchmarks"
http://www.freewebs.com/godaves/javabench_revisited/

Bei NestedLoop ist C++ dort 50x so schnell, aber auch sonst
bis auf eine Ausnahme immer führend.

Sicherlich gibt es auch flotte Java-Programme. Manchmal überraschend schnell.
OsmAnd fand ich aber extrem langsam, wenn es mangels Native-Libraries
auf Java zurückfällt.

In C lässt sich eben der Prozessor am besten kontrollieren, fast wie in Assembler.
Auch die neuen Prozessor-Features sind über Intrinsics bzw. Inline-Assembler ohne
Overhead nutzbar (SSE, AVX). Wichtig ist das in der schnellen Signalverarbeitung.

Offline

#203 2013-11-05 20:23:22

viw
Member
Registered: 2010-05-15
Posts: 2,623

Re: BRouter: offline Fahrrad-Routing für Android

openzzz wrote:
Nop wrote:
openzzz wrote:

Aber Java ist auch i.d.R. langsamer als C++.

Diese Annahme ist etwa 10 Jahre veraltet. Sieh z.B. die Benchmarks hier: http://scribblethink.org/Computer/javaCbenchmark.html

Nein, gilt eigentlich immer noch, auch wenn die VMs besser geworden sind.

"There are lies, damn lies and Benchmarks"
http://www.freewebs.com/godaves/javabench_revisited/

Bei NestedLoop ist C++ dort 50x so schnell, aber auch sonst
bis auf eine Ausnahme immer führend.

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/ … 38567.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-Techn … ersion_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.

Last edited by viw (2013-11-05 20:26:36)

Offline

#204 2013-11-05 20:50:39

abrensch
Member
Registered: 2013-01-07
Posts: 509

Re: BRouter: offline Fahrrad-Routing für Android

openzzz wrote:

Aber ich dachte der große Vorteil von BRouter wäre seine Konfigurierbarkeit und die Nutzung des Höhenprofils für die Metrik. Ich hatte nicht den Eindruck, dass OsmAnd zu viele Umwege mangels Optimierung liefert.

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.

Offline

#205 2013-11-05 21:01:33

Netzwolf
Member
Registered: 2008-04-01
Posts: 1,665

Re: BRouter: offline Fahrrad-Routing für Android

Nahmd,

abrensch wrote:

[…]die Diskussion ist einfach sinnlos, in der Praxis machen die Daten-Modelle und die Algorithmen den Unterschied, die Technologie kann das nicht reissen, […]

Danke, oder auf neudeutsch: +1

Du hast mir die Worte aus dem Mund genommen.

Gruß Wolf

Offline

#206 2013-11-05 21:21:35

seichter
Member
Registered: 2011-05-21
Posts: 2,738

Re: BRouter: offline Fahrrad-Routing für Android

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.

Last edited by seichter (2013-11-05 21:39:09)

Offline

#207 2013-11-05 21:30:01

openzzz
Member
Registered: 2013-10-03
Posts: 215

Re: BRouter: offline Fahrrad-Routing für Android

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.

Last edited by openzzz (2013-11-05 21:38:53)

Offline

#208 2013-11-05 21:46:20

rayquaza
Member
From: DE-BW
Registered: 2012-11-18
Posts: 2,007

Re: BRouter: offline Fahrrad-Routing für Android

openzzz wrote:

Der Android-Kernel ist nicht umsonst in C geschrieben.

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?

Offline

#209 2013-11-05 21:49:37

openzzz
Member
Registered: 2013-10-03
Posts: 215

Re: BRouter: offline Fahrrad-Routing für Android

seichter wrote:

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.

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.

Offline

#210 2013-11-05 21:59:00

openzzz
Member
Registered: 2013-10-03
Posts: 215

Re: BRouter: offline Fahrrad-Routing für Android

rayquaza wrote:

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…

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 smile

Offline

#211 2013-11-05 23:08:30

openzzz
Member
Registered: 2013-10-03
Posts: 215

Re: BRouter: offline Fahrrad-Routing für Android

abrensch wrote:

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.

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?).

Offline

#212 2013-11-05 23:50:07

Nop
Moderator
Registered: 2009-01-26
Posts: 2,457

Re: BRouter: offline Fahrrad-Routing für Android

openzzz wrote:

Es ist halt schwierig mit Benchmarks zu argumentieren.

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

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


Nothing is too difficult for the man who does not have to do it himself...
Projekte: Reit- und Wanderkarte mit Navigation - Kartengenerator Map Composer - GPS Track Editor Track Guru

Offline

#213 2013-11-05 23:50:36

ikonor
Member
Registered: 2010-11-08
Posts: 499
Website

Re: BRouter: offline Fahrrad-Routing für Android

openzzz wrote:

OsmAnd bevorzugt Fahrradwege entlang viel befahrener Straßen. Kann man machen für die Rennradler unter uns, für sie eine gute Metrik. Ich möchte aber Ruhe und fahre bevorzugt Feldwege und noch lieber Waldwege. Aber wer berücksichtigt den Waldanteil? Ehrlich gesagt hat mir bisher noch kein Router zuverlässig aus meiner Sicht attraktive Routen geliefert. Ich priorisiere auch keine Fernradwege, wenn es ruhigere Alternativen im Wald gibt. Hoch im Kurs stehen bei mir Fluss- und Bachläufe, Mischwald, Fernsicht auf Höhenwegen etc.

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

Offline

#214 2013-11-06 00:28:55

openzzz
Member
Registered: 2013-10-03
Posts: 215

Re: BRouter: offline Fahrrad-Routing für Android

ikonor wrote:

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.

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.

Offline

#215 2013-11-06 12:23:32

ikonor
Member
Registered: 2010-11-08
Posts: 499
Website

Re: BRouter: offline Fahrrad-Routing für Android

openzzz wrote:
ikonor wrote:

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.

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.

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. 

openzzz wrote:

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.

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

Offline

#216 2013-11-06 12:44:47

abrensch
Member
Registered: 2013-01-07
Posts: 509

Re: BRouter: offline Fahrrad-Routing für Android

openzzz wrote:

Aber manchmal kam es vor, dass partout ein bestimmter Weg verweigert wurde, auch als ich schon kurz davor stand. .... Vielleicht habe ich die Verbots-Schemata nicht verstanden oder es war ein Bug in OsmAnd.

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.

openzzz wrote:

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?).

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.

openzzz wrote:

Aber wer berücksichtigt den Waldanteil? Ehrlich gesagt hat mir bisher noch kein Router zuverlässig aus meiner Sicht attraktive Routen geliefert.

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...

Offline

#217 2013-11-07 01:28:40

openzzz
Member
Registered: 2013-10-03
Posts: 215

Re: BRouter: offline Fahrrad-Routing für Android

abrensch wrote:

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.

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.

Offline

#218 2013-11-07 12:44:28

abrensch
Member
Registered: 2013-01-07
Posts: 509

Re: BRouter: offline Fahrrad-Routing für Android

openzzz wrote:

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).

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

abrensch wrote:

Und noch was interressantes habe ich: ich hab's geschafft, OsmAnd aus den Sourcen zu bauen (in der Version ohne native Bibliotheken) und da die direkte Schnittstelle zu BRouter reingebaut. Das ganze ist noch schwebend als Pull-Request auf GitHub:

  https://github.com/osmandapp/Osmand/pull/537

Aber eine Binär-Version habe ich jetzt einfach mal bei mir hochgeladen:

  http://h2096617.stratoserver.net/broute … router.zip

Das ist natürlich Bastelkram, ohne die nativen Libs ist das rendering schon spürbar langsamer, und das APK ist mit dem Debug-Key signiert (man muss also eine release-version erst deinstallieren), und paar Übersetzungen musste ich auch löschen, aber die Verbindung zu BRouter funktioniert tadellos und die automatischen Neuberechnungen (auch bei langen Strecken) machen richtig Freude.

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.

Offline

#219 2013-11-07 21:43:43

womisa
Member
Registered: 2009-06-30
Posts: 445

Re: BRouter: offline Fahrrad-Routing für Android

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.......

Last edited by womisa (2013-11-07 21:45:04)

Offline

#220 2013-11-07 22:18:48

schiki
Member
Registered: 2012-12-07
Posts: 96

Re: BRouter: offline Fahrrad-Routing für Android

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


Gruß aus Rheinhessen

Offline

#221 2013-11-07 22:43:35

womisa
Member
Registered: 2009-06-30
Posts: 445

Re: BRouter: offline Fahrrad-Routing für Android

Hallo schiki,

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

Offline

#222 2013-11-07 23:07:36

schiki
Member
Registered: 2012-12-07
Posts: 96

Re: BRouter: offline Fahrrad-Routing für Android

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.


Gruß aus Rheinhessen

Offline

#223 2013-11-07 23:23:01

abrensch
Member
Registered: 2013-01-07
Posts: 509

Re: BRouter: offline Fahrrad-Routing für Android

womisa wrote:

Routet man jetzt auf einer Bergstrecke in kurzen Abschnitten geht der Router irgenwann zurück auf eine "weit" abliegende Nebenstrasse....

Ich hab' das mal in den östereichichen Alpen gesehen, dass eine Wintersperre für den Pass als access=no für ein kurzes Stück der Passstrasse eingetragen war. Was dann natürlich dazu führt, dass der Router irgendwelche noch unpassierbareren Wanderrouten findet.

Sowas kann man patchen, indem man access=no einfach rausnimmt, also aus "or access=private access=no" einfach nur "access=private" macht

Offline

#224 2013-11-07 23:34:27

womisa
Member
Registered: 2009-06-30
Posts: 445

Re: BRouter: offline Fahrrad-Routing für Android

Hallo

vielen Dank für die Antworten. Ich habe mal ein Snapshot gemacht (Zentrum ca.  46.53;8.37) geroutet wurde vom 1. roten Punkt zum 2. roten Punkt und dann sollte zum 3 . roten Punkt geroutet werden, aber dann kommt die Blaue Nebenlinie ohne roten Endpunkt.....
Ich habe den "shortest.brf" genommen und die Routingdateien sind neu.

siehe da: http://augilabs.de/swingmapViewer/bilder/Oberwald.jpg

Wie schon beschrieben die http://www.wanderreitkarte.de/ routet das problemlos. Die Kartenbasis (OSM) müßte doch gleich sein, oder?.


ich habe das geändert:

zeile 23: switch or access=private acces=no    geändert:  switch or access=private
zeile 65: switch or access=private acces=no    geändert:  switch or access=private

dan kommt aber ein Fehler:

Exception in thread "AWT-EventQueue-0" java.lang.IllegalArgumentException: ParseException at line 30: assign operator within expression
    at btools.expressions.BExpressionContext.parseFile(BExpressionContext.java:470)
    at btools.router.RoutingEngine.<init>(RoutingEngine.java:78)
    at womisa.brouter.BRouter.findROUTE(BRouter.java:25)
    at org.mapsforge.map.swing.controller.MouseEventListener.mouseClicked(MouseEventListener.java:119)
    at java.awt.Component.processMouseEvent(Component.java:6508)
    at java.awt.Component.processEvent(Component.java:6270)
    at java.awt.Container.processEvent(Container.java:2229)
    at java.awt.Component.dispatchEventImpl(Component.java:4861)
    at java.awt.Container.dispatchEventImpl(Container.java:2287)
    at java.awt.Component.dispatchEvent(Component.java:4687)
    at java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4832)
    at java.awt.LightweightDispatcher.processMouseEvent(Container.java:4501)
    at java.awt.LightweightDispatcher.dispatchEvent(Container.java:4422)
    at java.awt.Container.dispatchEventImpl(Container.java:2273)
    at java.awt.Window.dispatchEventImpl(Window.java:2719)
    at java.awt.Component.dispatchEvent(Component.java:4687)
    at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:735)
    at java.awt.EventQueue.access$200(EventQueue.java:103)
    at java.awt.EventQueue$3.run(EventQueue.java:694)
    at java.awt.EventQueue$3.run(EventQueue.java:692)
    at java.security.AccessController.doPrivileged(Native Method)
    at java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:76)
    at java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:87)
    at java.awt.EventQueue$4.run(EventQueue.java:708)
    at java.awt.EventQueue$4.run(EventQueue.java:706)
    at java.security.AccessController.doPrivileged(Native Method)
    at java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:76)
    at java.awt.EventQueue.dispatchEvent(EventQueue.java:705)
    at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:242)
    at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:161)
    at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:150)
    at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:146)
    at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:138)
    at java.awt.EventDispatchThread.run(EventDispatchThread.java:91)

Last edited by womisa (2013-11-08 01:06:16)

Offline

#225 2013-11-07 23:44:07

openzzz
Member
Registered: 2013-10-03
Posts: 215

Re: BRouter: offline Fahrrad-Routing für Android

abrensch wrote:
openzzz wrote:

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).

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

abrensch wrote:

Und noch was interressantes habe ich: ich hab's geschafft, OsmAnd aus den Sourcen zu bauen (in der Version ohne native Bibliotheken) und da die direkte Schnittstelle zu BRouter reingebaut. Das ganze ist noch schwebend als Pull-Request auf GitHub:

  https://github.com/osmandapp/Osmand/pull/537

Aber eine Binär-Version habe ich jetzt einfach mal bei mir hochgeladen:

  http://h2096617.stratoserver.net/broute … router.zip

Das ist natürlich Bastelkram, ohne die nativen Libs ist das rendering schon spürbar langsamer, und das APK ist mit dem Debug-Key signiert (man muss also eine release-version erst deinstallieren), und paar Übersetzungen musste ich auch löschen, aber die Verbindung zu BRouter funktioniert tadellos und die automatischen Neuberechnungen (auch bei langen Strecken) machen richtig Freude.

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.

Na, ich wollte meine Original-Version nicht deinstallieren. Die ist mittlerweile bei Version 1.6.5 und dein
Binary wäre ein Downgrade auf 1.6.1. Dazwischen hat sich laut Release-Notes das Format der Kartendateien geändert.
Die kommen jetzt auch von einem neuen Server (hatte ich schon bei mir aufgespielt):
http://new.osmand.net/list.php

Die Java-Version läuft auf meinem billigen Samsung-Smartphone (lahme CPU, wenig RAM) extrem langsam.
Mit den native Libs (C++) ist das erträglicher. Der Kartenaufbau könnte natürlich flotter sein, aber es sind
eben auch viele Objekte drin (Detailmodus ist aktiviert). Einmal hatte ich aus Versehen die Java-Version drauf,
da wegen Speichermangel die "Link to SD-Card" Funktion fehlerhaft war, OsmAnd dann die native Libraries
wohl nicht finden konnte. Mein interner Flash-Speicher ist nur 150 MB. Darum muss ich alles auf eine
ausgelagerte Partition der 32 GB µSD-Karte verlinken.

Also Brouter benimmt sich dann genauso wie der Interne Router? Der merkt relativ schnell, wenn ich der Route nicht folge,
und berechnet dann ohne Nachfrage oder Benutzerinteraktion gleich die neue Route.

Soll das denn wirklich ein OsmAnd-Plugin werden? Die stehen unter "Zusatzmodule".
Dein Download ist ja kein Plugin, sondern eine gepatchte Version von OsmAnd selbst.
Der Unterschied beim Plugin wäre, dass man immer die Updates der Originalversion bekommt,
auch wenn sich das BRouter-Plugin nicht geändert hat.

Offline

Board footer

Powered by FluxBB